Kubernetes jest wysoce konfigurowalny i rozbudowywalny. W rezultacie rzadko istnieje potrzeba robienia forka lub przesyłania poprawek do kodu projektu.

Ten przewodnik opisuje opcje dostosowywania klastra Kubernetesa. Jest skierowany do operatorów klastrów, którzy chcą zrozumieć, jak dostosować swój klaster Kubernetesa do potrzeb środowiska pracy. Programiści, którzy są potencjalnymi Deweloperami Platformy lub Współtwórcami projektu Kubernetes również uznają go za przydatny jako wprowadzenie do istniejących punktów rozszerzeń i wzorców oraz ich kompromisów i ograniczeń.

Podejścia do dostosowywania można ogólnie podzielić na konfigurację, która obejmuje tylko zmiany argumentów wiersza poleceń, lokalnych plików konfiguracyjnych lub zasobów API; oraz rozszerzenia, które obejmują uruchamianie dodatkowych programów, dodatkowych usług sieciowych lub obu. Ten dokument dotyczy przede wszystkim rozszerzeń.

Konfiguracja

Pliki konfiguracyjne i argumenty poleceń są udokumentowane w sekcji Materiały źródłowe (ang. Reference) dokumentacji online, z osobną stroną dla każdego pliku binarnego:

• kube-apiserver
• kube-controller-manager
• kube-scheduler
• kubelet
• kube-proxy

Argumenty poleceń i pliki konfiguracyjne mogą nie zawsze być możliwe do zmiany w hostowanej usłudze Kubernetesa lub w dystrybucji z zarządzaną instalacją. Kiedy są możliwe do zmiany, zazwyczaj mogą być zmieniane tylko przez operatora klastra. Dodatkowo, mogą ulegać zmianom w przyszłych wersjach Kubernetesa, a ich ustawienie może wymagać ponownego uruchomienia procesów. Z tych powodów należy je używać tylko wtedy, gdy nie ma innych opcji.

Wbudowane interfejsy API polityk, takie jak ResourceQuota, NetworkPolicy i Role-based Access Control ( RBAC), to natywne API Kubernetesa umożliwiające deklaratywną konfigurację polityk. Interfejsy API są zazwyczaj użyteczne nawet w przypadku hostowanych usług Kubernetesa i zarządzanych instalacji Kubernetesa. Wbudowane interfejsy API polityk przestrzegają tych samych konwencji co inne zasoby Kubernetesa, takie jak Pody. Gdy korzystasz z API polityk, które są stabilne, masz zapewnione określone wsparcie, zgodnie z ogólną polityką wsparcia API Kubernetesa. Z tych powodów interfejsy API polityk są zalecane zamiast plików konfiguracyjnych i argumentów poleceń, tam gdzie to możliwe.

Rozszerzenia

Rozszerzenia to komponenty oprogramowania, które rozszerzają i głęboko integrują się z Kubernetesem. Dostosowują go do obsługi nowych typów i nowych rodzajów sprzętu.

Wielu administratorów klastra korzysta z hostowanej lub dystrybucyjnej instancji Kubernetesa. Te klastry mają zainstalowane rozszerzenia. W rezultacie, większość użytkowników Kubernetesa nie będzie musiała instalować rozszerzeń, a jeszcze mniej użytkowników będzie musiało tworzyć nowe.

Wzorce rozszerzeń

Kubernetes jest zaprojektowany tak, aby można go było zautomatyzować poprzez pisanie programów klienckich. Każdy program, który odczytuje i/lub zapisuje do API Kubernetesa, może zapewnić użyteczną automatyzację. Automatyzacja może działać zarówno na klastrze, jak i poza nim. Postępując zgodnie z wytycznymi zawartymi w tym dokumencie, możesz napisać wysoce dostępną i solidną automatyzację. Automatyzacja generalnie działa z dowolnym klastrem Kubernetesa, w tym klastrami hostowanymi i zarządzanymi instalacjami.

Istnieje specyficzny wzorzec pisania programów klienckich, które dobrze współpracują z Kubernetesem, zwany wzorcem kontrolera. Kontrolery zazwyczaj odczytują .spec obiektu, ewentualnie wykonują pewne czynności, a następnie aktualizują .status obiektu.

