Kubernetes v mé práci: kdy má smysl a jak ho používám

2026-09-10

Kubernetes má problém s pověstí: polovina oboru ho nosí jako odznak, druhá ho vnímá jako daň. Pro mě je to nástroj s jasným okamžikem, kdy začíná dávat smysl. Marketingový web nebo MVP běží skvěle na jednom serveru se správcem procesů a CI úlohou — přesně tak se nasazuje i tento web. Kubernetes se vyplatí, když přibude více služeb, proměnlivá zátěž a více týmů nasazujících do stejné infrastruktury.

Všechno začíná kontejnerem. Vícefázové Dockerfile, malý runtime image bez vývojových závislostí, uživatel mimo root a jeden proces na kontejner. Aplikace Next.js se sestaví v režimu standalone; API NestJS obsahuje pouze dist a produkční node_modules. Stejný image jde z CI do stagingu a pak do produkce. Mění se jen konfigurace přes proměnné prostředí, ConfigMapy a Secrety — image se nikdy znovu nestaví pro každé prostředí.

Denně používám jen několik objektů: Deployment pro každou službu, před ním Service, Ingress s TLS pro veřejný provoz a HorizontalPodAutoscaler pro části se skutečnými špičkami zátěže. Každý kontejner má requests a limits zdrojů — bez nich plánovač hádá. Probe readiness a liveness jsou záměrně oddělené: readiness říká „zatím mi neposílej provoz“, liveness „restartuj mě“. Záměna promění pomalou databázi v lavinu restartů. Každá služba Node.js také zpracuje SIGTERM a dokončí rozpracované požadavky, aby rolling update nepřerušil platbu v polovině.

Ne všechno je webový server. Workery front běží ve vlastních Deploymentech a škálují se podle backlogu, ne CPU. Plánované úlohy — reporty, čištění, odsouhlasení s platební bránou — běží jako CronJoby s concurrencyPolicy: Forbid, aby se pomalý běh nepřekrýval s dalším. Migrace databáze se spustí jako Job před rolloutem, ne při startu aplikace: pět současně startujících replik se nemá pokoušet migrovat schéma najednou. PostgreSQL raději používám spravovaný, například RDS, než ve StatefulSetu — cluster je pro bezstavové služby.

Manifesty jsou v Gitu a kontrolují se jako kód. Nasazují se CI pipeline s Helmem nebo Kustomize, případně přes GitOps s Argo CD; rollback je pak revert, ne noční práce s kubectl. kubectl apply z notebooku je na učení, ne do produkce. Logy jdou do stdout a centrálního úložiště, metriky do Promethea a Grafany; rollout sleduji příkazem kubectl rollout status, místo abych jen doufal. Na AWS to obvykle znamená EKS se spravovanými skupinami uzlů, aby se tým soustředil na produkt, ne na control plane.

Odmítám Kubernetes pro dvoustránkový web, service mesh předtím, než existují služby, tajné údaje v prostém YAML v repozitáři a pody bez limitů jen proto, že „to fungovalo ve stagingu“. Pokud si nejste jistí, zda cluster potřebujete, pošlete mi seznam služeb, provoz a velikost týmu. Upřímně vám řeknu, zda zvolit Kubernetes, pár kontejnerů na jednom hostu, nebo platformu typu Vercel — a kolik každá možnost přibližně stojí měsíčně.

Dejte příštímu produktu někoho, kdo zůstane.

Chcete začít? Napište mi – mohu začít hned a zůstat. Dlouhodobé retainery, ne dvoutýdenní předání. Proberme váš projekt, požadavky a nejlepší cestu vpřed.

Zeptejte se na zkušenosti nebo služby