Lab 05 – První pohled na cluster

Cíl: zjistit, z čeho je cluster složený, a vidět rozdíl mezi imperativním a deklarativním přístupem. Tahák: kubectl

# 1 – kam a jako kdo jsem připojen?
kubectl cluster-info
kubectl config get-contexts
kubectl config view --minify | grep server

Zvykněte si na config get-contexts před čímkoli destruktivním. Většina produkčních nehod je příkaz napsaný na správný objekt ve špatném clusteru.

# 2 – stroje
kubectl get nodes -o wide
kubectl describe node control01 | head -40
kubectl describe node worker01 | grep -A6 'Allocated resources'

V describe node jsou důležité tři bloky: Conditions (je zdravý?), Taints (co tu odmítá běžet?) a Allocated resources (jak je plný?). Všimněte si, že se počítá z requestů podů, ne ze skutečného vytížení.

# 3 – co cluster provozuje sám pro sebe?
kubectl get pods -n kube-system -o wide

Většinu poznáte z diagramu architektury: API server, etcd, scheduler, controller manager, CoreDNS a jeden pod CNI na každém uzlu.

Imperativně

# 4 – akce, provedená jednou
kubectl run web01 --image nginx:1.27
kubectl get pods -o wide
kubectl run web01 --image nginx:1.27      # chyba: už existuje – není idempotentní
kubectl delete pod web01

Deklarativně

# 5 – manifest si nechte vygenerovat
cd ~
kubectl run web01 --image nginx:1.27 --dry-run=client -o yaml > web01.yaml
cat web01.yaml

--dry-run=client objekt sestaví lokálně a vypíše ho místo odeslání. Je to nejrychlejší cesta ke správnému manifestu – vygenerovat, pak upravit.

# 6 – nasaďte dvakrát
kubectl apply -f web01.yaml
kubectl apply -f web01.yaml          # „unchanged“ – idempotence
kubectl get pod web01

Druhý apply nic neudělá, protože požadovaný stav už odpovídá. Právě proto je apply bezpečný v pipeline a run se do ní nehodí.

# 7 – změňte soubor a nasaďte znovu
sed -i 's/nginx:1.27/nginx:1.28/' web01.yaml
kubectl apply -f web01.yaml
kubectl get pod web01 -o jsonpath='{.spec.containers[0].image}{"\n"}'

Úklid

# 8 – mažte stejným souborem, kterým jste vytvářeli
kubectl delete -f web01.yaml