KUBERNETES / DEPLOYMENT

Kubernetes Zero-Downtime Deployments: Kompletní průvodce

Jak nasazovat aktualizace vašich Kubernetes aplikací bez jakéhokoli přerušení služby. Rolling updates, blue-green, canary releases a kritické konfigurace, které většina týmů přehlíží.

Únor 2026 · 10 min čtení

TL;DR - Rychlá odpověď

  • Zero-downtime deployment znamená vydávání aktualizací bez přerušení služby
  • Vyžaduje: správné readiness probes, rolling update strategii, zpracování graceful shutdown
  • Běžné strategie: Rolling Updates (výchozí), Blue-Green, Canary Releases
  • Většina selhání je způsobena chybějícími readiness probes nebo nesprávným drainováním spojení

Co je Zero-Downtime Deployment?

Zero-downtime deployment je strategie nasazování, při které jsou aktualizace aplikací vydávány bez jakéhokoli přerušení služby. Uživatelé pokračují v normálním přístupu k aplikaci po celou dobu procesu nasazování - nezaznamenají chyby, timeouty ani žádnou indikaci, že probíhá aktualizace.

V Kubernetes se toho dosahuje kombinací správné konfigurace deploymentu, health checků a zpracování graceful shutdown. Když je to provedeno správně, můžete nasazovat vícekrát denně s naprostou jistotou, že uživatelé nebudou ovlivněni.

Proč na Zero-Downtime záleží

Každá minuta výpadku má svou cenu:

  • Ztráta příjmů - E-commerce stránky přicházejí o prodeje, SaaS platformy o příjmy založené na využití
  • Důvěra uživatelů - Časté výpadky narušují důvěru ve vaši platformu
  • Rychlost vývojářů - Strach z nasazování vede k méně častým releasům s většími, rizikovějšími změnami
  • Zátěž on-call - Riziková nasazování znamenají více incidentů a stresované inženýry

Týmy, které dosáhnou spolehlivých zero-downtime deployments, nasazují častěji, dodávají menší změny a mají vyšší důvěru ve své releasy.

Porovnání deployment strategií

Strategie Jak funguje Nejlepší pro
Rolling Update Postupně nahrazuje staré pody novými Většinu aplikací (výchozí strategie)
Blue-Green Dvě identická prostředí, přepnutí trafficu najednou Databázové migrace, velké změny
Canary Směruje malé % trafficu na novou verzi jako první Vysoce rizikové změny, postupný rollout

Krok 1: Nakonfigurujte Readiness Probes

Readiness probe říká Kubernetes, kdy je váš pod připraven přijímat traffic. Bez ní Kubernetes bude posílat traffic na pody, které nejsou připraveny, což způsobí chyby během nasazování.

spec:
  containers:
  - name: app
    readinessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
      failureThreshold: 3

Častá chyba

Nepoužívejte pouze liveness probe! Liveness probes restartují nezdravé pody, ale readiness probes řídí směrování trafficu. Pro zero-downtime potřebujete obě.

Váš health endpoint by měl ověřit, že aplikace je skutečně připravena:

  • Databázová spojení jsou navázána
  • Cache je zahřáta (pokud je třeba)
  • Závislosti jsou dosažitelné

Krok 2: Nakonfigurujte Rolling Update strategii

Rolling update strategie řídí, jak Kubernetes nahrazuje staré pody novými. Dva klíčové parametry:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  • maxUnavailable: 0 - Nikdy nemít méně než požadovaný počet podů (zero-downtime)
  • maxSurge: 1 - Povolit jeden extra pod během rolloutu

S touto konfigurací Kubernetes:

  1. Vytvoří nový pod s aktualizovanou verzí
  2. Počká, až projde readiness kontrolami
  3. Začne směrovat traffic na nový pod
  4. Terminuje starý pod
  5. Opakuje, dokud nejsou všechny pody aktualizovány

Krok 3: Implementujte Graceful Shutdown

Když Kubernetes terminuje pod, pošle SIGTERM signál. Vaše aplikace musí tento signál zpracovat korektně:

  • Přestat přijímat nové požadavky
  • Dokončit zpracování probíhajících požadavků
  • Čistě uzavřít databázová spojení
  • Ukončit proces
# Python příklad
import signal
import sys

def graceful_shutdown(signum, frame):
    print("Přijat SIGTERM, probíhá graceful shutdown...")
    # Přestat přijímat nové požadavky
    server.stop_accepting()
    # Počkat na dokončení probíhajících požadavků
    server.wait_for_pending_requests(timeout=30)
    # Uzavřít spojení
    db.close()
    sys.exit(0)

signal.signal(signal.SIGTERM, graceful_shutdown)

Krok 4: Přidejte PreStop Hook

Existuje race condition: Kubernetes odstraní pod ze service endpointů ve stejnou dobu, kdy posílá SIGTERM. Nějaký traffic může během tohoto okna stále přicházet.

PreStop hook přidává zpoždění před shutdownem, což dává čas pro propagaci aktualizací endpointů:

spec:
  containers:
  - name: app
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep 10"]

Tento 10sekundový sleep dává load balancerům a ingress controllerům čas přestat posílat traffic na tento pod, než začne shutdown.

Pro Tip

Nastavte terminationGracePeriodSeconds minimálně na preStop sleep + čas shutdownu vaší aplikace. Výchozí hodnota je 30 sekund.

Kompletní příklad

Zde je kompletní konfigurace deploymentu pro zero-downtime:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: app
        image: my-app:v2
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 10"]

Řešení běžných problémů

1. Chyby během nasazování

Příznak: Uživatelé vidí 502/503 chyby během nasazování.
Příčina: Obvykle chybějící nebo špatně nakonfigurované readiness probes.
Řešení: Zajistěte, aby readiness probe vracela healthy až když je aplikace skutečně připravena.

2. Resety spojení

Příznak: Probíhající požadavky selhávají s connection reset.
Příčina: Aplikace nezpracovává SIGTERM korektně.
Řešení: Implementujte graceful shutdown a přidejte preStop hook.

3. Pomalé rollouty

Příznak: Nasazování trvá příliš dlouho.
Příčina: Obvykle pomalé readiness probes nebo konzervativní nastavení.
Řešení: Vylaďte initialDelaySeconds a periodSeconds, zvyšte maxSurge.

Klíčové poznatky

  • Zero-downtime deployment je dosažitelný se správnou konfigurací
  • Readiness probes jsou kritické - řídí směrování trafficu
  • Použijte maxUnavailable: 0 pro zajištění kapacity během nasazování
  • Implementujte graceful shutdown ve vaší aplikaci
  • Přidejte preStop hook pro řešení race condition aktualizace endpointů
  • Otestujte svou deployment strategii, než se na ni v produkci spolehnete

Potřebujete pomoc s Kubernetes deployments?

Pomohli jsme firmám dosáhnout zero-downtime deployments a snížit obavy z nasazování. Pojďme si promluvit o vaší infrastruktuře.

Kontaktujte nás