Control Plane w Kubernetes

kube-apiserver: centralny punkt komunikacji

kube-apiserver to jeden z najważniejszych komponentów Kubernetes.

To przez niego przechodzi komunikacja z klastrem.

Gdy wykonujesz:

kubectl get pods

albo:

kubectl apply -f app.yaml

kubectl nie rozmawia bezpośrednio z etcd, schedulerem czy kubeletem.

Rozmawia z API Serverem.

kubectl
   |
   v
kube-apiserver

API Server odpowiada m.in. za:

• przyjęcie żądania,
• uwierzytelnienie,
• autoryzację,
• walidację danych,
• udostępnienie API Kubernetes,
• zapis lub odczyt stanu klastra.

To centralny punkt, wokół którego zbudowana jest reszta systemu.

Dlaczego wszystko przechodzi przez API

Kubernetes jest systemem mocno opartym na API.

Scheduler, controllery i kubelety również obserwują stan właśnie przez API Server.

Dzięki temu poszczególne komponenty nie muszą bezpośrednio znać swoich implementacji.

Mają wspólny kontrakt: Kubernetes API.

To upraszcza architekturę i pozwala rozdzielać odpowiedzialności.

etcd: pamięć klastra

etcd jest rozproszonym magazynem typu key-value.

Kubernetes wykorzystuje go do przechowywania swojego stanu.

Można go traktować jako źródło prawdy dla control plane.

W etcd znajdują się informacje o obiektach, konfiguracji i stanie deklarowanym w klastrze.

Ważne jest jednak to, czego etcd nie robi.

etcd:

• nie uruchamia kontenerów,
• nie wybiera node,
• nie zarządza ruchem sieciowym,
• nie wykonuje logiki kontrolerów.

Jego rolą jest przechowywanie spójnych danych.

Jeśli stracisz etcd bez poprawnego backupu, możesz stracić wiedzę o stanie całego klastra.

Dlatego w self-managed Kubernetes jest to jeden z najbardziej krytycznych elementów do zabezpieczenia.

kube-scheduler: wybór node

Gdy powstaje Pod, może początkowo nie mieć przypisanego node.

Scheduler obserwuje takie Pody i wybiera dla nich odpowiednią maszynę.

Podczas wyboru może brać pod uwagę m.in.:

• dostępne CPU,
• pamięć,
• labels,
• affinity,
• anti-affinity,
• taints,
• tolerations,
• ograniczenia topologiczne.

W dużym uproszczeniu:

nowy Pod
   |
   v
scheduler
   |
   v
wybór Node

Bardzo ważne:

scheduler nie uruchamia kontenera.

On tylko podejmuje decyzję, na którym node Pod powinien się znaleźć.

Uruchomieniem zajmuje się później kubelet.

kube-controller-manager: pilnowanie rzeczywistości

kube-controller-manager uruchamia wiele kontrolerów.

Ich wspólnym zadaniem jest pilnowanie, aby rzeczywisty stan klastra zgadzał się z deklarowanym.

To klasyczny mechanizm reconciliation loop.

Przykład:

desired state: 3
actual state: 2

Kontroler zauważa różnicę i inicjuje działania prowadzące do utworzenia brakującego zasobu.

Potem ponownie sprawdza stan.

I robi to cały czas.

To właśnie kontrolery są jednym z głównych powodów, dla których Kubernetes potrafi reagować na awarie i samoczynnie wracać do oczekiwanego stanu.

cloud-controller-manager

W środowiskach chmurowych może działać również cloud-controller-manager.

Jego zadaniem jest integracja Kubernetes z infrastrukturą konkretnego providera.

Może odpowiadać np. za część operacji związanych z:

• nodami,
• load balancerami,
• informacją o infrastrukturze cloud.

W nowoczesnych środowiskach wiele funkcji związanych np. ze storage jest realizowanych przez osobne interfejsy, takie jak CSI.

Jak komponenty współpracują

Najprostszy obraz wygląda tak:

               ┌───────────────────────┐
               │    kube-apiserver     │
               └──────────┬────────────┘
                          │
             ┌────────────┼─────────────┐
             │            │             │
           etcd      scheduler    controller-manager

API Server jest centralnym punktem komunikacji.

etcd przechowuje stan.

Scheduler wybiera node.

Controller manager pilnuje, aby rzeczywistość zgadzała się z deklaracją.

Co zapamiętać

Control plane to nie jeden "mózg", ale zestaw komponentów.

Każdy ma osobną odpowiedzialność:

API Server          -> komunikacja
etcd                -> stan
Scheduler           -> wybór node
Controller Manager  -> reconciliation

Razem tworzą warstwę sterującą Kubernetes.