Kontroler jest klientem API Kubernetesa. Gdy Kubernetes działa jako klient i wywołuje zdalną usługę, nazywa to webhookiem. Zdalna usługa nazywana jest backendem webhooka. Podobnie jak w przypadku niestandardowych kontrolerów, webhooki stanowią dodatkowy potencjalny punkt awarii.

W modelu webhook Kubernetes wykonuje żądanie sieciowe do zdalnej usługi. W alternatywnym modelu binarnej wtyczki, Kubernetes wykonuje program binarny. Wtyczki binarne są używane przez kubelet (na przykład, wtyczki magazynu CSI i wtyczki sieciowe CNI), oraz przez kubectl (zobacz Rozszerz kubectl za pomocą wtyczek).

Punkty rozszerzeń

Ten diagram pokazuje punkty rozszerzeń w klastrze Kubernetesa oraz klientów, którzy uzyskują do niego dostęp.

Klucz do rysunku

1. Użytkownicy często wchodzą w interakcję z API Kubernetesa za pomocą kubectl. Wtyczki dostosowują zachowanie klientów. Istnieją ogólne rozszerzenia, które mogą być stosowane do różnych klientów, a także specyficzne sposoby rozszerzania kubectl.

2. Serwer API obsługuje wszystkie żądania. Kilka typów punktów rozszerzeń w serwerze API umożliwia uwierzytelnianie żądań, blokowanie ich na podstawie ich treści, edytowanie treści oraz obsługę usuwania. Są one opisane w sekcji Rozszerzenia dostępu do API.

3. Serwer API obsługuje różne rodzaje zasobów. Wbudowane rodzaje zasobów, takie jak pods, są definiowane przez projekt Kubernetesa i nie mogą być modyfikowane. Przeczytaj Rozszerzenia API, aby dowiedzieć się więcej o rozszerzaniu API Kubernetesa.

4. Scheduler Kubernetesa decyduje, na których węzłach umieścić pody. Istnieje kilka sposobów na rozszerzenie harmonogramowania, które są opisane w sekcji Rozszerzenia harmonogramowania.

5. Duża część zachowań Kubernetesa jest realizowana przez programy zwane kontrolerami, które są klientami serwera API. Kontrolery są często używane w połączeniu z niestandardowymi zasobami. Przeczytaj łączenie nowych API z automatyzacją oraz Zmiana wbudowanych zasobów, aby dowiedzieć się więcej.

6. Kubelet działa na serwerach (węzłach) i pomaga podom wyglądać jak wirtualne serwery z własnymi adresami IP w sieci klastra. Wtyczki sieciowe umożliwiają różne implementacje sieciowania podów.

7. Możesz użyć Pluginów Urządzeń, aby zintegrować niestandardowy sprzęt lub inne specjalne lokalne dla węzła funkcje i udostępnić je Podom działającym w Twoim klastrze. Kubelet zawiera wsparcie dla pracy z pluginami urządzeń.

   Kubelet również montuje i odmontowuje volume dla podów i ich kontenerów. Możesz użyć wtyczek magazynowania, aby dodać obsługę nowych rodzajów magazynu (ang. storage) i innych typów wolumenów.

Schemat przepływu wyboru punktu rozszerzenia

Jeśli nie jesteś pewien, od czego zacząć, ten schemat blokowy może pomóc. Zwróć uwagę, że niektóre rozwiązania mogą obejmować kilka typów rozszerzeń.

---

Rozszerzenia klienta

Wtyczki do kubectl to oddzielne pliki binarne, które dodają lub zastępują działanie określonych poleceń. Narzędzie kubectl może również integrować się z wtyczkami uwierzytelniania. Te rozszerzenia wpływają tylko na lokalne środowisko danego użytkownika, dlatego nie mogą wymuszać polityk dla całego serwisu.

Jeśli chcesz rozszerzyć narzędzie kubectl, przeczytaj Rozszerzanie kubectl za pomocą wtyczek.

Rozszerzenia API

Definicje zasobów niestandardowych (ang. custom resource)

