Architektura klastra

Klaster Kubernetesa składa się z warstwy sterowania oraz zestawu maszyn roboczych, zwanych węzłami, które uruchamiają konteneryzowane aplikacje. Każdy klaster potrzebuje co najmniej jednego węzła roboczego, aby obsługiwać Pody.

Węzeł roboczy hostuje Pody, które są komponentami workload aplikacji. Warstwa sterowania zarządza węzłami roboczymi oraz Podami w klastrze. W środowiskach produkcyjnych, warstwa sterowania zazwyczaj działa na wielu komputerach, a klaster zazwyczaj działa na wielu węzłach, zapewniając odporność na awarie i wysoką dostępność.

Ten dokument opisuje różne komponenty, które musisz posiadać, aby mieć kompletny i działający klaster Kubernetesa.

About this architecture

Diagram na Rysunku 1 przedstawia przykładową referencyjną architekturę klastra Kubernetesa. Rzeczywisty rozkład komponentów może różnić się w zależności od specyficznych konfiguracji klastra i wymagań.

Na schemacie każdy węzeł uruchamia komponent kube-proxy. Potrzebujesz komponentu sieciowego proxy na każdym węźle, aby zapewnić, że API Service i związane z nim zachowania są dostępne w sieci klastra. Niektóre wtyczki sieciowe jednak dostarczają własne, zewnętrzne implementacje proxy. Kiedy korzystasz z tego rodzaju wtyczki sieciowej, węzeł nie musi uruchamiać kube-proxy.

Komponenty warstwy sterowania

