Kubernetes: test na awarię 30% węzłów

Testowanie odporności Kubernetes: wyłączanie 30% węzłów w środowisku produkcyjnym

Zespół wyłączył 30% węzłów w produkcyjnym klastrze Kubernetes opartym na OKD, aby wykryć rzeczywiste problemy z odpornością. Pozwoliło to przetestować reakcję płaszczyzny sterującej, komponentów infrastruktury oraz usług aplikacyjnych na poważny awarię infrastruktury. W wyniku ujawniły się problemy z kontrolerami webhook i dystrybucją replik, które nie były widoczne w normalnej eksploatacji.

Architektura testowanego klastra

Klaster został wdrożony w chmurze z trzema strefami dostępności, każda — oddzielny centrum danych z opóźnieniem poniżej 1 ms między strefami. Pełna topologia połączeń zapewnia zachowanie jak w lokalnej sieci.

Kluczowe komponenty:

• Load Balancer dla ruchu użytkownika: backendy — 3 węzły infrastruktury z podami Ingress i kontrolerem Persistent Volume.
• Load Balancer dla API: backendy — 3 węzły master z płaszczyzną sterującą.
• Węzły worker: równomiernie rozłożone po strefach, N sztuk.

Taka topologia umożliwia symulację awarii strefy bez utraty całego klastra, zachowując kworum etcd (maksymalnie 1 master z 3).

Przygotowanie do ćwiczeń awaryjnych

Plan obejmował 8 kroków:

• Sprawdzenie podstawowej funkcjonalności klastra i usług.
• Tworzenie snapshotów węzłów master i infrastruktury do szybkiego cofnięcia.
• Wyłączenie wszystkich węzłów jednej strefy (lub 1 master, 1 infra + 30% worker).
• Monitorowanie przez 1–2 godziny: rejestracja błędów, statystyki, wsparcie zespołów.
• Odtworzenie węzłów.
• Ponowne sprawdzenie.
• Zakończenie.
• Dokumentacja zadań.

Snapshoty są preferowane przed kopiami etcd podczas ćwiczeń: szybsze cofnięcie, mniejsze ryzyko. Węzły worker nie są backupowane — stan jest w etcd. Węzły infrastruktury są backupowane ze względu na PV.

30% to kompromis: realistyczny scenariusz awarii (test anti-affinity, PDB, replikacji), ale nie katastrofa. Kworum węzłów master wytrzymuje utratę 33%.

Kryteria sukcesu:

• API dostępne.
• Pod-y tworzone/usuwane.
• PV dostępne.
• Usługi działają.
• Odtworzenie replik w ciągu 10–15 minut.
• Alerty rozwiązane (poza wyłączonymi węzłami).

Ćwiczenia nr 1: klaster developmentowy

Wyłączono 1/3: 1 master, 1 infra, ok. 80 rdzeni worker. LB usunął niereagujące backendy w ciągu minuty. API działało, węzły były w stanie Unknown przez 300 sekund (domyślny timeout), potem not-ready/unreachable.

Pod-y nie były ponownie tworzone przez 10 minut. Przy tworzeniu:

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 (webhook do modyfikacji) miało po 1 Podzie na typ, 2/3 w wyłączonym regionie — Terminating. Bez webhook zmiany nie docierają do etcd. Przestrzenie systemowe zostały wykluczone z Kyverno, by uniknąć zakleszczenia.

Zwiększono repliki Kyverno. Ale events pokazały: ban na scheduling z powodu niewystarczających zasobów (nie podano w tekście, ale wynika z kontekstu).

Problemy i rozwiązania

Kyverno: przejęto na co najmniej 3 repliki na typ webhook, rozkład topologiczny po strefach.

Ban schedulera: sprawdzono quota zasobów i limity w przestrzeni nazw.

W produkcji (ćwiczenia nr 2/3) podobne scenariusze, ale w większym skali: ujawnione naruszenia PDB w usługach bez odpowiedniej anti-affinity, opóźnienia migracji PV.

Zespoły aplikacyjne otrzymały checklist:

• Minimalnie 3 repliki.
• PodDisruptionBudget z minAvailable.
• TopologySpreadConstraints lub nodeAffinity.
• Requests/limits.
• Liveness/readiness probes.

Co jest ważne

• Wyłączenie 30% węzłów wykrywa problemy z webhook i scheduling, niewidoczne w normalnych warunkach.
• Kyverno wymaga replik >1 z rozkładem po strefach.
• 300-sekundowy timeout NotReady/Unreachable — standard, ale wymaga rezerwy zasobów.
• Snapshoty węzłów infra/master — klucz do bezpiecznych ćwiczeń.
• Pełne odtworzenie: 10–15 minut na repliki + alerty.

Rekomendacje dla zespołów

Dla deweloperów usług:

• Skonfiguruj PDB: minAvailable: 50%.
• Użyj topologySpreadConstraints dla stref.
• Requests/limits CPU/RAM — 80% od obserwowanych szczytów.
• Probes z timeoutem 5–10s, próg 3.

Dla administratorów Kubernetes:

• Repliki Kyverno/innych webhook >3, HA.
• Monitoruj wybory lidera etcd.
• Planowanie pojemności: +30% rezerwy.
• Automatyczne snapshoty przed ćwiczeniami.

Takie ćwiczenia to konieczność dla klastrów produkcyjnych powyżej 100 węzłów.

— Editorial Team