Jak działa platforma Kubernetes

Ukończone

Pomyślnie skonfigurowana instalacja platformy Kubernetes zależy od rzetelnej znajomości architektury systemu Kubernetes. W tym miejscu przyjrzymy się wszystkim składnikom tworzącym instalację platformy Kubernetes.

Co to jest klaster komputerowy?

Klaster to zbiór komputerów skonfigurowanych do współdziałania i wyświetlanych jako pojedynczy system. Komputery skonfigurowane w klastrze obsługują tego samego rodzaju zadania. Mogą one na przykład hostować witryny internetowe lub interfejsy API albo wykonywać zadania intensywnie korzystające z obliczeń.

Klaster używa scentralizowanego oprogramowania, które jest odpowiedzialne za planowanie i kontrolowanie tych zadań. Komputery w klastrze, na których są uruchamiane zadania, są nazywane węzłami, a komputery, na których działa oprogramowanie do planowania, są nazywane płaszczyznami sterowania.

Diagram of a computer cluster that shows how a task is distributed via the control plane to three nodes and the interaction between the nodes.

Architektura platformy Kubernetes

Przypomnij sobie z wcześniejszych lekcji, że orkiestrator to system, który wdraża aplikacje i zarządza nimi. Wiesz również, że klaster jest zestawem komputerów, które współpracują ze sobą i są postrzegane jako pojedynczy system. Platformy Kubernetes używa się jako oprogramowania do orkiestracji i obsługi klastrów, aby wdrażać aplikacje i reagować na zmiany potrzeb dotyczących zasobów obliczeniowych.

Diagram of a Kubernetes cluster architecture that shows the components installed on the control plane and the worker nodes.

Klaster Kubernetes zawiera co najmniej jedną płaszczyznę główną i co najmniej jeden węzeł roboczy. Wystąpienia płaszczyzn sterowania i węzłów roboczych mogą być urządzeniami fizycznymi, maszynami wirtualnymi lub wystąpieniami w chmurze. Domyślnym systemem operacyjnym hosta na platformie Kubernetes jest system Linux z domyślną obsługą obciążeń opartych na systemie Linux.

Obciążenia firmy Microsoft można również uruchamiać przy użyciu systemu Windows Server 2019 lub nowszego w węzłach klastra. Załóżmy na przykład, że usługa przetwarzania danych w aplikacji do śledzenia dronów jest zapisywana jako aplikacja platformy .NET 4.5 korzystająca z określonych wywołań interfejsu API systemu operacyjnego Windows. Tę usługę można wykonywać tylko w węzłach, w których działa system operacyjny Windows Server.

Teraz przyjrzyj się zarówno płaszczyznom sterowania, jak i węzłom procesu roboczego oraz oprogramowaniu, które działa na każdym z nich bardziej szczegółowo. Zrozumienie roli każdego składnika i miejsca, w którym każdy składnik jest uruchomiony na klastrze, pomaga w instalacji platformy Kubernetes.

Płaszczyzna sterowania platformy Kubernetes

Płaszczyzna sterowania platformy Kubernetes w klastrze Kubernetes obsługuje kolekcję usług, które zarządzają funkcjonalnością orkiestracji na platformie Kubernetes.

Z perspektywy uczenia się użycie jednej płaszczyzny sterowania w środowisku testowym podczas eksplorowania funkcji platformy Kubernetes ma sens. Jednak w przypadku wdrożeń produkcyjnych i w chmurze, takich jak usługa Azure Kubernetes Service (AKS), okaże się, że preferowana konfiguracja jest wdrożeniem o wysokiej dostępności z trzema do pięciu replikowanych płaszczyzn sterowania.

Uwaga

Fakt, że w płaszczyźnie sterowania jest uruchamiane określone oprogramowanie do utrzymania stanu klastra, nie wyklucza płaszczyzny z obsługi innych obciążeń obliczeniowych. Zwykle jednak należy upewnić się, że w płaszczyźnie sterowania nie są uruchamiane obciążenia niekrytyczne i obciążenia aplikacji użytkowników.

Węzeł Kubernetes

Węzeł w klastrze Kubernetes to miejsce, w którym są uruchamiane obciążenia obliczeniowe. Każdy węzeł komunikuje się z płaszczyzną sterowania za pośrednictwem serwera interfejsu API w celu informowania o zmianach stanu na węźle.

Usługi, które są uruchamiane na płaszczyźnie sterowania

Platforma Kubernetes zależy od kilku usług administracyjnych działających na płaszczyźnie sterowania. Te usługi zarządzają aspektami, takimi jak komunikacja między składnikami klastra, planowanie obciążeń i trwałość stanu klastra.

Diagram of a Kubernetes cluster architecture that shows the components installed on the control plane.

