Kubernetes pro vývojáře: jak funguje orchestrace kontejnerů

Aplikaci zabalíte do kontejneru a spustíte příkazem docker run. Jenže kdo ji restartuje, když ve tři ráno spadne? Kdo ji přesune, když umře celý server? A kdo přidá další instance, když přijde špička? Přesně tyhle otázky řeší Kubernetes — a dělá to způsobem, který je elegantnější, než se z jeho pověsti „přebujelého molochu“ může zdát. V tomto článku rozebereme jeho klíčovou myšlenku (deklarativní model a rekonciliační smyčku), architekturu clusteru, základní objekty i praktické ukázky. A taky si upřímně řekneme, kdy Kubernetes nepotřebujete.

Proč vůbec orchestrace

Kontejnery vyřešily zabalení aplikace: kód, závislosti a runtime v jednom přenositelném balíčku. Neřeší ale provoz. Jakmile máte víc než pár kontejnerů na víc než jednom stroji, začnou se hromadit otázky, na které docker run odpověď nemá:

• Plánování (scheduling) — na kterém stroji má kontejner běžet, aby se efektivně využily CPU a paměť?
• Samoléčení (self-healing) — kdo restartuje spadlý proces a co se stane, když vypadne celý server?
• Škálování — jak přidat instance při špičce a ubrat je v noci, aniž by to někdo dělal ručně?
• Nasazování — jak vydat novou verzi bez výpadku a jak se rychle vrátit, když je rozbitá?
• Síťování a discovery — jak se instance najdou navzájem, když se jejich IP adresy neustále mění?

Kubernetes (zkráceně K8s — osm písmen mezi K a s) je open-source odpověď na všechny tyto otázky najednou. Vznikl v Googlu jako destilát zkušeností z interního systému Borg, v roce 2014 byl uvolněn jako open source a dnes je spravován nadací CNCF. Je de facto standardem: všechny velké cloudy nabízejí spravovaný Kubernetes (EKS, GKE, AKS) a naprostá většina cloud-native nástrojů s ním počítá jako s podložím.

Klíčová myšlenka: deklarativní model a rekonciliační smyčka

Kdybyste si z celého článku měli odnést jedinou věc, ať je to tahle. Kubernetes neposloucháte imperativně („spusť tři kontejnery“), ale deklarativně: popíšete žádoucí stav („chci, aby běžely tři repliky této aplikace“) a Kubernetes se stará o to, aby mu skutečný stav clusteru odpovídal. Nepřetržitě.

Zajišťují to kontrolery — programy, které v nekonečné smyčce dělají tři kroky: pozoruj skutečný stav, porovnej ho s žádoucím stavem zapsaným v poli spec objektu a jednej tak, aby se rozdíl zmenšil. Této smyčce se říká rekonciliační (reconciliation loop) a je to nejdůležitější návrhový vzor celého systému — každá funkce Kubernetes, od Deploymentů po autoscaling, je jen další kontroler s toutéž smyčkou.

Ze smyčky plynou dvě vlastnosti, díky kterým Kubernetes přežije i chaos reálného provozu:

• Level-triggered chování — kontroler nereaguje na jednotlivé události („uživatel změnil repliky ze 3 na 5, pak na 4“), ale vždy na aktuální stav. Když kontroler spadne nebo mu utečou události, po restartu se prostě podívá znovu a dopočítá rozdíl. Žádná ztracená zpráva nezpůsobí trvalou nekonzistenci.
• Idempotence — každá rekonciliace se dá bezpečně spustit opakovaně. Vytvoření Podu, který už existuje, je no-op; škálování na počet, který už platí, nic neudělá. Proto se smyčka může točit klidně každých pár sekund, aniž by systém rozbila.

Tenhle vzor je tak univerzální, že na něm stojí i rozšiřování Kubernetes: napíšete vlastní typ objektu (Custom Resource Definition) a vlastní kontroler — tomu se říká operátor — a najednou Kubernetes umí spravovat třeba PostgreSQL cluster nebo certifikáty stejným způsobem, jakým spravuje Pody.

Architektura: control plane a worker nody

Fyzicky je Kubernetes cluster množina strojů (fyzických nebo virtuálních) rozdělená na dvě role. Control plane je mozek: drží stav, plánuje a rozhoduje. Worker nody jsou svaly: na nich skutečně běží vaše kontejnery.

Komponenty control plane

• kube-apiserver — jediné místo, přes které se s clusterem komunikuje. REST API, přes které jde všechno: kubectl, kontrolery i kubelety na nodech. Validuje objekty a ukládá je do etcd.
• etcd — distribuovaná key-value databáze, ve které žije kompletní stav clusteru (všechny objekty a jejich spec i status). Jediná stavová komponenta — vše ostatní se dá restartovat bez ztráty dat.
• kube-scheduler — sleduje Pody bez přiřazeného nodu a vybírá pro ně nejvhodnější stroj podle požadavků na CPU/paměť, afinit a dalších pravidel.
• kube-controller-manager — hostí desítky vestavěných kontrolerů (Deployment, ReplicaSet, Job, Node…), každý se svou rekonciliační smyčkou.

