34. Proč Kubernetes a základní architektura clusteru

Úvod a kontext

Doposud jsme pracovali s jednotlivými kontejnery a docker-compose
soubory na jednom stroji. To funguje výborně pro vývoj nebo malé
nasazení, ale ve chvíli, kdy aplikace běží na desítkách serverů,
potřebuje se automaticky škálovat podle zátěže, musí se sama zotavit
z pádu jednoho uzlu a je třeba spravovat stovky kontejnerů napříč
clusterem, ruční docker run přestává stačit. Kubernetes (zkráceně
K8s) je open-source systém pro orchestraci kontejnerů, který tyto
problémy řeší automatizovaně.

Teorie

Proč orchestrace

Samotný Docker odpoví na otázku "jak spustit jeden kontejner na jednom
stroji". Orchestrátor odpovídá na širší otázky:

• Na kterém z mnoha serverů spustit tento kontejner? (scheduling)
• Co se stane, když server nebo kontejner spadne? (self-healing —
  automatický restart, přesun na jiný uzel)
• Jak kontejner najde jiný kontejner, i když se přesune na jiný
  server a dostane novou IP? (service discovery)
• Jak plynule nasadit novou verzi bez výpadku? (rolling update)
• Jak automaticky přidat/ubrat instance podle zátěže? (škálování)

Kubernetes tohle všechno řeší deklarativně: administrátor popíše
žádaný stav (např. "chci 5 běžících instancí této aplikace") a
Kubernetes se nepřetržitě stará o to, aby se skutečný stav shodoval
s žádaným — pokud instance spadne, automaticky nastartuje novou.

Architektura clusteru

Kubernetes cluster se skládá ze dvou typů uzlů:

Control plane (řídicí rovina) — "mozek" clusteru, typicky běží na
vyhrazených uzlech (v menších clusterech i sdíleně):

• kube-apiserver — jediný vstupní bod do clusteru. Veškerá
  komunikace (od kubectl, od ostatních komponent i mezi sebou)
  probíhá přes REST API tohoto serveru.
• etcd — distribuovaná key-value databáze, ve které je uložen
  veškerý stav clusteru (jaké objekty existují, jejich konfigurace).
  Je to jediný zdroj pravdy (source of truth) celého clusteru.
• kube-scheduler — rozhoduje, na který worker uzel se má nově
  vytvořený pod naplánovat, na základě dostupných zdrojů (CPU, paměť),
  afinit a dalších omezení.
• kube-controller-manager — běží smyčku kontrolérů, které
  neustále porovnávají žádaný a skutečný stav (např. "má být 5
  replik, běží jen 4 → naplánuj jednu další").

Worker uzly — stroje, na kterých skutečně běží kontejnery
aplikací:

• kubelet — agent běžící na každém worker uzlu, komunikuje s
  API serverem a stará se o to, aby kontejnery popsané v přiřazených
  podech skutečně běžely.
• container runtime — samotný engine, který kontejnery spouští
  (typicky containerd, dříve i přímo Docker Engine).
• kube-proxy — spravuje síťová pravidla na uzlu, aby fungovalo
  směrování provozu na Services (viz další lekce).

Textový diagram architektury:

                     ┌────────────────────────────┐
                     │        Control plane        │
                     │  kube-apiserver  ← kubectl   │
                     │  etcd                        │
                     │  kube-scheduler               │
                     │  kube-controller-manager      │
                     └───────────┬────────────────┘
                                 │ API (HTTPS)
        ┌────────────────────────┼────────────────────────┐
        │                         │                         │
 ┌──────▼──────┐          ┌──────▼──────┐          ┌──────▼──────┐
 │ Worker uzel 1│          │ Worker uzel 2│          │ Worker uzel 3│
 │ kubelet       │          │ kubelet       │          │ kubelet       │
 │ kube-proxy    │          │ kube-proxy    │          │ kube-proxy    │
 │ container     │          │ container     │          │ container     │
 │ runtime       │          │ runtime       │          │ runtime       │
 │ [pody...]     │          │ [pody...]     │          │ [pody...]     │
 └───────────────┘          └───────────────┘          └───────────────┘

kubectl — nástroj pro práci s clusterem

kubectl je CLI klient, který komunikuje s kube-apiserver. Prakticky
veškerá práce s Kubernetes probíhá skrz něj:

kubectl cluster-info          # základní info o clusteru
kubectl get nodes             # seznam worker uzlů
kubectl get pods              # seznam běžících podů v aktuálním namespace
kubectl get pods -A           # ve všech namespace
kubectl describe node uzel-1  # detail konkrétního uzlu

Pro lokální vyzkoušení bez skutečného clusteru existují nástroje jako
minikube nebo kind (Kubernetes in Docker), které rozběhnou
jednouzlový (nebo víceuzlový, u kind) cluster přímo na notebooku.

Praktický příklad

Ověření lokálního clusteru (např. po instalaci minikube start):

minikube start
kubectl get nodes
# NAME       STATUS   ROLES           AGE   VERSION
# minikube   Ready    control-plane   1m    v1.29.0

kubectl get pods -A
# ukáže systémové pody běžící v namespace kube-system,
# mimo jiné kube-apiserver, etcd, kube-scheduler jako pody samy o sobě —
# i control plane komponenty typicky běží jako kontejnery

Shrnutí

Kubernetes automatizuje to, co by administrátor jinak dělal ručně na
úrovni jednotlivých docker run příkazů napříč mnoha servery:
plánování, self-healing, service discovery, rolling update a
škálování — na základě deklarativně popsaného žádaného stavu. Cluster
tvoří control plane (apiserver, etcd, scheduler, controller manager) a
worker uzly (kubelet, kube-proxy, container runtime). Veškerá
komunikace prochází přes kube-apiserver, se kterým mluví kubectl.

Kontrolní otázky

1. Jaké tři konkrétní problémy řeší orchestrátor navíc oproti
   samotnému Dockeru?
2. Která komponenta control plane je jediným zdrojem pravdy o stavu
   clusteru a která je jediným vstupním bodem pro veškerou komunikaci?
3. Jaký je rozdíl v roli mezi kubelet a kube-scheduler?
4. Mini cvičení: nainstalujte minikube (nebo kind), spusťte
   minikube start a příkazem kubectl get pods -A vypište systémové
   pody běžící v kube-system — identifikujte mezi nimi pody
   odpovídající jednotlivým komponentám control plane.