Co to są definicje zasobów niestandardowych Kubernetes (CRD)?
Definicje zasobów niestandardowych (CRD) to rozszerzenia interfejsu API Kubernetes, które mogą definiować nowe typy obiektów. Pody, ReplicaSets, ConfigMaps i Ingress to przykłady typowych zasobów wbudowanych. Dokumenty CRD umożliwiają dodawanie do tej listy zupełnie nowych typów, a następnie zarządzanie nimi za pomocą znanych narzędzi Kubernetes, takich jak Kubectl.
Mechanizm CRD jest celowo abstrakcyjny i może być używany na wiele sposobów do przechowywania danych i tworzenia nowych funkcji. Zasoby niestandardowe znajdziesz w wielu popularnych narzędziach społecznościowych: Cert-Manager definiuje obiekty, które reprezentują certyfikaty SSL i wystawców, podczas gdy Helm reprezentuje wykresy jako własne CRD.
streszczenie
Co tworzy zasób?
Zasoby Kubernetes definiują typy danych, które można przechowywać w klastrze. Są one dostępne za pośrednictwem interfejsu API Kubernetes, który zapewnia punkty końcowe do tworzenia, wyświetlania i modyfikowania elementów w każdym typie zasobu.
Możesz dodać niestandardowe zasoby, aby przechowywać własne, dowolne dane w klastrze. Utworzone elementy będą przechowywane przez komponent płaszczyzny sterowania etcd, wraz z wbudowanymi instancjami zasobów. Zasoby niestandardowe są automatycznie wyświetlane przez interfejs API, więc nie musisz konfigurować własnych narzędzi do tworzenia instancji elementów.
CRD domyślnie działają jak proste struktury danych. Chociaż CRD w naturze często mają swoje własne zachowania, nie zapewnia tego mechanizm CRD. Niestandardowe kontrolery i operatory Kubernetes mogą służyć do implementowania funkcji wokół niestandardowych zasobów. Bez kontrolera elementy w CRD będą nadal istniały jako dane statyczne w klastrze, z którymi można wchodzić w interakcje za pośrednictwem punktów końcowych CRUD udostępnianych przez interfejs API Kubernetes.
CRD to dynamiczne komponenty, które można tworzyć i usuwać w dowolnym momencie. Niektóre typy obiektów zawarte w Kubernetes są również implementowane jako CRD, co zapewnia większą modułowość w rdzeniu klastra.
Utworzenie CRD
CRD są same w sobie rodzajem obiektu Kubernetes. Tworzysz je w taki sam sposób, jak każdy inny zasób, pisząc plik YAML i stosując go do swojego klastra:
Wersja api: apieextensions.k8s.io/v1 uprzejmy: Zasób niestandardowyDefinaród metadanych: Nazwa: niestandardowe-aplikacje.crds.example.com specyfikacja: grupa: crds.example.com Wersje: - Nazwa: v1 służył: prawdziwy przechowywanie: prawdziwy schemat: Otwórz APIV3Schema: rodzaj: przedmiot niska zabudowa: specyfikacja: rodzaj: przedmiot niska zabudowa: Nazwa aplikacji: rodzaj: ciąg wersja aplikacji: rodzaj: ciąg liczba wydań: rodzaj: liczba całkowita zakres: z przestrzenią nazw Nazwy: liczba mnoga: niestandardowe aplikacje liczba pojedyncza: niestandardowa aplikacja uprzejmy: Aplikacja niestandardowa
Użyj Kubectl, aby dodać CRD CustomApp do swojego klastra:
$ kubectl apply -f custom-apps-crd.yaml customresourcedefiutworzono nition.apiextensions.k8s.io/custom-apps.crds.example.com
Plik YAML definiuje CRD, którego można użyć do przechowywania danych aplikacji. CRD wymaga metadata.name et spec.group pole w określonym formacie: grupa przyjmuje postać subdomeny, do której należy CRD. Ta sama subdomena musi być uwzględniona w CRD metadata.name . Wartość names.plural zostanie dodany jako nowy komponent subdomeny, aby stworzyć ostateczną wersję metadata.name.
La spec.names To pole określa, w jaki sposób będziesz odwoływać się do CRD podczas korzystania z Kubernetes API i poleceń Kubectl. W tym przykładzie możesz uruchomić kubectl get custom-apps et kubectl get custom-app/example-app do interakcji z obiektami, które korzystają z CRD. Kiedy tworzysz nowy obiekt jako plik YAML, musisz ustawić kind: CustomApp aby uczynić go instancją CRD.
CRD jest skonfigurowany jako typ obiektu na poziomie przestrzeni nazw przez scope pole. Możesz użyć Cluster jako wartość alternatywną dla tego pola do tworzenia obiektów, które istnieją na poziomie klastra, poza jakąkolwiek przestrzenią nazw.
Dane powiązane z Twoimi obiektami niestandardowymi są zdefiniowane w spec.versions.schema.openAPIV3Schema pole. Każda wymieniona „wersja” tworzy nową wersję interfejsu API CRD, do której można się odwoływać za pomocą apiVersion w plikach YAML zasobów. Dane CRD są konfigurowane przy użyciu właściwości OpenAPI; tutaj każda „niestandardowa aplikacja” w Twoim klastrze powinna mieć app-name, app-versionet release-count właściwości zdefiniowane w jego YAML spec.
Korzystanie z CRD
Udostępnianie punktów końcowych interfejsu API dla nowej CRD może potrwać kilka minut. Sprawdź postęp, pobierając szczegóły CRD za pomocą Kubectl:
$ kubectl opisz crd custom-apps.crds.example.com ... Status: Zaakceptowane nazwy: Rodzaj: CustomApp List Rodzaj: CustomAppList Liczba mnoga: niestandardowe aplikacje Liczba pojedyncza: niestandardowa aplikacja Warunki: Czas ostatniego przejścia: 2022-04-04T13: 29:24Z Wiadomość: nie znaleziono konfliktów Powód: Brak konfliktów Status: True Typ: NamesAccepted Czas ostatniego przejścia: 2022-04-04T13:29:24Z Wiadomość: początkowe nazwy zostały zaakceptowane Powód: InitialNamesAccepted Status: True Typ: Ustanowiono ...
CRD jest gotowy do użycia, gdy zobaczysz Type: Established pod koniec danych wyjściowych polecenia. Kubernetes będzie akceptować żądania do punktu końcowego interfejsu API CRD. W takim przypadku podstawowym adresem URL interfejsu API będzie:
/apis/niestandardowe-aplikacje.crds.example.com/v1/przestrzenie nazw/*/niestandardowe-aplikacje/...
Możesz teraz używać Kubectl do przeglądania obiektów, które zostały utworzone za pomocą CRD:
$ kubectl get custom-apps Nie znaleziono zasobów w domyślnej przestrzeni nazw.
Chociaż żaden obiekt jeszcze nie istnieje, Kubernetes teraz wie, że ma typ zasobu o nazwie custom-apps.
Aby utworzyć obiekt "aplikacji niestandardowej", napisz nowy plik YAML za pomocą kind: CustomApp. Plik apiVersion należy ustawić na nazwę grupy i wersję interfejsu API dostarczoną przez CRD. W obrębie spec uwzględnij właściwości zdefiniowane w schemacie CRD.
Wersja api: crds.example.com/v1 uprzejmy: Aplikacja niestandardowa metadanych: Nazwa: aplikacja-demo-1 specyfikacja: Nazwa aplikacji: aplikacja demonstracyjna wersja aplikacji: 1.1.0 liczba wydań: 5
Użyj Kubectl, aby dodać obiekt do klastra:
$ kubectl apply -f custom-app.yaml customapp.crds.example.com/utworzona-aplikacja demo
Możesz teraz pobrać szczegóły obiektu za pomocą zwykłych poleceń Kubectl:
$ kubectl opisz custom-app/demo-app-1 Nazwa: demo-app Przestrzeń nazw: default Etykiety: Uwagi: Wersja API: crds.example.com/v1 Rodzaj: CustomApp ... Specyfikacja: Aplikacja - Nazwa: aplikacja demo Aplikacja - Wersja: 1.1.0 Wydanie - Liczba: 5 ... Zdarzenia:
Masz działający zasób niestandardowy, który przechowuje teraz niektóre dane w Twoim klastrze Kubernetes. Możesz usunąć CRD, usuwając go w Kubectl; spowoduje to automatyczne wyczyszczenie wszystkich obiektów, które z niego korzystają.
$ kubectl usuń crd custom-apps.crds.example.com customresourcedefinition.apiextensions.k8s.io „custom-apps.crds.example.com” usunięte
Tworzenie deklaratywnych interfejsów API za pomocą CRD
Ta CRD nie dodaje żadnych funkcji do klastra. Przechowuje dane, udostępnia interfejs API do interakcji z nimi i może odwoływać się do innych obiektów. CRD stają się bardziej wydajne, gdy są sparowane z niestandardowym kontrolerem, który może wziąć odpowiedzialność za zarządzanie nimi.
Kontrolerzy śledzą zasoby i podejmują działania w odpowiedzi na ich zdarzenia. Napisanie kontrolera dla Twoich CRD umożliwia przekształcenie ich w deklaratywne interfejsy API, które wprowadzają rzeczywiste zmiany w klastrze. Twoje obiekty mogą reprezentować powrotu stan, zamiast dokładnego stanu bieżącego.
Cert-Manager używa tego wzorca do automatycznego uzyskiwania certyfikatów SSL, gdy w klastrze pojawią się nowe obiekty CertificateRequest. W rdzeniu Kubernetes węzły pobierają i wykonują obrazy kontenerów w odpowiedzi na pojawiające się pody. Kontrolery umożliwiają dołączanie zachowania do własnych CRD, więc dodanie „aplikacji niestandardowej” może spowodować pobranie jej konfiguracji z usługi zewnętrznej. Możesz rozpocząć tworzenie kontrolerów za pomocą pakietu Go SDK, aby zintegrować własny kod ze środowiskiem wykonawczym Kubernetes.
Kiedy używać CRD?
Dokumenty CRD najlepiej nadają się do zarządzania danymi wewnętrznymi organizacji, zespołu lub projektu. Zostały zaprojektowane do reprezentowania jasno zdefiniowanych schematów, jako wartości statyczne lub jako deklaratywne interfejsy API wspierane przez niestandardową implementację kontrolera.
Zaawansowane funkcje umożliwiają implementację procedur sprawdzania poprawności pól w schemacie. Możesz również użyć finalizatorów do zarządzania usuwaniem obiektów i przyjęcia systemu wersjonowania do zarządzania zmianami w definicjach CRD.
CRD czasami nakładają się na Kubernetes ConfigMaps. Są to wbudowane obiekty do przechowywania ogólnych danych konfiguracyjnych powiązanych z aplikacjami. ConfigMap jest odpowiedni w przypadku korzystania z wartości w określonym miejscu w klastrze, takim jak zasobnik, który uzyskuje dostęp do ustawień bazy danych jako zmienne środowiskowe wstrzyknięte z ConfigMap.
CRD są przeznaczone do użytku, gdy dane muszą być obywatelami pierwszej klasy w klastrze. Możesz tworzyć wiele instancji typu zasobów CRD, wchodzić z nimi bezpośrednio w interakcję za pomocą Kubectl i tworzyć własne schematy strukturalne, które prowadzą użytkowników do wprowadzania prawidłowych wartości. Mogą być lepszym wyborem, gdy dane istnieją niezależnie od czegokolwiek innego w klastrze.
streszczenie
Niestandardowe definicje zasobów Kubernetes (CRD) definiują nowe typy obiektów, których można używać z interfejsem Kubernetes API i Kubectl. Każda CRD ma własny interfejs API z obsługą wersji, ma ustrukturyzowany schemat i może być używana do implementowania nowych funkcji w klastrze, jeśli jest obsługiwana przez kontroler towarzyszący.
CRD mogą czasem wydawać się skomplikowane i zarezerwowane dla zaawansowanych sytuacji. Tak nie może być. Proste CRD do przechowywania wartości statycznych w klastrze są łatwe do utworzenia, co ilustruje powyższy przykład „aplikacji niestandardowej”. Mogą być używane do przechowywania danych autonomicznych klastrów, dzięki czemu są traktowane na najwyższym poziomie w Kubernetes.
Ważne jest również, aby rozpoznać, gdzie nie pasują CRD. Obiekty wbudowane, takie jak ConfigMaps i Secrets, są zaprojektowane tak, aby pomieścić większość form konfiguracji, które będą używane bezpośrednio przez zasobniki aplikacji. Pisanie CRD, który definiuje schemat pliku konfiguracji aplikacji, jest zwykle niepotrzebne i trudniejsze do utrzymania w czasie, ponieważ nie będziesz korzystać z funkcji ConfigMap, takich jak automatyczne ciągłe aktualizacje i wstrzykiwanie zmiennych środowiskowych.