Co běží na worker nodech

• kubelet — agent, který se ptá API serveru, jaké Pody mají na nodu běžet, a přes container runtime je spouští a hlídá.
• container runtime — typicky containerd, samotné spouštění kontejnerů. (Docker jako runtime skončil, obrazy z Dockeru ale samozřejmě fungují dál — formát OCI je společný.)
• kube-proxy — udržuje síťová pravidla, aby fungovaly Services (viz níže).

Základní objekty: od Podu k Deploymentu

S Kubernetes se pracuje přes objekty — YAML manifesty, které popisují žádoucí stav. Základní stavebnice je malá a skládá se do sebe jako matrjoška:

Důležitý detail: Pody jsou jednorázové. Když Pod umře, nikdo ho neopravuje — ReplicaSet prostě vytvoří nový, klidně na jiném stroji a s jinou IP adresou. Proto existují Services: dávají proměnlivé množině Podů stabilní DNS jméno (např. api.default.svc.cluster.local) a rozkládají mezi ně provoz. Pody si Service vybírá podle labelů — obyčejných key-value štítků.

Praktická ukázka: nasazení aplikace

Takhle vypadá kompletní manifest pro nasazení webové aplikace ve třech replikách i se Service:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: moje-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: moje-api
  template:
    metadata:
      labels:
        app: moje-api
    spec:
      containers:
        - name: api
          image: registry.example.com/moje-api:1.7.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 250m        # 0.25 CPU pro planovani
              memory: 256Mi
            limits:
              memory: 512Mi    # tvrdy strop, pri prekroceni OOMKill
---
apiVersion: v1
kind: Service
metadata:
  name: moje-api
spec:
  selector:
    app: moje-api      # smeruj na Pody s timto labelem
  ports:
    - port: 80
      targetPort: 8080

Manifest pošlete do clusteru a sledujete, jak rekonciliační smyčky odvedou svou práci:

$ kubectl apply -f moje-api.yaml
deployment.apps/moje-api created
service/moje-api created

$ kubectl get pods -l app=moje-api
NAME                        READY   STATUS    RESTARTS   AGE
moje-api-7d4b9c8f6d-2xvqp   1/1     Running   0          14s
moje-api-7d4b9c8f6d-8kzwl   1/1     Running   0          14s
moje-api-7d4b9c8f6d-tr9nc   1/1     Running   0          14s

Samoléčení si můžete vyzkoušet hned: smažte jeden Pod ručně a sledujte, jak ReplicaSet kontroler během pár sekund doplní stav zpátky na tři repliky.

$ kubectl delete pod moje-api-7d4b9c8f6d-2xvqp
pod "moje-api-7d4b9c8f6d-2xvqp" deleted

$ kubectl get pods -l app=moje-api
NAME                        READY   STATUS    RESTARTS   AGE
moje-api-7d4b9c8f6d-8kzwl   1/1     Running   0          3m
moje-api-7d4b9c8f6d-tr9nc   1/1     Running   0          3m
moje-api-7d4b9c8f6d-x51fh   1/1     Running   0          4s    # novy Pod, dopocital ho kontroler

A nová verze? Změníte tag image v manifestu (nebo použijete kubectl set image) a Deployment kontroler provede rolling update: postupně vytváří Pody s novou verzí a teprve když jsou zdravé, ubírá staré. Když se něco pokazí, kubectl rollout undo vrátí předchozí revizi.

$ kubectl set image deployment/moje-api api=registry.example.com/moje-api:1.8.0
$ kubectl rollout status deployment/moje-api
Waiting for deployment "moje-api" rollout to finish: 1 out of 3 new replicas have been updated...
deployment "moje-api" successfully rolled out

Jak Kubernetes pozná, že je aplikace zdravá

Rolling update i self-healing stojí a padají s tím, že Kubernetes umí rozlišit zdravý Pod od nemocného. Od toho jsou sondy (probes), které kubelet periodicky spouští proti kontejneru:

• Liveness probe — „žiješ?“ Když opakovaně selže, kubelet kontejner restartuje. Hodí se na zaseknuté procesy a deadlocky.
• Readiness probe — „jsi připraven obsluhovat?“ Když selže, Pod se dočasně vyřadí ze Service a nedostává provoz — třeba během warm-upu nebo když čeká na databázi.
• Startup probe — ochrana pomalu startujících aplikací, dokud neproběhne, liveness se nevyhodnocuje.

          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            periodSeconds: 10
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            periodSeconds: 5

Častá chyba: dát do liveness probe kontrolu závislostí (databáze, fronty). Když pak vypadne databáze, Kubernetes začne restartovat všechny vaše Pody — a z drobného výpadku je kaskádová katastrofa. Liveness má testovat jen samotný proces; závislosti patří nanejvýš do readiness.

Škálování: ruční, automatické, a na co si dát pozor

