41. Ladění a monitoring Kubernetes clusteru

Úvod a kontext

Předchozí lekce ukázaly, jak Kubernetes automaticky reaguje na
problémy — restartuje nezdravé Pody, škáluje podle zátěže, přeplánovává
na jiné uzly. Ale co když se Pod nespustí vůbec, zůstane trvale ve
stavu CrashLoopBackOff, nebo se aplikace nechová podle očekávání a
automatika sama problém nevyřeší? Pak potřebuje administrátor umět
diagnostikovat stav clusteru ručně — a zároveň mít monitoring,
který ho na problém upozorní dřív, než si ho všimnou uživatelé. Tato
lekce záměrně propojuje dvě témata: řemeslo ladění pomocí kubectl a
základy pozorování clusteru přes metriky, protože v praxi jde ruku v
ruce — monitoring vás na problém upozorní, kubectl vám pomůže zjistit
proč.

Teorie

Životní cyklus Podu a časté stavy

Pod prochází stavy Pending → ContainerCreating → Running, případně
Succeeded/Failed u jednorázových úloh. Nejčastější problematické
stavy, se kterými se administrátor setká:

• Pending trvale — scheduler nemůže Pod naplánovat (nedostatek
  zdrojů na žádném uzlu, nesplněné affinity/toleration požadavky).
• ImagePullBackOff / ErrImagePull — Kubernetes se nemůže dostat
  k image (špatný název, chybějící přihlašovací údaje k privátnímu
  registru, překlep ve verzi/tagu).
• CrashLoopBackOff — kontejner se opakovaně spouští a hned padá;
  Kubernetes mezi pokusy exponenciálně prodlužuje čekání.
• OOMKilled — kontejner byl zabit, protože překročil paměťový
  limit (resources.limits.memory).

Diagnostický postup

Základní diagnostická trojice pro libovolný problém s Podem:

kubectl get pods
# rychlý přehled — stav, počet restartů, stáří

kubectl describe pod web-abc123
# detailní informace: přiřazené zdroje, poslední stav kontejneru,
# a hlavně sekce "Events" na konci — obsahuje chronologický záznam
# událostí (naplánování, pull image, selhání probe, ...)

kubectl logs web-abc123
# standardní výstup aplikace v kontejneru

kubectl logs web-abc123 --previous
# logy z PŘEDCHOZÍHO běhu kontejneru — klíčové u CrashLoopBackOff,
# protože aktuální kontejner může být čerstvě nastartovaný bez logů

U Podu s víc kontejnery je nutné logy i describe cílit na konkrétní
kontejner (kubectl logs pod-jmeno -c nazev-kontejneru).

Interaktivní ladění

Pro hlubší diagnostiku lze do běžícího kontejneru vstoupit nebo spustit
dočasný ladicí Pod:

kubectl exec -it web-abc123 -- /bin/sh
# interaktivní shell uvnitř kontejneru (pokud image shell obsahuje)

kubectl port-forward pod/web-abc123 8080:8080
# přesměruje lokální port 8080 na port 8080 uvnitř Podu — užitečné
# pro ruční otestování HTTP endpointu bez nutnosti Service/Ingress

kubectl debug web-abc123 -it --image=busybox --target=web
# připojí dočasný debug kontejner ke sdílenému namespace Podu,
# užitečné u minimalistických produkčních images bez shellu

Events clusteru

Kromě describe lze zobrazit i všechny nedávné události v namespace
najednou, seřazené chronologicky — vhodné, když nevíte, který přesně
Pod je zdrojem problému:

kubectl get events --sort-by=.lastTimestamp

Monitoring: metriky jako doplněk k ad-hoc ladění

Ruční describe/logs funguje, když už problém nastal a víte, kde ho
hledat. Pro trvalý přehled o zdraví clusteru a včasné varování se
používá monitoring postavený na sběru metrik v čase:

• metrics-server — lehká komponenta poskytující aktuální (ne
  historická) data o CPU/paměti pro kubectl top a pro HPA z
  předchozí lekce.
• Prometheus — sbírá a ukládá metriky v čase z clusteru (kubelet,
  kube-state-metrics popisující stav objektů jako Deploymenty a Pody,
  i z aplikací samotných), s možností nad nimi psát alerty.
• Grafana — vizualizuje metriky nasbírané Prometheem do dashboardů
  (viz samostatná lekce o Prometheus/Grafana v modulu Observabilita).

kubectl top nodes
# NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
# node-1     420m         21%    2100Mi          54%

kubectl top pods
# NAME          CPU(cores)   MEMORY(bytes)
# web-abc123    15m          85Mi

kubectl top vyžaduje nainstalovaný metrics-server — bez něj vrátí
chybu, že metriky nejsou dostupné.

Kombinace obou přístupů

Typický reálný scénář: Grafana dashboard nebo alert upozorní, že
Deployment web má za poslední hodinu zvýšený počet restartů Podů.
Administrátor otevře kubectl get pods, najde konkrétní Pod v
CrashLoopBackOff, pomocí kubectl logs --previous zjistí chybovou
hlášku (např. selhání připojení k databázi), a kubectl describe
potvrdí, kdy problém začal. Monitoring řekne "něco je špatně a od
kdy", kubectl řekne "co přesně a proč".

Praktický příklad

# Pod visí v CrashLoopBackOff
kubectl get pods
# NAME          READY   STATUS             RESTARTS   AGE
# web-abc123    0/1     CrashLoopBackOff   5          3m

# zjištění příčiny z logů předchozího běhu
kubectl logs web-abc123 --previous
# Error: could not connect to database at db:5432: connection refused

# potvrzení v popisu Podu
kubectl describe pod web-abc123
# ...
# Events:
#   Warning  BackOff  probíhá restartování kontejneru "web"

# ověření, že problém je v Service/DB, ne v samotném web Podu
kubectl get pods -l app=db
kubectl logs db-0

# po opravě (např. databáze nebyla ještě připravená) sledování
# obnovy přes metriky
kubectl top pods
kubectl get pods --watch

Shrnutí

Diagnostika Kubernetes problémů kombinuje ad-hoc nástroje (kubectl get, describe, logs --previous, exec, port-forward, debug,
get events) pro zjištění konkrétní příčiny konkrétního incidentu a
trvalý monitoring (metrics-server pro kubectl top/HPA, Prometheus pro
historické metriky a alerty, Grafana pro vizualizaci) pro včasné
upozornění na problém dřív, než ho nahlásí uživatelé. Obě roviny se v
provozu doplňují — monitoring řekne, že a kdy něco selhalo, kubectl
pomůže zjistit proč.

Kontrolní otázky

1. Proč je u CrashLoopBackOff často užitečnější kubectl logs --previous než obyčejné kubectl logs?
2. Jaký je rozdíl mezi tím, co ukáže kubectl describe pod a co ukáže
   kubectl logs?
3. K čemu slouží metrics-server a proč bez něj nefunguje kubectl top
   ani HorizontalPodAutoscaler?
4. Mini cvičení: nasaďte Pod s úmyslně špatným názvem image (např.
   překlep ve verzi) a projděte celý diagnostický postup — kubectl get pods, describe, get events --sort-by=.lastTimestamp — dokud
   nenajdete v Events přesný důvod (ErrImagePull/ImagePullBackOff).