Komponenty warstwy sterowania podejmują globalne decyzje dotyczące klastra (na przykład harmonogramowanie), a także wykrywają i reagują na zdarzenia klastra (na przykład uruchamianie nowego poda gdy nie zgadza się liczba replik Deploymentu.

Elementy warstwy sterowania mogą być uruchamiane na dowolnej maszynie w klastrze. Jednakże, dla uproszczenia, skrypty instalacyjne zazwyczaj uruchamiają wszystkie elementy warstwy sterowania na tej samej maszynie i nie uruchamiają kontenerów użytkownika na tej maszynie. Zobacz Tworzenie klastrów o wysokiej dostępności za pomocą kubeadm dla przykładowej konfiguracji warstwy sterowania, która działa na wielu maszynach.

kube-apiserver

Serwer API jest składnikiem warstwy sterowania Kubernetesa, który udostępnia API. Server API służy jako front-end warstwy sterowania Kubernetesa.

Podstawową implementacją serwera API Kubernetesa jest kube-apiserver. kube-apiserver został zaprojektowany w taki sposób, aby móc skalować się horyzontalnie — to oznacza, że zwiększa swoją wydajność poprzez dodawanie kolejnych instancji. Można uruchomić kilka instancji kube-apiserver i rozkładać między nimi ruch od klientów.

etcd

Magazyn typu klucz-wartość (key/value store), zapewniający spójność i wysoką dostępność, używany do przechowywania wszystkich danych o klastrze Kubernetesa.

Jeśli Twój klaster Kubernetesa używa etcd do przechowywania swoich danych, upewnij się, że masz opracowany plan tworzenia kopii zapasowych tych danych.

Szczegółowe informacje na temat etcd można znaleźć w oficjalnej dokumentacji.

kube-scheduler

Składnik warstwy sterowania, który śledzi tworzenie nowych podów i przypisuje im węzły, na których powinny zostać uruchomione.

Przy podejmowaniu decyzji o wyborze węzła brane pod uwagę są wymagania indywidualne i zbiorcze odnośnie zasobów, ograniczenia wynikające z polityk sprzętu i oprogramowania, wymagania affinity i anty-affinity, lokalizacja danych, zależności między zadaniami i wymagania czasowe.

kube-controller-manager

Składnik warstwy sterowania odpowiedzialny za uruchamianie kontrolerów.

Z poziomu podziału logicznego, każdy kontroler jest oddzielnym procesem, ale w celu zmniejszenia złożoności, wszystkie kontrolery są skompilowane do jednego programu binarnego i uruchamiane jako jeden proces.

Istnieje wiele różnych typów kontrolerów. Niektóre z nich to:

• Kontroler węzłów (ang. Node controller): Odpowiada za zauważanie i reagowanie, gdy węzły przestają działać.
• Kontroler zadania (ang. Job controller): Monitoruje obiekty zadania (Job), które reprezentują jednorazowe zadania, a następnie tworzy Pody, aby wykonały te zadania do końca.
• Kontroler EndpointSlice: Uzupełnia obiekty EndpointSlice (aby zapewnić połączenie między Services a Pods).
• Kontroler ServiceAccount: Tworzenie domyślnych obiektów ServiceAccount dla nowych przestrzeni nazw.

Powyższa lista nie jest wyczerpującą.

cloud-controller-manager

Element składowy warstwy sterowania Kubernetesa, który zarządza usługami realizowanymi po stronie chmur obliczeniowych. Cloud controller manager umożliwia połączenie Twojego klastra z API operatora usług chmurowych i rozdziela składniki operujące na platformie chmurowej od tych, które dotyczą wyłącznie samego klastra.

Manager 'cloud-controller' uruchamia tylko kontrolery specyficzne dla dostawcy chmury. Jeśli uruchamiasz Kubernetesa w swojej siedzibie lub w środowisku do nauki na swoim komputerze osobistym, klaster nie posiada managera 'cloud-controller'.

Podobnie jak kube-controller-manager, cloud-controller-manager łączy kilka logicznie niezależnych pętli kontrolnych w jedną binarkę, którą uruchamiasz jako pojedynczy proces. Możesz go skalować horyzontalnie (uruchamiając więcej niż jedną kopię), aby poprawić wydajność lub pomóc w tolerowaniu awarii.

Następujące kontrolery mogą mieć zależności od dostawcy chmury:

• Kontroler węzłów (ang. Node controller): Do sprawdzania dostawcy chmury w celu ustalenia, czy węzeł został usunięty w chmurze po tym, jak przestaje odpowiadać.
• Kontroler tras (ang. Route controller): Do konfiguracji tras w podstawowej infrastrukturze chmurowej.
• Kontroler usługi (ang. Service controller): Do tworzenia, aktualizowania i usuwania load balancerów dostawcy chmury.

---

Komponenty węzła

Komponenty węzła działają na każdym węźle, utrzymując działające pody i zapewniając środowisko wykonawcze Kubernetesa.

kubelet

Agent, który działa na każdym węźle klastra. Odpowiada za uruchamianie kontenerów w ramach poda.

kubelet korzysta z dostarczanych (różnymi metodami) PodSpecs i gwarantuje, że kontenery opisane przez te PodSpecs są uruchomione i działają poprawnie. Kubelet nie zarządza kontenerami, które nie zostały utworzone przez Kubernetesa.

kube-proxy (opcjonalne)

kube-proxy to proxy sieciowe, które uruchomione jest na każdym węźle klastra i uczestniczy w tworzeniu serwisu.

kube-proxy utrzymuje reguły sieciowe na węźle. Dzięki tym regułom sieci na zewnątrz i wewnątrz klastra mogą komunikować się z podami.

kube-proxy używa warstwy filtrowania pakietów dostarczanych przez system operacyjny, o ile taka jest dostępna. W przeciwnym przypadku, kube-proxy samo zajmuje sie przekazywaniem ruchu sieciowego.

Jeśli używasz wtyczki sieciowej, która samodzielnie implementuje przekazywanie pakietów dla Usług i zapewnia równoważne działanie do kube-proxy, to nie musisz uruchamiać kube-proxy na węzłach w swoim klastrze.

Środowisko uruchomieniowe kontenera

Podstawowy komponent umożliwiający efektywne uruchamianie kontenerów w Kubernetesie. Odpowiada za zarządzanie uruchamianiem i cyklem życia kontenerów w środowisku Kubernetes.

Kubernetes obsługuje różne container runtimes: containerd, CRI-O oraz każdą implementację zgodną z Kubernetes CRI (Container Runtime Interface).

Dodatki

Dodatki (ang. Addons) wykorzystują zasoby Kubernetesa (DaemonSet, Deployment, itp.) do wdrażania funkcji klastra. Ponieważ zapewniają one funkcje na poziomie klastra, zasoby te należą do przestrzeni nazw kube-system.

Wybrane dodatki są opisane poniżej; aby uzyskać rozszerzoną listę dostępnych dodatków, zobacz Dodatki.

DNS

Podczas gdy inne dodatki nie są ściśle wymagane, wszystkie klastry Kubernetes powinny mieć DNS klastra, ponieważ wiele elementów na nim polega.

Cluster DNS to serwer DNS, będący uzupełnieniem dla innych serwerów DNS w Twoim środowisku, który obsługuje rekordy DNS dla usług Kubernetes.

Kontenery uruchamiane przez Kubernetesa automatycznie uwzględniają ten serwer DNS w swoich wyszukiwaniach DNS.

Interfejs Web UI (Dashboard)

Dashboard to uniwersalny interfejs internetowy dla klastrów Kubernetesa. Umożliwia użytkownikom zarządzanie i rozwiązywanie problemów z aplikacjami działającymi w klastrze, a także samym klastrem.

Monitorowanie zasobów kontenerów

Monitorowanie Zasobów Kontenera rejestruje ogólne metryki dotyczące kontenerów w centralnej bazie danych i udostępnia interfejs użytkownika do przeglądania tych danych.

Rejestrowanie na poziomie klastra

Mechanizm logowania na poziomie klastra jest odpowiedzialny za zapisywanie logów z kontenerów w centralnym magazynie logów z interfejsem do przeszukiwania/przeglądania.

Wtyczki sieciowe

Wtyczki sieciowe są komponentami oprogramowania, które implementują specyfikację interfejsu sieciowego kontenera (CNI). Są odpowiedzialne za przydzielanie adresów IP do podów i umożliwianie im komunikacji między sobą w klastrze.

Warianty architektury

Podczas gdy podstawowe komponenty Kubernetesa pozostają niezmienne, sposób ich wdrażania i zarządzania może się różnić. Zrozumienie tych wariacji jest kluczowe dla projektowania i utrzymania klastrów Kubernetesa, które spełniają określone potrzeby operacyjne.

Opcje wdrażania warstwy sterowania

Komponenty warstwy sterowania mogą być wdrażane na kilka sposobów:

Tradycyjna implementacja: : Komponenty warstwy sterowania działają bezpośrednio na dedykowanych maszynach lub maszynach wirtualnych (VM), często zarządzane jako usługi systemd.

Statyczne Pody: : Komponenty warstwy sterowania są wdrażane jako statyczne Pody, zarządzane przez kubelet na określonych węzłach. Jest to powszechne podejście stosowane przez narzędzia takie jak kubeadm.

Samodzielnie hostowane : Warstwa sterowania działa jako Pody wewnątrz samego klastra Kubernetes, zarządzane przez Deploymenty i StatefulSety lub inne obiekty Kubernetesa.

Zarządzane usługi Kubernetesa: Dostawcy usług chmurowych zazwyczaj ukrywają warstwę kontrolną, zarządzając jej elementami w ramach swoich usług.

Rozważania dotyczące umieszczania workloadów

Umiejscowienie workloadów, w tym komponentów warstwy sterowania, może różnić się w zależności od wielkości klastra, wymagań dotyczących wydajności i polityk operacyjnych:

• W mniejszych klastrach lub klastrach deweloperskich, komponenty warstwy sterowania i workloady użytkowników mogą działać na tych samych węzłach.
• Większe klastry produkcyjne często dedykują określone węzły dla komponentów warstwy sterowania, oddzielając je od workloadów użytkowników.
• Niektóre organizacje uruchamiają krytyczne dodatki lub narzędzia monitorujące na węzłach warstwy sterowania.

Narzędzia do zarządzania klastrem

Narzędzia takie jak kubeadm, kops i Kubespray oferują różne podejścia do wdrażania i zarządzania klastrami, z których każde ma własną metodę rozmieszczenia i zarządzania komponentami.

Dostosowywanie i rozszerzalność

Architektura Kubernetesa pozwala na szeroką konfigurację:

• Niestandardowe schedulery mogą być wdrażane do pracy wraz z domyślnym schedulerem Kubernetesa lub aby całkowicie go zastąpić.
• Serwery API mogą być rozszerzane za pomocą CustomResourceDefinitions i agregacji API.
• Dostawcy chmury mogą mocno integrować się z Kubernetesem używając cloud-controller-manager.

Elastyczność architektury Kubernetesa umożliwia organizacjom dostosowanie ich klastrów do specyficznych potrzeb, balansując czynniki takie jak złożoność operacyjna, wydajność i narzut na zarządzanie.

Co dalej?

Dowiedz się więcej na temat:

• Węzły i ich komunikacja z warstwą sterowania.
• Kontrolery Kubernetesa.
• kube-scheduler, czyli domyślny scheduler dla Kubernetesa.
• Oficjalna dokumentacja Etcd.
• Wiele środowisk uruchomieniowych kontenerów w Kubernetesie.
• Integracja z dostawcami chmury za pomocą cloud-controller-manager.
• Polecenia kubectl.