Ruční škálování je jeden příkaz (kubectl scale deployment/moje-api --replicas=10), ale zajímavější je to automatické. Horizontal Pod Autoscaler (HPA) je — jak jinak — další kontroler: sleduje metriky (typicky vytížení CPU vůči requests) a upravuje počet replik v zadaném rozmezí.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: moje-api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: moje-api
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Aby HPA (a scheduler vůbec) fungoval rozumně, potřebuje znát resources.requests vašich kontejnerů — podle nich se plánuje i počítá vytížení. Nasazovat produkční workloady bez requests je jedna z nejčastějších začátečnických chyb: scheduler pak stroje přeplní a aplikace se navzájem vyhladoví. Vedle HPA existuje i Vertical Pod Autoscaler (upravuje requests) a Cluster Autoscaler (přidává celé nody v cloudu) — dohromady tvoří tři vrstvy elasticity.

Kde si Kubernetes vyzkoušet

Nepotřebujete firemní cluster, plnohodnotný Kubernetes spustíte na vlastním notebooku:

• kind (Kubernetes in Docker) — cluster v kontejnerech, ideální pro rychlé experimenty a CI. Start do minuty.
• minikube — nejstarší a nejpohodlnější varianta s doplňky (dashboard, ingress) na jeden příkaz.
• k3s — odlehčená certifikovaná distribuce (jedna binárka ~70 MB), skvělá i pro Raspberry Pi a edge.

# cely playground na tri prikazy (potrebujete jen Docker)
$ kind create cluster --name pokusy
$ kubectl cluster-info --context kind-pokusy
$ kubectl apply -f moje-api.yaml

V produkci pak drtivá většina firem sáhne po spravované službě — Amazon EKS, Google GKE nebo Azure AKS — kde control plane provozuje cloud a vy řešíte jen worker nody a své aplikace.

Co Kubernetes není (a kdy ho nepoužívat)

Upřímnost na závěr: Kubernetes je mocný, ale není zadarmo. Není to PaaS — nedostanete build pipeline, databáze ani monitoring; to všechno si do něj teprve instalujete a spravujete. A jeho komplexita je reálná: síťové modely, RBAC, certifikáty, upgrady clusteru třikrát ročně.

• Jedna aplikace na jednom serveru? Docker Compose + systemd vás obslouží za zlomek úsilí.
• Malý tým bez ops kapacity? PaaS (Fly.io, Railway, Azure App Service…) vyřeší 90 % potřeb bez nutnosti rozumět etcd.
• Kubernetes dává smysl, když provozujete desítky služeb, potřebujete autoscaling, multi-tenant izolaci, jednotnou platformu pro víc týmů — nebo speciální workloady jako GPU inference (viz náš článek o hostování LLM, kde Kubernetes hraje hlavní roli na velké škále).

Pravidlo palce: Kubernetes si pořiďte, až vás začne bolet jeho absence — ne proto, že ho mají všichni okolo. Migrace z Compose do K8s je mnohem levnější než rok předčasné komplexity.

Kubernetes v roce 2026

Projekt vydává tři verze ročně; aktuální je v1.36 „Haru“ z dubna 2026 (70 vylepšení, z toho 18 nově stabilních). Za zmínku stojí směr, kterým se projekt vyvíjí:

• AI a batch workloady — Workload Aware Scheduling (gang scheduling, PodGroup API) míří na distribuovaný trénink a inference, kde je potřeba naplánovat skupinu Podů atomicky „všechno, nebo nic“. Dynamic Resource Allocation (DRA) pro flexibilní přidělování GPU postupně dozrává do stable.
• Deklarativní validace API — validace nativních typů se generuje z deklarativních pravidel místo ručního kódu; pravidla se časem propíší do OpenAPI schémat, takže chyby odhalí už editor.
• Úklid — starý gitRepo volume byl definitivně odstraněn a Service.spec.externalIPs je deprecated (CVE-2020-8554). Před upgradem clusteru se vyplatí audit zastaralých API.

Co s tím v praxi

• Začněte s managed clusterem a lokálním kind — provozovat vlastní control plane se učte, až to budete opravdu potřebovat.
• Vždy nastavujte resources.requests a u paměti i limits; bez nich nefunguje pořádně scheduler ani autoscaling.
• Liveness probe testuje jen proces, ne závislosti — ušetříte si kaskádové restarty.
• Manifesty patří do gitu — deklarativní model přímo vybízí ke GitOps přístupu (Argo CD, Flux): git je žádoucí stav, cluster se s ním rekonciliuje. Stejná smyčka, o vrstvu výš.
• Naučte se debugovat: kubectl describe pod (události!), kubectl logs --previous, kubectl exec. Odpověď na 80 % problémů je v events.
• Nepodléhejte template hellu — než sáhnete po Helmu s třemi vrstvami hodnot, zkuste čisté manifesty a Kustomize. Komplexitu přidávejte, až když bolí její absence.

← Zpět na všechny články