Opisz architekturę Kubernetes: control plane vs worker nody i ich komponenty.

Question

IT Interview Practice · Accepted Answer

Klaster Kubernetes ma dwa rodzaje maszyn: **control plane** ("mózg", który podejmuje decyzje i przechowuje stan) oraz **worker nody** (gdzie faktycznie działają twoje Pody). Każdy ma niewielki zestaw dobrze zdefiniowanych komponentów.

## Ogólny obraz

```text
┌──────────────── CONTROL PLANE (mózg) ─────────────────────┐
│                                                            │
│   kube-apiserver ── drzwi frontowe; CAŁA komunikacja tędy  │
│        │                                                   │
│   etcd ───────── magazyn klucz-wartość: ŹRÓDŁO PRAWDY      │
│                  klastra (wszystkie obiekty i pożądany stan)│
│   kube-scheduler ── decyduje, na KTÓRYM nodzie działa Pod  │
│   controller-manager ── uruchamia pętle sterujące          │
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pody (twoje apki)│ │  └ Pody (twoje apki)│
└─────────────────────┘ └─────────────────────┘
```

## Komponenty control plane

```text
kube-apiserver        Jedyny punkt wejścia. Wystawia REST API; waliduje i
                      utrwala obiekty w etcd. kubectl, kontrolery i kubelety
                      rozmawiają TYLKO z apiserverem.
etcd                  Rozproszony, spójny magazyn klucz-wartość. Trzyma CAŁY
                      stan klastra (pożądany + bieżący). Utrata etcd = utrata klastra.
kube-scheduler        Śledzi Pody bez przypisanego noda i wybiera najlepszy node
                      (na podstawie żądań zasobów, affinity, taintów itp.).
kube-controller-      Uruchamia pętle sterujące: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints itd. Każda pętla prowadzi rzeczywisty → pożądany.
cloud-controller-     (W chmurze) integruje z dostawcą: load balancery, trasy,
manager               cykl życia nodów.
```

## Komponenty worker noda

```text
kubelet          Agent noda. Rozmawia z apiserverem, startuje/zatrzymuje kontenery przez
                 runtime i raportuje status Podów i noda. Sprawia, że rzeczywistość noda
                 pasuje do Podów mu przypisanych.
kube-proxy       Programuje sieć noda (iptables/IPVS), aby wirtualne IP Service
                 były load-balancowane do właściwych endpointów Podów.
container runtime Oprogramowanie, które faktycznie uruchamia kontenery (containerd, CRI-O).
```

## Jak "kubectl apply" przepływa przez system

```text
1. kubectl → kube-apiserver: "Chcę Deployment z 3 replikami"
2. apiserver waliduje i zapisuje obiekt do etcd
3. controller-manager (kontroler deployment→replicaset) widzi to, tworzy 3 obiekty Pod
4. scheduler widzi 3 nieprzypisane Pody, przypisuje każdy do noda (zapis przez apiserver)
5. kubelet każdego noda widzi swoje Pody, każe runtime pobrać obrazy i uruchomić kontenery
6. kube-proxy podłącza sieć Service, aby ruch dotarł do nowych Podów
Wszystko to pętla WATCH + RECONCILE pośredniczona przez apiserver.
```

```bash
kubectl get nodes                 # wypisz nody (control-plane + workery)
kubectl get pods -n kube-system   # zobacz komponenty control-plane / systemowe
kubectl get componentstatuses     # zdrowie kluczowych elementów control-plane
```

## Dlaczego to ważne

Zrozumienie podziału na control plane i worker nody — oraz roli każdego komponentu — jest tym, co zmienia Kubernetes z czarnej skrzynki w system, o którym potrafisz rozumować i który potrafisz obsługiwać, więc to kluczowa wiedza dla każdego inżyniera na poziomie middle lub wyżej. **Control plane** to mózg podejmujący decyzje: **kube-apiserver** to jedyne drzwi frontowe, przez które komunikuje się każdy komponent i użytkownik; **etcd** to spójny magazyn klucz-wartość, który trzyma cały stan klastra i jest źródłem prawdy (jego utrata oznacza utratę klastra); **scheduler** decyduje, na którym nodzie ląduje każdy nowy Pod; a **controller-manager** uruchamia pętle uzgadniania, które nieustannie prowadzą stan rzeczywisty ku pożądanemu. Na każdym **worker nodzie** **kubelet** to agent, który sprawia, że kontenery noda pasują do przypisanych mu Podów, **kube-proxy** programuje sieć, która sprawia, że wirtualne IP Service kierują do właściwych Podów, a **container runtime** (containerd, CRI-O) faktycznie uruchamia kontenery. Zobaczenie, jak pojedyncze `kubectl apply` przepływa przez ten system — apiserver do etcd, kontrolery tworzące obiekty, scheduler rozmieszczający Pody, kubelety startujące kontenery, kube-proxy podłączające sieć, wszystko jako pętle watch-and-reconcile — odsłania elegancki, spójny projekt stojący za platformą. Ten model mentalny to dokładnie to, czego potrzebujesz, aby zdebugować, dlaczego Pod utknął w stanie Pending (scheduler), dlaczego klaster nie odpowiada (apiserver/etcd) lub dlaczego Service nie kieruje ruchu (kube-proxy), co czyni go niezbędnym do obsługi i rozwiązywania problemów w prawdziwych klastrach.

Ogólny obraz

Komponenty control plane

Komponenty worker noda

Jak "kubectl apply" przepływa przez system

Dlaczego to ważne

Powiązane pytania