Kubernetes: test selhání 30 % uzlů

Testování odolnosti Kubernetes: vypnutí 30 % uzlů v produkci

Tým vypnul 30 % uzlů v produkčním clusteru Kubernetes na základě OKD, aby identifikoval skutečné slabiny v odolnosti. Tím bylo možné otestovat reakci control plane, infrastrukturálních komponent a aplikací na vážný selhání infrastruktury. Výsledkem byly objevené problémy s webhook kontrolery a rozdělením replik, které se v běžné provozní době neukázaly.

Architektura testovaného clusteru

Cluster je nasazený v cloudu s třemi zónami dostupnosti, každá z nich představuje samostatný datový středisko s latencí pod 1 ms mezi zónami. Plně propojená topologie zajišťuje chování jako v lokální síti.

Klíčové komponenty:

• Národní vyrovnávač zátěže pro uživatelský provoz: backendy – 3 infrauzly s Ingress pody a Persistent Volume kontrolerem.
• Národní vyrovnávač zátěže pro API: backendy – 3 master uzly s control plane.
• Worker uzly: rovnoměrně rozloženy do zón, N kusů.

Tato topologie umožňuje simulovat výpadek zóny bez úplné ztráty clusteru, zároveň zachovává kvórum etcd (maximálně 1 master z 3).

Příprava na havarijní cvičení

Plán zahrnoval 8 kroků:

• Ověření základní funkčnosti clusteru a služeb.
• Vytvoření snímků master a infra uzlů pro rychlé vrácení zpět.
• Vypnutí všech uzlů jedné zóny (nebo 1 master, 1 infra + 30 % workerů).
• Monitorování 1–2 hodiny: zaznamenání selhání, statistiky, podpora týmům.
• Obnovení uzlů.
• Opětovné ověření.
• Dokončení.
• Zaznamenání úkolů.

Snímky jsou předností před etcd zálohami při cvičeních: rychlejší obnovení, nižší riziko. Worker uzly se nezaznamenávají – jejich stav je uložen v etcd. Infrauzly se zaznamenávají kvůli PV.

30 % je kompromis: realistické selhání (ověření anti-affinity, PDB, replikace), ale ne katastrofa. Kvórum master uzlů vydrží ztrátu 33 %.

Kritéria úspěchu:

• API je přístupné.
• Pody se vytvářejí/odstraňují.
• PV jsou přístupné.
• Služby fungují.
• Obnovení replik za 10–15 minut.
• Alerty jsou vyřešeny (kromě vypnutých uzlů).

Cvičení č. 1: vývojový cluster

Vypnuto 1/3: 1 master, 1 infra, ~80 worker jader. Vyrovnávač zátěže odstranil nefunkční backendy za minutu. API fungovalo, uzly byly ve stavu Unknown 300 sekund (výchozí timeout), poté not-ready/unreachable.

Pody se neobnovily 10 minut. Při vytváření:

Error from server (InternalError): error when creating "pod.yaml": Internal error occurred: failed calling webhook "mutate.kyverno.svc-fail": failed to call webhook: Post "https://infra-kyverno-svc.infra-kyverno.svc:443/mutate/fail?timeout=30s": dial tcp 10.128.4.174:9443: connect: connection refused

Kyverno (admission/mutation webhook) mělo po jednom Podu na typ, 2/3 byly v vypnuté zóně – Terminating. Bez webhooku změny nedosáhly etcd. Systémové namespace byly vyloučeny z Kyverno, aby se zabránilo dead-lock.

Zvýšili jsme repliky Kyverno. Ale eventy ukázaly: zákaz plánování kvůli nedostatku prostředků (není uvedeno v textu, ale z kontextu je zřejmé).

Problémy a řešení

Kyverno: přešli na více než 3 repliky na typ webhooku s rozložením podle zón.

Scheduler ban: ověřili resource quotas a limity v namespace.

V produkci (cvičení č. 2/3) stejné scénáře, ale s větším rozsahem: objevily se porušení PDB u služeb bez správné anti-affinity, zpoždění při migraci PV.

Aplikační týmy dostaly check-list:

• Minimálně 3 repliky.
• PodDisruptionBudget s minAvailable.
• TopologySpreadConstraints nebo nodeAffinity.
• Resource requests/limits.
• Liveness/readiness probes.

Co je důležité

• Vypnutí 30 % uzlů odhaluje problémy s webhooky a schedulingem, které v normálním provozu nejsou viditelné.
• Kyverno vyžaduje repliky >1 s rozložením podle zón.
• 300 sekundový timeout NotReady/Unreachable je standard, ale vyžaduje rezervu prostředků.
• Snímky infra/master jsou klíčem k bezpečným cvičením.
• Kompletní obnova: 10–15 minut na repliky + alerty.

Doporučení pro týmy

Pro vývojáře služeb:

• Nastavte PDB: minAvailable: 50 %.
• Použijte topologySpreadConstraints pro zóny.
• Requests/limits pro CPU/RAM – 80 % z pozorovaných špiček.
• Probes s timeoutem 5–10 s, threshold 3.

Pro administrátory Kubernetes:

• Repliky Kyverno/dalších webhooků >3, HA.
• Monitorování výběru etcd leadera.
• Plánování kapacity: +30 % rezerva.
• Automatické snímky před havarijními cvičeními.

Taková cvičení jsou nezbytná pro produkční clustery s více než 100 uzly.

— Editorial Team