Jakie są główne komponenty architektury Kubernetes i za co każdy z nich jest odpowiedzialny?
Klaster Kubernetes składa się z płaszczyzny sterującej oraz zestawu maszyn roboczych, zwanych węzłami, które uruchamiają skonteneryzowane aplikacje w Podach. Każdy klaster potrzebuje co najmniej jednego węzła roboczego do uruchamiania Podów.
Koncepcyjnie Kubernetes jest deklaratywny: przesyłasz żądany stan do serwera API (przechowywany w itd.), a kontrolery uruchamiają ciągłe pętle uzgadniające, które obserwują różnice i działają, aby doprowadzić rzeczywisty stan do pożądanego stanu.
Komponenty płaszczyzny sterującej
Płaszczyzna kontroli podejmuje globalne decyzje dotyczące klastra (takie jak planowanie) i reaguje na zdarzenia w klastrze. W środowisku produkcyjnym zwykle działa na wielu komputerach, aby zapewnić wysoką dostępność.
- kube-apiserver — podstawowy komponent udostępniający API Kubernetes HTTP. Jest to frontend płaszczyzny kontroli i pojedynczy punkt kontaktowy: przez niego przepływają całe uwierzytelnianie, autoryzacja, sprawdzanie poprawności żądań oraz odczyty/zapisy stanu klastra. Skaluje się poziomo. W normalnych wdrożeniach jest to jedyny komponent Kubernetesa, który odczytuje i zapisuje stan klastra bezpośrednio w etcd; wszystkie pozostałe komponenty wchodzą w interakcję ze stanem za pośrednictwem serwera API.
- etcd — spójny i wysoce dostępny magazyn klucz-wartość używany jako magazyn zapasowy Kubernetesa dla wszystkich danych klastra: konfiguracji, stanu i metadanych. etcd jest obowiązkowe i stanowi jedyne źródło prawdy — jego utrata oznacza utratę całego stanu klastra, dlatego musi działać z kworum (nieparzysta liczba elementów) i regularnie tworzyć kopie zapasowe.
- kube-scheduler — wyszukuje Pody, które nie są jeszcze powiązane z węzłem i przypisuje każdy Pod do odpowiedniego węzła, biorąc pod uwagę zasoby, ograniczenia i zasady.
- kube-controller-manager — uruchamia kontrolery implementujące zachowanie Kubernetes API (np. kontroler węzła, kontroler zadań, kontroler EndpointSlice). Każdy sterownik obserwuje stan pożądany i uzgadnia z nim stan rzeczywisty.
- cloud-controller-manager (opcjonalnie) — integruje się z podstawowym dostawcą usług w chmurze, izolując logikę specyficzną dla chmury od podstawowych komponentów Kubernetes.
Komponenty węzła
Działają one na każdym węźle, utrzymując Pody w działaniu i zapewniając środowisko wykonawcze.
- kubelet — agent zapewniający działanie Podów, w tym ich kontenerów. Obserwuje serwer API pod kątem przypisań Podów, uruchamia kontenery za pośrednictwem środowiska wykonawczego, montuje woluminy, uruchamia sondy żywotności/gotowości i raportuje stan węzła.
- kube-proxy — implementuje sieć usług poprzez programowanie iptables lub reguł IPVS na węzłach, dzięki czemu ruch do Usługi jest przekazywany do właściwych adresów IP Pod. Jest oznaczony jako opcjonalny, ponieważ niektóre wtyczki CNI (np. Cilium w trybie eBPF) przejmują jego zadanie, ale w klastrze standardowym jest wymagany.
- Container runtime — oprogramowanie odpowiedzialne za uruchamianie kontenerów (containerd, CRI-O itp., poprzez interfejs CRI).
Dodatki
Dodatki rozszerzają funkcjonalność klastra: DNS klastra (domyślnie CoreDNS), internetowy interfejs użytkownika pulpitu nawigacyjnego, monitorowanie zasobów kontenera i rejestrowanie na poziomie klastra.
Wspólne działania następcze: cała komunikacja przepływa przez serwer API — program planujący, kontrolery i kubelety po prostu ją obserwują i reagują — co czyni serwer API krytycznym węzłem klastra.
