Architektura klastra Kubernetes
- data
- kategoria
- Containers
- czytanie
- 2 min / 395 słów
Zanim zaczniemy rozkładać Kubernetes na konkretne procesy, warto najpierw zbudować prostą mapę całego systemu.
Najważniejszy podział to:
- control plane,
- data plane.
To dwa logiczne obszary klastra, które mają zupełnie inne zadania.
W dużym uproszczeniu:
Kubernetes cluster
├── Control Plane
│ ├── kube-apiserver
│ ├── etcd
│ ├── kube-scheduler
│ └── kube-controller-manager
│
└── Worker Nodes
├── kubelet
├── container runtime
├── networking
└── Pods
Nie oznacza to koniecznie, że control plane musi być jedną maszyną, a data plane drugą. To bardziej podział odpowiedzialności niż fizyczny podział serwerów.
Control Plane: część sterująca
Control plane odpowiada za zarządzanie stanem klastra.
To właśnie tutaj zapadają decyzje dotyczące tego:
- co powinno działać,
- gdzie powinno działać,
- czy obecny stan zgadza się z oczekiwanym,
- co należy zrobić, jeśli coś przestanie działać.
Można powiedzieć, że control plane nie wykonuje właściwej pracy aplikacyjnej, tylko koordynuje cały system.
Przykład:
Deklarujesz, że chcesz mieć trzy instancje aplikacji.
Control plane nie uruchamia sam tych kontenerów. Zamiast tego:
- zapisuje oczekiwany stan,
- sprawdza, czy istnieją trzy Pody,
- jeśli nie, inicjuje ich utworzenie,
- wybiera dla nich odpowiednie nody,
- obserwuje, czy wszystko działa zgodnie z deklaracją.
Data Plane: część wykonawcza
Data plane to miejsce, gdzie faktycznie uruchamiane są workloady.
Najczęściej są to worker nodes.
Na każdym node znajdują się komponenty, które odpowiadają za wykonanie decyzji control plane:
kubelet,- container runtime,
- komponenty sieciowe,
- uruchomione Pody.
Control plane może powiedzieć:
Pod X powinien działać na Node 2
ale to dopiero kubelet na Node 2 doprowadzi do tego, że runtime faktycznie uruchomi kontenery.
Desired state i actual state
To jeden z najważniejszych konceptów w całym Kubernetes.
Kubernetes stale porównuje:
- desired state, czyli stan oczekiwany,
- actual state, czyli stan rzeczywisty.
Przykład:
desired state: 3 Pody
actual state: 2 Pody
System wykrywa różnicę i próbuje ją skorygować.
Nie działa więc jak prosty skrypt typu:
uruchom kontener
koniec
Bardziej przypomina ciągły mechanizm:
sprawdź stan
|
v
porównaj z deklaracją
|
v
napraw różnicę
|
v
powtórz
To właśnie dlatego Kubernetes potrafi reagować na awarie.
Cluster i node
Całość nazywamy klastrem.
Klaster składa się z maszyn nazywanych nodes.
W typowym środowisku mamy:
- nody control plane,
- worker nodes.
W małych środowiskach laboratoryjnych jedna maszyna może pełnić obie role.
W produkcji często rozdziela się je dla większej niezawodności i bezpieczeństwa.
Pod jako jednostka wykonywana
Pod jest najmniejszą jednostką uruchamianą przez Kubernetes.
Nie jest jednak komponentem infrastruktury w takim samym sensie jak kubelet czy scheduler.
Pod jest workloadem, którym klaster zarządza.
W tej serii interesuje nas głównie to, jak infrastruktura klastra doprowadza do tego, że Pod pojawia się i działa.
Co zapamiętać
Najprostszy model jest taki:
Control Plane
-> decyduje i pilnuje stanu
Data Plane
-> wykonuje pracę
W kolejnych częściach rozłożymy oba obszary na konkretne komponenty i zobaczymy, za co każdy z nich odpowiada.