Rozważ dodanie Custom Resource do Kubernetesa, jeśli chcesz zdefiniować nowe kontrolery, obiekty konfiguracji aplikacji lub inne deklaratywne interfejsy API i zarządzać nimi za pomocą narzędzi Kubernetesa, takich jak kubectl.

Aby dowiedzieć się więcej o zasobach niestandardowych, zapoznaj się z przewodnikiem po zasobach niestandardowych.

Warstwa agregacji API

Możesz użyć warstwy agregacji API Kubernetesa, aby zintegrować API Kubernetesa z dodatkowymi usługami, takimi jak metryki.

Łączenie nowych interfejsów API z automatyzacją

Kombinacja niestandardowego API zasobu i pętli sterowania nazywana jest wzorcem controllers. Jeśli Twój kontroler zastępuje ludzkiego operatora wdrażającego infrastrukturę na podstawie pożądanego stanu, kontroler może również podążać za wzorcem operatora. Wzorzec operatora jest używany do zarządzania specyficznymi aplikacjami; zazwyczaj są to aplikacje, które utrzymują stan i wymagają uwagi w sposobie zarządzania nimi.

Możesz także tworzyć własne niestandardowe interfejsy API i pętle sterujące, które zarządzają innymi zasobami, takimi jak storage, lub definiować polityki (takie jak ograniczenia kontroli dostępu).

Zmiana wbudowanych zasobów

Kiedy rozszerzasz API Kubernetesa poprzez dodanie zasobów niestandardowych, dodane zasoby zawsze trafiają do nowych grup API. Nie możesz zastąpić ani zmienić istniejących grup API. Dodanie API nie pozwala bezpośrednio wpłynąć na zachowanie istniejących API (takich jak Pody), podczas gdy Rozszerzenia Dostępu do API mogą to zrobić.

Rozszerzenia dostępu do API

Gdy żądanie trafia do serwera API Kubernetesa, najpierw jest uwierzytelniane, następnie autoryzowane, i podlega różnym typom kontroli dostępu (niektóre żądania nie są uwierzytelniane i podlegają specjalnemu przetwarzaniu). Zobacz Kontrolowanie dostępu do API Kubernetesa aby dowiedzieć się więcej o tym procesie.

Każdy z kroków w przepływie uwierzytelniania / autoryzacji Kubernetesa oferuje punkty rozszerzeń.

Uwierzytelnianie

Uwierzytelnianie mapuje nagłówki lub certyfikaty we wszystkich żądaniach do nazwy użytkownika dla klienta składającego żądanie.

Kubernetes ma kilka wbudowanych metod uwierzytelniania, które obsługuje. Może również działać za proxy uwierzytelniającym, a także może wysyłać token z nagłówka Authorization: do zdalnej usługi w celu weryfikacji (przez authentication webhook ), jeśli te metody nie spełniają Twoich potrzeb.

Autoryzacja

Authorization określa, czy konkretni użytkownicy mogą odczytywać, zapisywać i wykonywać inne operacje na zasobach API. Działa na poziomie całych zasobów -- nie rozróżnia na podstawie dowolnych pól obiektu.

Jeśli wbudowane opcje autoryzacji nie spełniają Twoich potrzeb, webhook autoryzacji umożliwia wywołanie niestandardowego kodu, który podejmuje decyzję autoryzacyjną.

Dynamiczne sterowanie dostępem

Po autoryzacji żądania, jeśli jest to operacja zapisu, przechodzi również przez kroki Kontroli Przyjęć (ang. Admission Control). Oprócz wbudowanych kroków, istnieje kilka rozszerzeń:

• Webhook polityki obrazów ogranicza, jakie obrazy mogą być uruchamiane w kontenerach.
• Aby podejmować dowolne decyzje dotyczące kontroli dostępu, można użyć ogólnego webhooka dopuszczenia (ang. Admission webhook). Webhooki dopuszczenia mogą odrzucać żądania tworzenia lub aktualizacji. Niektóre webhooki modyfikują dane przychodzącego żądania, zanim zostaną one dalej obsłużone przez Kubernetesa.

Rozszerzenia infrastruktury

Wtyczki urządzeń

