Popište architekturu Kubernetes: control plane vs worker nody a jejich komponenty.

Question

IT Interview Practice · Accepted Answer

Kubernetes cluster má dva druhy strojů: **control plane** ("mozek", který dělá rozhodnutí a ukládá stav) a **worker nody** (kde vaše Pody skutečně běží). Každý má malou sadu jasně definovaných komponent.

## Celkový obrázek

```text
┌──────────────── CONTROL PLANE (the brain) ────────────────┐
│                                                            │
│   kube-apiserver ── the front door; ALL comms go through it│
│        │                                                   │
│   etcd ───────── key-value store: the cluster's SOURCE OF  │
│                  TRUTH (all objects & desired state)       │
│   kube-scheduler ── decides WHICH node a new Pod runs on   │
│   controller-manager ── runs control loops (reconcilers)   │
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pods (your apps) │ │  └ Pods (your apps) │
└─────────────────────┘ └─────────────────────┘
```

## Komponenty control plane

```text
kube-apiserver        Jediný vstupní bod. Vystavuje REST API; validuje a
                      ukládá objekty do etcd. kubectl, controllery i kubelety
                      mluví POUZE s apiserverem.
etcd                  Distribuované, konzistentní key-value úložiště. Drží CELÝ
                      stav clusteru (požadovaný + aktuální). Ztráta etcd = ztráta clusteru.
kube-scheduler        Sleduje Pody bez přiřazeného nodu a vybírá nejlepší node
                      (podle resource requests, affinity, taints atd.).
kube-controller-      Běží řídicí smyčky: node controller, replikace (ReplicaSet),
manager               deployment, job, endpoints atd. Každá smyčka žene aktuální → požadované.
cloud-controller-     (Na cloudu) integruje s poskytovatelem: load balancery, routy,
manager               životní cyklus nodů.
```

## Komponenty worker nodu

```text
kubelet          Agent nodu. Mluví s apiserverem, spouští/zastavuje kontejnery přes
                 runtime a hlásí stav Podů a nodu. Zařizuje, aby realita nodu
                 odpovídala Podům, které mu byly přiřazeny.
kube-proxy       Programuje síťování nodu (iptables/IPVS), aby virtuální IP Service
                 byly load-balancovány na správné endpointy Podů.
container runtime Software, který skutečně spouští kontejnery (containerd, CRI-O).
```

## Jak "kubectl apply" prochází systémem

```text
1. kubectl → kube-apiserver: "Chci Deployment se 3 replikami"
2. apiserver validuje a zapíše objekt do etcd
3. controller-manager (deployment→replicaset controller) to uvidí, vytvoří 3 objekty Pod
4. scheduler vidí 3 nepřiřazené Pody, každý přiřadí na node (zapíše zpět přes apiserver)
5. kubelet každého nodu uvidí své Pody, řekne runtime stáhnout imagy a spustit kontejnery
6. kube-proxy zapojí síťování Service, aby provoz dorazil k novým Podům
Všechno je smyčka WATCH + RECONCILE zprostředkovaná apiserverem.
```

```bash
kubectl get nodes                 # vypíše nody (control-plane + workery)
kubectl get pods -n kube-system   # zobrazí control-plane / systémové komponenty
kubectl get componentstatuses     # zdraví klíčových částí control-plane
```

## Proč je to důležité

Pochopení rozdělení mezi control plane a worker nody — a role každé komponenty — je to, co mění Kubernetes z černé skříňky v systém, o kterém dokážete uvažovat a který umíte provozovat, takže je to klíčová znalost pro každého inženýra na střední a vyšší úrovni. **Control plane** je rozhodovací mozek: **kube-apiserver** jsou jediné vstupní dveře, přes které komunikuje každá komponenta i uživatel; **etcd** je konzistentní key-value úložiště, které drží celý stav clusteru a je zdrojem pravdy (jeho ztráta znamená ztrátu clusteru); **scheduler** rozhoduje, na který node každý nový Pod dopadne; a **controller-manager** běží smyčky slaďování, které průběžně ženou skutečný stav k požadovanému. Na každém **worker nodu** je **kubelet** agent, který zařizuje, aby kontejnery nodu odpovídaly přiřazeným Podům, **kube-proxy** programuje síťování, díky kterému virtuální IP Service směrují na správné Pody, a **container runtime** (containerd, CRI-O) skutečně spouští kontejnery. Vidět, jak jediný `kubectl apply` prochází tímto systémem — apiserver do etcd, controllery vytvářejí objekty, scheduler umisťuje Pody, kubelety spouštějí kontejnery, kube-proxy zapojuje síťování, vše jako smyčky watch-and-reconcile — odhaluje elegantní, konzistentní design za platformou. Tento myšlenkový model je přesně to, co potřebujete k ladění, proč Pod uvízl v Pending (scheduler), proč cluster neodpovídá (apiserver/etcd) nebo proč Service nesměruje (kube-proxy), což jej činí nepostradatelným pro provoz a řešení problémů reálných clusterů.

Celkový obrázek

Komponenty control plane

Komponenty worker nodu

Jak "kubectl apply" prochází systémem

Proč je to důležité

Související otázky