Następujące usługi tworzą płaszczyznę sterowania klastra Kubernetes:

  • Serwer interfejsu API
  • Magazyn zapasowy
  • Planista
  • Menedżer kontrolerów
  • Menedżer kontrolerów chmury

Co to jest serwer interfejsu API?

Serwer interfejsu API można traktować jako fronton na płaszczyźnie sterowania klastra Kubernetes. Cała komunikacja między składnikami klastra Kubernetes odbywa się za pomocą tego interfejsu API.

Na przykład jako użytkownik używasz aplikacji wiersza polecenia o nazwie kubectl , która umożliwia uruchamianie poleceń na serwerze interfejsu API klastra Kubernetes. Składnik dostarczający ten interfejs API nazywa się kube-apiserver. Możesz wdrożyć kilka wystąpień tego składnika, aby obsłużyć skalowanie w klastrze.

Ten interfejs API uwidacznia interfejs API RESTful, który umożliwia publikowanie poleceń lub plików konfiguracji opartych na języku YAML. YAML to czytelny dla człowieka standard serializacji danych dla języków programowania. Pliki YAML służą do definiowania zamierzonego stanu wszystkich obiektów w klastrze Kubernetes.

Załóżmy na przykład, że chcesz zwiększyć liczbę wystąpień aplikacji w klastrze. Należy zdefiniować nowy stan przy użyciu pliku opartego na języku YAML i przesłać ten plik do serwera interfejsu API. Serwer interfejsu API weryfikuje konfigurację, zapisuje ją w klastrze, a na koniec wprowadza skonfigurowany wzrost wdrożeń aplikacji.

Co to jest magazyn zapasowy?

Magazyn zapasowy jest magazynem trwałym, w którym klaster Kubernetes zapisuje ukończoną konfigurację. Rozwiązanie Kubernetes używa rozproszonego, niezawodnego magazynu par klucz-wartość o wysokiej dostępności, o nazwie etcd. Ten magazyn par klucz-wartość przechowuje bieżący stan, a także żądany stan wszystkich obiektów w klastrze.

W przypadku produkcyjnego klastra Kubernetes oficjalnie zaleca się posiadanie od trzech do pięciu zreplikowanych wystąpień bazy danych etcd w celu zapewnienia wysokiej dostępności.

Uwaga

etcd nie odpowiada za tworzenie kopii zapasowych danych. Zapewnienie efektywnego planu tworzenia kopii zapasowych danych przechowywanych w magazynie etcd należy do użytkownika.

Co to jest harmonogram?

Harmonogram jest składnikiem odpowiedzialnym za przypisywanie obciążeń we wszystkich węzłach. Harmonogram monitoruje klaster pod kątem nowo utworzonych kontenerów i przypisuje je do węzłów.

Co to jest menedżer kontrolerów?

Menedżer kontrolerów uruchamia i monitoruje kontrolery skonfigurowane dla klastra za pomocą serwera interfejsu API.

Platforma Kubernetes używa kontrolerów do śledzenia stanów obiektów w klastrze. Każdy kontroler działa w nieokreślonej pętli podczas oglądania i reagowania na zdarzenia w klastrze. Istnieją na przykład kontrolery do monitorowania węzłów, kontenerów lub punktów końcowych.

Kontroler komunikuje się z serwerem interfejsu API w celu określenia stanu obiektu. Jeśli bieżący stan różni się od żądanego stanu obiektu, kontroler podejmuje działania w celu zapewnienia żądanego stanu.

Załóżmy, że jeden z trzech kontenerów uruchomionych w klastrze przestaje odpowiadać i kończy się niepowodzeniem. W takim przypadku kontroler decyduje, czy jest wymagane uruchomienie nowych kontenerów w celu zapewnienia stałej dostępności aplikacji. Jeśli żądany stan jest taki, aby zawsze były uruchomione trzy kontenery, zostanie zaplanowane uruchomienie nowego kontenera.

Co to jest menedżer kontrolerów chmury?

Zadaniem menedżera kontrolerów chmury jest integracja z bazowymi technologiami chmury w klastrze, który działa w środowisku chmury. Tymi usługami mogą być na przykład moduły równoważenia obciążenia, kolejki i magazyn.

Usługi, które działają w węźle

Istnieje kilka usług uruchamianych w węźle Kubernetes w celu kontrolowania sposobu uruchamiania obciążeń.

Diagram of a Kubernetes cluster architecture that shows the components installed on a Kubernetes node.

Następujące usługi są uruchamiane w węźle Kubernetes:

  • Kubelet
  • Kube-proxy
  • Środowisko uruchomieniowe kontenera

Co to jest kubelet?

Usługa kubelet to agent, który działa w każdym węźle w klastrze i monitoruje żądania robocze z serwera interfejsu API. Usługa ta gwarantuje, że żądana jednostka pracy jest uruchomiona i w dobrej kondycji.

