Kubernetes obnovuje deklarovaný stav. Neobnovuje automaticky službu CIO MAG

Oficiální dokumentace Kubernetes rozlišuje dobrovolná a nedobrovolná narušení. PodDisruptionBudget omezuje některé dobrovolné evikce, ale nezabrání poruše hardwaru, síťovému oddělení uzlu ani přímému smazání workloadu. Nedobrovolné výpadky se do rozpočtu počítají, samotný rozpočet je však nedokáže zastavit.

Tento detail opravuje běžnou interpretaci, že počet replik a PDB automaticky znamenají vysokou dostupnost. Tři repliky mohou skončit ve stejné zóně. Nový Pod může čekat na chybějící kapacitu nebo volume. Readiness může potvrdit běh procesu dříve, než aplikace skutečně zvládne provoz. Cluster splní deklarovaný počet objektů, zatímco obchodní transakce stále selhává.

Manažerské shrnutí

01Restart je mechanismus, ne výsledek. Nový Pod musí získat kapacitu, data, síť a připravenost všech nutných závislostí.

02PDB nechrání před každou poruchou. Omezuje vybrané dobrovolné evikce. Nedobrovolný výpadek zóny ani přímé smazání tím nezmizí.

03Testuje se služba za hranicí clusteru. Úspěch se měří obchodní transakcí, latencí a datovou správností během ztráty uzlu, zóny nebo úložiště.

Počet replik neříká, kde běží

Scheduler potřebuje explicitní pravidla, aby repliky rozložil mezi uzly, racky nebo zóny podle požadované odolnosti. Topology spread constraints a anti affinity mohou omezit společný osud, ale jejich účinek závisí na označení topologie, dostupné kapacitě a volbě, zda se při nesplnění pravidla nový Pod vůbec naplánuje.

Kontrola	Co skutečně řeší	Co neřeší sama
Deployment se třemi replikami	Požadovaný počet Podů	Rozdělení zón, stav dat a kapacitu po poruše
PodDisruptionBudget	Současný počet vybraných dobrovolných evikcí	Výpadek uzlu, zóny a přímé smazání workloadu
Readiness probe	Zařazení Podu do obsluhy	Správnost všech obchodních funkcí a závislostí
Topology spread	Rozložení podle dostupných topologických domén	Dostatek kapacity a odolnost datové vrstvy
Autoscaler	Reakci na signál nebo nenaplánované Pody	Okamžitou kapacitu, kvóty a dostupnost typu uzlu

ARCHITEKTONICKÉ PRAVIDLO

Požadovaný počet replik schvalujte společně s požadovanou topologií a přeživší kapacitou. Pokud po ztrátě jedné zóny zbývající zóny nemají kam umístit nové Pody, deklarovaná redundance je pouze stav před poruchou.

Živý proces ještě nemusí být připravená aplikace

Liveness, readiness a startup probes mají rozdílný účel. Liveness rozhoduje, zda má kubelet kontejner restartovat. Readiness určuje, zda má Pod dostávat provoz. Startup probe může dát pomalu startující aplikaci čas před spuštěním ostatních kontrol. Chybně zvolený endpoint však může prohlásit aplikaci za připravenou dříve, než načte konfiguraci, naplní cache nebo obnoví spojení.

Příliš agresivní liveness naopak může během pomalé závislosti vytvářet restartovací smyčku. Platforma potom zvyšuje počet technických událostí právě během incidentu. Kontrola proto nemá odpovídat pouze na otázku, zda běží proces. Má být navržena podle toho, jaké selhání lze bezpečně řešit odebráním provozu a jaké skutečně vyžaduje restart.

PORUCHOVÝ TEST

V kontrolovaném prostředí odstavte jeden uzel a poté celou topologickou doménu. Měřte počet úspěšných transakcí, p99, dobu do plné kapacity, čekající Pody a stav dat. Výsledek clusteru porovnejte s výsledkem uživatele.

Modelový scénář z praxe: tři repliky na dvou uzlech

Modelová služba měla tři aplikační repliky a PDB s minimem dvou dostupných Podů. Během údržby jednoho uzlu se evikce správně zastavila. Tým to považoval za důkaz odolnosti. Při neplánovaném výpadku druhého uzlu však dvě repliky zmizely současně a nový Pod zůstal čekat, protože zbývající uzel neměl volnou paměť.

Cluster se choval podle konfigurace. Chyběla kapacitní a topologická podmínka, kterou vedení od návrhu očekávalo, ale nikdo ji technicky nevyjádřil. Náprava spojila topology spread, realistické resource requests, rezervu pro přežití poruchy a test ztráty zóny. PDB zůstal užitečnou kontrolou pro údržbu, nikoli náhradou celé dostupnostní architektury.

POZNÁMKA Z PRAXE

PDB, který blokuje údržbu celé hodiny, nemusí dokazovat vysokou odolnost. Může odhalovat, že aplikace neumí zdravě vytvořit další repliku, nemá kapacitu nebo používá příliš přísnou kombinaci pravidel.

Co z testu neplyne

Úspěšná ztráta uzlu neprokazuje odolnost proti ztrátě zóny, control plane, registru image ani datové vrstvy. Test stateless služby neříká nic o správnosti obnovy stateful workloadu. Stejně tak krátká zkouška nemusí zachytit vyčerpání front, prodlouženou replikaci nebo návrat z náhradní kapacity.

Kubernetes poskytuje nástroje pro vyjádření a obnovování deklarovaného stavu. Nezná však obchodní definici dostupnosti. Tu musí dodat vlastník služby a převést ji do topologie, kapacity, kontrol připravenosti a měřitelných poruchových scénářů.

CO VÝSLEDEK NEPROKAZUJE

To, že se po smazání Podu vytvoří nový, neprokazuje odolnost služby. Test obešel poruchu uzlu, topologie, úložiště i závislostí a ověřil pouze jednu část řídicí smyčky.

Platforma má obnovovat podmínky služby

Rozhodnutí o clusteru by nemělo končit dostupností control plane a standardem nasazení. Pro každou kritickou službu je nutné určit tolerovanou ztrátu topologické domény, přeživší kapacitu, datový režim, přípustnou dobu obnovy a vlastníka akceptačního testu.

Nosná teze zní: Kubernetes obnovuje objekty podle deklarace. Spolehlivost vzniká teprve tehdy, když deklarace zahrnuje podmínky, za kterých může fungovat celá služba.