Základy Kubernetes
Základy Kubernetes
Vznikl v Googlu v roce 2014 na základech projektů Borg (2003) a Omega (2013), v roce 2015 byl darován nadaci CNCF.
Jedna velká myšlenka
Požadovaný stav vs. aktuální stav. Vy popíšete, co chcete; kontrolery to porovnávají se skutečností a jednají, dokud se oba stavy nesejdou. Všechno ostatní je jen variace na tuto smyčku.
graph LR
U[Vy: manifest] --> A[API server]
A --> E[(etcd – požadovaný stav)]
C[Kontroler] --> A
C --> C
C -->|create / delete| K[kubelet na uzlu]
K -->|hlásí aktuální stav| A
Architektura
graph TB
subgraph control01 [Control plane]
API[kube-apiserver]
ETCD[(etcd)]
SCH[kube-scheduler]
CM[kube-controller-manager]
end
subgraph worker0X [Worker uzel]
KL[kubelet]
KP[kube-proxy]
CRI[containerd]
end
API --- ETCD
SCH --- API
CM --- API
KL --- API
KP --- API
KL --- CRI
| Komponenta | Co dělá |
|---|---|
| kube-apiserver | jediné dveře do clusteru; REST + validace |
| etcd | ukládá požadovaný stav |
| kube-scheduler | vybírá uzel pro každý nový pod |
| kube-controller-manager | běží v něm reconciliation smyčky |
| kubelet | spouští a hlídá kontejnery na svém uzlu |
| kube-proxy | implementuje síťování Services na svém uzlu |
| containerd | container runtime (CRI) |
Zásuvné standardy
- CRI – runtime. Docker není CRI runtime a od verze 1.24 není podporován; tento cluster používá containerd.
- CNI – síťový plugin.
- CSI – storage drivery. Tento cluster žádný nemá, a proto se v labu na úložiště vytvářejí PersistentVolumes ručně.
Imperativně vs. deklarativně
kubectl run web01 --image nginx # imperativně: akce
kubectl apply -f pod.yaml # deklarativně: požadovaný stav
Imperativní přístup je na zkoušení. Všechno, co má přežít, se verzuje jako YAML
a nasazuje přes apply. Jen apply je idempotentní.
API je REST
| Operace | HTTP | kubectl |
|---|---|---|
| Create | POST | kubectl create -f |
| Read | GET | kubectl get / describe |
| Update | PUT/PATCH | kubectl apply -f / edit |
| Delete | DELETE | kubectl delete |