Usługa kubelet monitoruje węzły i zapewnia, że kontenery zaplanowane w każdym węźle działają zgodnie z oczekiwaniami. Narzędzie kubelet zarządza tylko kontenerami tworzonymi przez platformę Kubernetes. Nie umożliwia ona ponownego planowania pracy w innych węzłach, jeśli bieżący węzeł nie może uruchomić zadania.

Co to jest kube-proxy?

Składnik kube-proxy jest odpowiedzialny za sieć klastra lokalnego i działa w każdym węźle. Gwarantuje on, że każdy węzeł ma unikatowy adres IP. Składnik kube-proxy implementuje także reguły do obsługi routingu i równoważenia obciążenia ruchu przy użyciu narzędzi iptables i IPVS.

Składnik ten nie udostępnia usług DNS. Zalecany jest dodatek DNS do klastra oparty na serwerze CoreDNS — jest on instalowany domyślnie.

Co to jest środowisko uruchomieniowe kontenera?

Środowisko uruchomieniowe kontenera to podstawowe oprogramowanie, które uruchamia kontenery w klastrze Kubernetes. Środowisko uruchomieniowe jest odpowiedzialne za pobieranie, uruchamianie i zatrzymywanie obrazów kontenerów. Platforma Kubernetes obsługuje kilka środowisk uruchomieniowych kontenerów, w tym między innymi platformę Docker, kontenerd, rkt, CRI-O i frakti. Obsługa wielu typów środowisk uruchomieniowych kontenera jest oparta na interfejsie Container Runtime Interface (CRI). Wtyczka CRI umożliwia usłudze kubelet komunikację z dostępnym środowiskiem uruchomieniowym kontenera.

Domyślnym środowiskiem uruchomieniowym kontenera w usłudze AKS jest kontenerowe środowisko uruchomieniowe kontenera standardowego.

Interakcja z klastrem Kubernetes

Platforma Kubernetes zapewnia narzędzie wiersza polecenia o nazwie kubectl do zarządzania klastrem. Za pomocą narzędzia kubectl można wysyłać polecenia do płaszczyzny sterowania klastra lub pobierać informacje o wszystkich obiektach Kubernetes za pośrednictwem serwera interfejsu API.

Narzędzie kubectl używa pliku konfiguracji, który zawiera następujące informacje o konfiguracji:

  • Konfiguracja elementu Klaster określa nazwę klastra, informacje o certyfikacie i punkt końcowy interfejsu API usługi skojarzony z klastrem. Ta definicja umożliwia łączenie się z jednej stacji roboczej z wieloma klastrami.
  • Konfiguracja elementu Użytkownik określa użytkowników i ich poziomy uprawnień podczas uzyskiwania dostępu do skonfigurowanych klastrów.
  • Grupy konfiguracji kontekstu klastry i użytkownicy przy użyciu przyjaznej nazwy. Możesz na przykład używać nazw „dev-cluster” i „prod-cluster” w celu zidentyfikowania klastra programistycznego i klastra produkcyjnego.

Narzędzie kubectl możesz skonfigurować w celu łączenia się z wieloma klastrami, podając prawidłowy kontekst jako część składni wiersza polecenia.

Zasobniki klastra Kubernetes

Zasobnik reprezentuje pojedyncze wystąpienie aplikacji uruchamiane na platformie Kubernetes. Obciążenia uruchamiane na platformie Kubernetes to aplikacje konteneryzowane. W przeciwieństwie do środowiska platformy Docker nie można uruchamiać kontenerów bezpośrednio na platformie Kubernetes. Kontener należy spakować do obiektu Kubernetes zwanego zasobnikiem. Zasobnik jest najmniejszym obiektem, który można utworzyć na platformie Kubernetes.

Diagram of a pod with a website as the primary container.

Pojedynczy zasobnik może grupować kilka kontenerów. Jednak zasobnik zazwyczaj nie zawiera wielu wystąpień tej samej aplikacji.

Zasobnik zawiera informacje o konfiguracji magazynu udostępnionego i sieci oraz specyfikację sposobu uruchamiania spakowanych kontenerów. Szablony zasobników służą do definiowania informacji o zasobnikach uruchomionych w klastrze. Szablony zasobników są plikami zakodowanymi w języku YAML, które są używane ponownie i dołączane do innych obiektów w celu zarządzania wdrożeniami zasobników.

Diagram of pod with a website as the primary container and a supporting container. The node has both an assigned IP address and a localhost host address.

Załóżmy na przykład, że chcesz wdrożyć witrynę internetową w klastrze Kubernetes. Należy utworzyć plik definicji zasobnika, który określa konfigurację i obrazy kontenera aplikacji. Następnie należy wdrożyć plik definicji zasobnika na platformie Kubernetes.

