Pevný rozsah. Vaše servisní okno. Plán rollbacku podepsaný před začátkem prací. Váš tým se nemusí dotknout produkce a neztratí na tom celý sprint.
Tři fakta, na kterých stojí celá tahle služba. Každé z nich si můžete ověřit u zdroje — odkazy jsou pod každou dlaždicí.
Nová minor verze vychází přibližně třikrát ročně a jedna verze dostává zhruba rok oprav. Na Amazon EKS trvá standardní podpora 14 měsíců od vydání verze. Produkční cluster proto potřebuje upgrade minimálně dvakrát ročně — donekonečna.
Zdroj: kubernetes.io — release cadence, kubernetes.io — patch support, AWS EKS pricing. Ověřeno 30. 8. 2026.
Cluster na verzi mimo standardní podporu stojí na Amazon EKS 0,60 USD za hodinu místo 0,10 USD. Na Azure AKS stojí Premium tier s Long-Term Support rovněž 0,60 USD za hodinu proti 0,10 USD u Standard tier. Obě platformy si za odkládaný upgrade účtují 365 USD měsíčně na každý cluster — přibližně 91 000 Kč ročně na cluster.
Zdroj: AWS EKS pricing, ceník AKS (ověřeno v Azure Retail Prices API), Microsoft Learn — AKS LTS. Ověřeno 30. 8. 2026.
Výpadek nezpůsobí cluster. Způsobí ho vaše aplikace: jedna replika, chybějící PodDisruptionBudget, žádný graceful shutdown, dlouhá spojení bez drainu. Odpovídáme za to, co se stane dvacet minut po zmáčknutí toho tlačítka.
Tohle není statistika, ale zkušenost z produkčních clusterů. Co konkrétně u vás projde a co ne, zjistíme v assessmentu — a napíšeme to po službách.
Assessment, remediace, zkouška nanečisto, provedení, předání. Na zkoušce stojí všechno ostatní — proto je to samostatná fáze s vlastním rozpočtem času.
Read-only přístup, žádný zásah do produkce. Projdeme manifesty a Helm charty na deprecated a odstraněná API, sestavíme matici kompatibility add-onů (CNI, CSI, ingress, cert-manager, service mesh, GitOps, autoscaler) a ohodnotíme každou službu podle toho, jestli přežije drain uzlu. Výstupem je mapa rizik, Workload Readiness Scorecard a plán upgradu s pevnou cenou.
Co neprojde Readiness Bar, opravíme ještě před upgradem — na současné verzi clusteru. Chybějící PodDisruptionBudgety, jedna replika u služby, která ji mít nemá, probes, které lžou, aplikace bez graceful shutdownu. Opravy aplikací a upgrade clusteru zásadně nemícháme do jednoho okna.
Samozřejmě že začínáme mimo produkci — na vašem stagingu, nebo na klonu clusteru, který postavíme tehdy, když se staging produkci v podstatných věcech nepodobá. Rozdíl není v tom, že zkoušíme, ale co si z toho odnášíme: projedeme celý upgrade včetně návratu zpět a zapíšeme čas každého kroku. Tyhle časy se pak stanou obsahem servisního okna, místo aby se odhadovaly. Když se něco rozbije, rozbije se to tady — a opravíme to dřív, než se vás to dotkne.
To je jediný způsob, jak lze slíbit nulový výpadek a myslet to vážně. Bez změřené zkoušky je „bez výpadku“ jen naděje.
Ve vašem servisním okně, včetně nocí a víkendů, podle scénáře ověřeného ve zkoušce. Plán rollbacku je odsouhlasený písemně předem. Průběh sledujeme proti vašim SLO, ne proti pocitu — pokud se ukazatele hnou, víme to dřív než vy.
Aktualizovaný infrastrukturní kód, závěrečný report a runbook, podle kterého další upgrade zvládne váš tým sám. Nepotřebujeme, abyste na nás byli závislí — pokud si nás najmete znovu, ať je to proto, že se vám to vyplatí.
Nulový výpadek je u nás měřená veličina, ne tvrzení v nabídce. Dopad na dostupnost změříme nejdřív při zkoušce nanečisto na klonu clusteru a znovu při samotném upgradu, proti vašim SLO. Naměřená čísla dostanete v závěrečném reportu.
Měřítkem je Readiness Bar — deset konkrétních podmínek, které ověříme v assessmentu. Co jimi neprojde, dostane samostatnou fázi remediace: opravíme to ještě před upgradem, na současné verzi clusteru. Nemícháme opravy aplikací a upgrade clusteru do jednoho okna — kdyby něco selhalo, nešlo by dohledat příčinu.
O aplikaci, kterou jsme neviděli, vám nulový výpadek nikdo poctivě slíbit nemůže. Proto začínáme tím, že se na ni podíváme.
Nemáme ceník, protože každý cluster je jinak zanedbaný. Máme ale pevnou cenu prvního kroku a otevřeně říkáme, na čem závisí ta druhá.
Pevná cena za 1 až 3 clustery, pět pracovních dní, read-only přístup. Každý další cluster +12 000 Kč.
Dostanete mapu rizik, úplný seznam deprecated API, matici kompatibility add-onů, Workload Readiness Scorecard a plán upgradu — s pevnou cenou provedení.
Na čem cena závisí:
Nad 220 000 Kč jdeme jen tam, kde assessment najde služby pod Readiness Bar — ty se řeší samostatně, 19 000 Kč za den. Každý další stejně postavený cluster vychází na 60 000 – 97 000 Kč.
Přesnou cenu upgradu stanovíme až po assessmentu — bez něj by to byl odhad, a odhad na produkčním clusteru není cena, ale slib, který někdo zaplatí. Ceny jsou bez DPH a platí pro clustery na Azure AKS a Amazon EKS. Zahraničním klientům fakturujeme v eurech; přepočet odpovídá kurzu k 30. 8. 2026.
Než se budeme bavit o naší ceně: spočítejte si, kolik vás stojí, že cluster neupgradujete.
Spočítat cenu odkládání →Assessment stojí 70 000 Kč za 1 až 3 clustery, každý další cluster +12 000 Kč. Trvá pět pracovních dní a stačí k němu read-only přístup. Samotný upgrade prvního clusteru vychází obvykle na 145 000 až 220 000 Kč podle toho, o kolik verzí cluster zaostává, kolik služeb neprojde Readiness Bar a jestli existuje non-prod prostředí.
Cenu assessmentu odečítáme od ceny upgradu, pokud budeme pokračovat do 90 dnů. Přesnou cenu upgradu stanovíme až po assessmentu — bez něj by to byl odhad.
Na assessment stačí read-only: čtecí role v Azure nebo AWS a ServiceAccount v clusteru s právem číst objekty. Secrety nečteme a přístup k nim nepotřebujeme.
Pro samotné provedení upgradu potřebujeme dočasně zvýšená práva, časově omezená na servisní okno a odvolatelná jedním krokem. Na Azure používáme Azure Lighthouse, na AWS cross-account roli s ExternalId. Do management accountu nevstupujeme. Každý úkon je ve vašich logech pod jménem konkrétního inženýra.
Plán rollbacku odsouhlasíme písemně před začátkem prací — včetně toho, za jakých konkrétních podmínek se do něj vrací. Ta kritéria nevymýšlíme až v okně, kdy na to není klid.
Návrat zpět je součástí zkoušky nanečisto: projedeme ho na klonu clusteru a změříme. Víme tedy dopředu, že funguje, a kolik minut zabere — a to číslo je pak zahrnuté v plánu servisního okna, ne dohadované na místě.
Proto také nemícháme opravy aplikací a upgrade clusteru do jednoho okna: kdyby něco selhalo, nešlo by dohledat příčinu. Konkrétní obchodní podmínky pro takový případ si domlouváme ve smlouvě podle rozsahu zakázky.
Assessment pět pracovních dní. Od assessmentu k provedení obvykle dva až tři týdny, podle rozsahu remediace. Samotné provedení běží ve vámi určeném servisním okně, včetně nocí a víkendů. Termín okna určujete vy, ne my.
Prioritně děláme Azure AKS a Amazon EKS — tam je náš postup nejlépe zaběhnutý a ceny nejpředvídatelnější. Self-hosted clustery (kubeadm, RKE2, k3s) posuzujeme případ od případu: assessment na nich uděláme vždy, u provedení upgradu se rozhodneme podle toho, jak je cluster postavený. Řekneme to rovnou na první schůzce, ne až po zaplacení.
Napište nám, na jaké verzi běžíte a kolik máte produkčních clusterů. Ozveme se do jednoho pracovního dne s termínem a rozsahem — na první schůzku nepotřebujeme žádný přístup.