Device plugins pozwalają węzłowi na odkrywanie nowych zasobów Węzła (oprócz wbudowanych, takich jak CPU i pamięć) za pomocą Device Plugin.

Wtyczki magazynowe (ang. Storage plugins)

Wtyczki Container Storage Interface (CSI) dostarczają sposób na rozszerzenie Kubernetesa o wsparcie dla nowych rodzajów wolumenów. Wolumeny mogą być obsługiwane przez trwałe zewnętrzne magazyny danych, dostarczać pamięć ulotną lub oferować interfejs tylko do odczytu do informacji z wykorzystaniem paradygmatu systemu plików.

Kubernetes zawiera również wsparcie dla wtyczek FlexVolume, które są przestarzałe od wersji Kubernetes v1.23 (na rzecz CSI).

Wtyczki FlexVolume umożliwiają użytkownikom podłączanie typów woluminów, które nie są natywnie obsługiwane przez Kubernetesa. Kiedy uruchamiasz Pod, który polega na magazynie FlexVolume, kubelet wywołuje wtyczkę binarną, aby zamontować wolumin. Zarchiwizowany FlexVolume projekt wstępny zawiera więcej szczegółów na temat tego podejścia.

FAQ dotyczące Wtyczki Wolumenów Kubernetesa dla Dostawców Pamięci zawiera ogólne informacje na temat wtyczek do pamięci.

Wtyczki sieciowe

Twój klaster Kubernetesa potrzebuje wtyczki sieciowej, aby mieć działającą sieć Podów i wspierać inne aspekty modelu sieciowego Kubernetesa.

Wtyczki sieciowe pozwalają Kubernetesowi na współpracę z różnymi topologiami i technologiami sieciowymi.

Wtyczki dostawcy poświadczeń obrazu dla Kubeleta

Dostawcy poświadczeń obrazów dla kubeleta to wtyczki dla kubeleta, które dynamicznie pobierają poświadczenia rejestru obrazów. Poświadczenia te są następnie używane podczas pobierania obrazów z rejestrów obrazów kontenerów, które odpowiadają konfiguracji.

Wtyczki mogą komunikować się z zewnętrznymi usługami lub korzystać z lokalnych plików w celu uzyskania poświadczeń. W ten sposób kubelet nie musi mieć statycznych poświadczeń dla każdego rejestru i może obsługiwać różne metody i protokoły uwierzytelniania.

Aby uzyskać szczegóły dotyczące konfiguracji wtyczki, zobacz Konfigurowanie dostawcy poświadczeń obrazu kubelet.

Rozszerzenia harmonogramowania

Scheduler to specjalny typ kontrolera, który obserwuje pody i przypisuje pody do węzłów. Domyślny scheduler może być całkowicie zastąpiony, przy jednoczesnym dalszym korzystaniu z innych komponentów Kubernetesa, lub wielokrotne schedulery mogą działać jednocześnie.

Jest to duże przedsięwzięcie i prawie wszyscy użytkownicy Kubernetesa stwierdzają, że nie muszą modyfikować schedulera.

Możesz kontrolować, które wtyczki planowania są aktywne, lub kojarzyć zestawy wtyczek z różnymi nazwanymi profilami schedulera. Możesz również napisać własną wtyczkę, która integruje się z jednym lub więcej punktami rozszerzeń kube-schedulera.

Wreszcie, wbudowany komponent kube-scheduler obsługuje webhook, który pozwala zdalnemu backendowi HTTP (rozszerzenie schedulera) na filtrowanie i/lub priorytetyzowanie węzłów, które kube-scheduler wybiera dla poda.

Co dalej?

• Dowiedz się więcej o rozszerzeniach infrastruktury
  • Wtyczki Urządzeń
  • Wtyczki sieciowe
  • Wtyczki do przechowywania CSI storage plugins
• Dowiedz się więcej o wtyczkach kubectl
• Dowiedz się więcej o zasobach niestandardowych (ang. Custom Resources)
• Dowiedz się więcej o serwerach API rozszerzeń
• Dowiedz się więcej o dynamicznym kontrolowaniu dostępu
• Dowiedz się więcej o wzorcu Operatora