Raczej nie spotyka się aplikacji internetowych, których jedynym składnikiem w rozwiązaniu jest witryna internetowa. Aplikacja internetowa zazwyczaj ma jakiś magazyn danych i inne elementy pomocnicze. Zasobniki Kubernetes również mogą zawierać więcej niż jeden kontener.

Załóżmy, że Twoja witryna używa bazy danych. Witryna internetowa jest spakowana w głównym kontenerze, a baza danych — w kontenerze pomocniczym. Wiele kontenerów komunikuje się ze sobą za pośrednictwem środowiska. Kontenery obejmują usługi dla systemu operacyjnego hosta, stosu sieciowego, przestrzeni nazw jądra, pamięci udostępnionej i woluminu magazynu. Zasobnik to środowisko piaskownicy, które udostępnia aplikacji wszystkie te usługi. Ponadto zasobnik umożliwia kontenerom współużytkowanie przypisanego adresu IP.

Ze względu na to, że potencjalnie można utworzyć wiele zasobników, które są uruchamiane w wielu węzłach, zidentyfikowanie ich może być trudne. Zasobniki można rozpoznawać i grupować przy użyciu etykiet ciągów, które określisz podczas definiowania zasobnika.

Cykl życia zasobnika platformy Kubernetes

Zasobniki platformy Kubernetes mają odrębne cykle życia, które wpływają na sposób wdrażania, uruchamiania i aktualizowania tych zasobników. Zaczynasz od przesłania manifestu YAML zasobnika do klastra. Utrwalony w klastrze plik manifestu definiuje żądany stan zasobnika. Harmonogram planuje zasobnik dla węzła w dobrej kondycji, który ma wystarczają ilość zasobów do uruchomienia zasobnika.

Diagram that shows the lifecycle of a pod.

Oto fazy cyklu życia zasobnika:

Faza opis
Oczekująca Zasobnik akceptuje klaster, ale nie wszystkie kontenery w klastrze są skonfigurowane lub gotowe do uruchomienia. Stan Oczekiwanie wskazuje czas oczekiwania zasobnika na zaplanowanie i czas spędzony na pobieraniu obrazów kontenerów.
Uruchomiono Zasobnik przechodzi do stanu uruchomienia, gdy wszystkie jego zasoby są gotowe.
Powodzenie Zasobnik przechodzi do stanu powodzenia, gdy wykona swoje zamierzone zadanie i zostanie pomyślnie uruchomiony.
Nie działa Zasobniki mogą nie działać prawidłowo z różnych powodów. Kontener w zasobniku może zakończyć się niepowodzeniem, co prowadzi do zakończenia wszystkich innych kontenerów, a może obraz nie został znaleziony podczas przygotowywania kontenerów zasobników. W takich typach przypadków zasobnik może przejść do stanu Niepowodzenie. Zasobniki mogą przejść do stanu niepowodzenia z stanu Oczekujące lub Uruchomione. Konkretna awaria może również umieścić zasobnik z powrotem w stanie oczekiwania.
Nieznane Jeśli nie można określić stanu zasobnika, zasobnik jest w stanie Nieznany.

Zasobniki są przechowywane w klastrze dopóki kontroler, płaszczyzna sterowania lub użytkownik ich jawnie nie usunie. Gdy zasobnik zostanie usunięty, nowy zasobnik zostanie utworzony natychmiast po. Nowy zasobnik jest uważany za całkowicie nowe wystąpienie oparte na manifeście zasobnika nie jest dokładną kopią, więc różni się od usuniętego zasobnika.

Klaster nie zapisuje stanu ani dynamicznie przypisywanej konfiguracji zasobnika. Na przykład identyfikator i adres IP zasobnika nie są zapisywane. Ten aspekt ma wpływ na sposób wdrażania zasobników i projektowania aplikacji. Nie możesz na przykład polegać na wstępnie przypisanych adresach IP swoich zasobników.

Stany kontenerów

Należy pamiętać, że fazy są podsumowaniem tego, w którym miejscu cyklu życia znajduje się zasobnik. Istnieją trzy stany, których używa klaster do śledzenia kontenerów w zasobniku podczas inspekcji zasobników:

Stan opis
Oczekiwanie Domyślny stan kontenera i stan, w którym znajduje się kontener, gdy nie jest uruchomiony ani zakończony.
Uruchomiono Kontener działa zgodnie z oczekiwaniami bez żadnych problemów.
Zakończony Kontener nie jest już uruchomiony. Stan ten występuje, gdy wszystkie zadania zostały ukończone lub doszło do awarii kontenera. Przyczyna i kod zakończenia są dostępne podczas debugowania obu przypadków.