Lab 16 – Operace s uzly

Lab 16 – Operace s uzly

Infodiscovery

Cíl: bezpečně odstavit uzel kvůli údržbě a vrátit ho zpět. Kapitola: Uzly (nodes)

Všechno tady jsou pod kapotou tainty – viz lab 13, pokud si je chcete vyzkoušet ručně.

# příprava – ať máme čím hýbat
kubectl create deploy filler --image nginx:1.27 --replicas 6
kubectl get pods -o wide | sort -k7

Úkol 1. Zabraňte plánování nových podů na worker03, aniž byste narušili to, co tam běží. Očekávaný výsledek: kubectl get nodes ukazuje u worker03 Ready,SchedulingDisabled a jeho pody jsou netknuté.

kubectl cordon worker03
kubectl get nodes
kubectl get pods -o wide | grep worker03

Úkol 2. Doložte, že cordon funguje: naškálujte Deployment na 9 a ukažte, že na worker03 nepřistál žádný nový pod.

kubectl scale deploy filler --replicas 9
kubectl get pods -o wide | grep -c worker03      # stejný počet jako předtím

Úkol 3. Teď worker03 skutečně vyprázdněte, aby šel restartovat. Očekávaný výsledek: žádné aplikační pody na něm, všechny běží jinde.

kubectl drain worker03 --ignore-daemonsets --delete-emptydir-data
kubectl get pods -o wide | grep worker03         # nanejvýš pody DaemonSetu
kubectl get pods -o wide | sort -k7

Drain vystěhovává pod po podu a ReplicaSet každý znovu vytvoří jinde – proto aplikace nespadne, dokud má víc než jednu repliku.

Úkol 4. Vysvětlete, proč příkaz potřeboval --ignore-daemonsets. Ukažte, kterých podů se to týká.

kubectl get ds -A
kubectl get pods -A -o wide --field-selector spec.nodeName=worker03

Pody DaemonSetu patří k uzlu samotnému. Vystěhovat je nemá smysl – kontroler by je okamžitě vytvořil znovu na tomtéž uzlu.


Úkol 5. Vraťte worker03 do provozu a rozprostřete zátěž zpět na všechny tři workery. Očekávaný výsledek: kubectl get pods -o wide ukazuje pody i na worker03.

kubectl uncordon worker03
kubectl get pods -o wide | sort -k7      # na worker03 pořád nic!
kubectl rollout restart deploy/filler
kubectl get pods -o wide | sort -k7

Tohle lidé pletou: uncordon nerozprostírá. Kubernetes běžící pod nikdy nepřesouvá. Rozprostření znamená pody nahradit, což dělá rollout restart.


Úkol 6. Vytvořte pod, který nespravuje žádný kontroler, přišpendlený na worker03, a zkuste uzel vyprázdnit znovu. Očekávaný výsledek: drain odmítne a řekne proč.

kubectl run orphan --image nginx:1.27 --overrides='{"spec":{"nodeName":"worker03"}}'
kubectl drain worker03 --ignore-daemonsets
# error: cannot delete Pods not managed by ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet
kubectl drain worker03 --ignore-daemonsets --force
kubectl get pod orphan                    # pryč – nikam se nepřeplánoval
kubectl uncordon worker03

--force pod nepřesune. Smaže ho. Holý pod nemá nic, co by ho vytvořilo znovu, což je celý argument proti holým podům v produkci.


Úkol 7. Zjistěte, kolik CPU a paměti je na worker01 aktuálně requestováno a jak se to má ke skutečnému vytížení.

kubectl describe node worker01 | grep -A6 'Allocated resources'
kubectl top node worker01

Scheduler se dívá jen na první číslo. Uzel může být téměř nečinný a pody přesto odmítat.

Úklid

kubectl delete deploy filler
kubectl get nodes                          # všechny Ready, žádný SchedulingDisabled
Varování

kubectl delete node worker03 smaže jen objekt v API. Kubelet běží dál a znovu se zaregistruje. Skutečné odebrání je drain → delete node → kubeadm reset na stroji.