Lab 08 – Ladění podů

Lab 08 – Ladění podů

Infodiscovery

Cíl: diagnostikovat čtyři rozbité pody jen z výstupu clusteru. Kapitola: Postup při ladění

U každého případu si nejdřív vyrobte problém uvedeným příkazem a pak odpovězte na otázku dřív, než otevřete box. Postup je vždy get → describe → logs.

Případ 1 – image se nedá stáhnout

kubectl run broken1 --image=nginx:doesnotexist
kubectl get pod broken1

Otázka. V jakém je stavu a kde přesně vám cluster říká proč?

kubectl describe pod broken1 | tail -15

ErrImagePull, pak ImagePullBackOff, jak kubelet prodlužuje pauzy. V bloku Events stojí Failed to pull image ... manifest unknown. Žádné logy nejsou – kontejner nikdy nenastartoval, takže kubectl logs nemá co ukázat.

kubectl delete pod broken1

Případ 2 – kontejner pořád padá

kubectl run broken2 --image=busybox --restart=Always -- sh -c 'echo starting; exit 1'
sleep 30
kubectl get pod broken2

Otázka. Počítadlo RESTARTS roste. Získejte výstup pokusu, který už selhal, ne toho aktuálního.

kubectl logs broken2 --previous
kubectl describe pod broken2 | grep -A6 'Last State'

--previous čte log předchozí instance kontejneru. Last State: Terminated, Exit Code: 1 potvrzuje, že aplikace skončila sama – je to chyba aplikace, ne infrastruktury. Pauza BackOff roste až na pět minut.

kubectl delete pod broken2

Případ 3 – nedá se naplánovat

kubectl run broken3 --image=nginx:1.27 \
  --overrides='{"spec":{"containers":[{"name":"broken3","image":"nginx:1.27","resources":{"requests":{"memory":"900Gi"}}}]}}'
kubectl get pod broken3

Otázka. Zůstává Pending napořád. Která komponenta si stěžuje a jaký přesně uvádí důvod?

kubectl describe pod broken3 | tail -10
kubectl get events --sort-by=.lastTimestamp | tail -5

FailedScheduling od scheduleru: 0/4 nodes are available: 4 Insufficient memory. Pending vždy znamená, že scheduler pod neumístil – kapacita, taint nebo nenavázaný volume.

Doplňující. Doložte, že jde o requesty, ne o skutečnou spotřebu: kolik paměti je na worker01 opravdu volné?

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

Uzel je skoro nečinný. Scheduler počítá jen s requesty.

kubectl delete pod broken3

Případ 4 – běží, ale neodpovídá

kubectl run web --image=nginx:1.27
kubectl expose pod web --port 80 --name web-svc
kubectl label pod web run-                     # odeberte label, který Service vybírá

Otázka. Klient dostává timeout. Pod je Running a zdravý. Najděte poruchu, aniž byste se podívali do jediného logu.

kubectl get endpointslices -l kubernetes.io/service-name=web-svc
kubectl describe svc web-svc | grep -i selector
kubectl get pod web --show-labels

EndpointSlice nemá žádné adresy: Service vybírá run=web a pod už ten label nenese. Žádné endpointy = žádný provoz, a nikde se nic nezaloguje. Je to nejčastější porucha Service vůbec.

Opravte to a ověřte, že se endpoint vrátil.

kubectl label pod web run=web
kubectl get endpointslices -l kubernetes.io/service-name=web-svc
kubectl run tmp --image=busybox --restart=Never -it --rm -- \
  wget -qO- --timeout=3 web-svc | head -3

kubectl delete pod web; kubectl delete svc web-svc

Postup ještě jednou

kubectl get pod <jméno> -o wide                stav, uzel
kubectl describe pod <jméno>                   Events dole – čtěte první
kubectl logs <jméno> [--previous] [-c ctr]     co řekla aplikace
kubectl get events --sort-by=.lastTimestamp    širší kontext
kubectl exec -it <jméno> -- sh                 jen když pod běží