Deployments

Deployments

Deployment vlastní ReplicaSety a každý ReplicaSet vlastní pody. Právě to patro navíc umožňuje aktualizace bez výpadku a návraty zpět.

graph TB D[Deployment nginx] --> RS1[ReplicaSet v1 – replicas 0] D --> RS2[ReplicaSet v2 – replicas 3] RS2 --> P1[Pod] RS2 --> P2[Pod] RS2 --> P3[Pod]

Změna šablony vytvoří nový ReplicaSet a starý po krocích zmenší. Starý zůstane na nule replik – to je váš rollback.

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1     # kolik smí být mimo provoz
      maxSurge: 1           # kolik smí přebývat navíc

Protože maxUnavailable chrání staré pody, rozbitý nový image aplikaci nepoloží: nový ReplicaSet selhává, starý dál obsluhuje a rollout se prostě nikdy nedokončí.

Každodenní příkazy

kubectl scale deploy web --replicas=5
kubectl set image deploy/web nginx=nginx:1.28
kubectl rollout status deploy/web
kubectl rollout history deploy/web
kubectl rollout undo deploy/web
kubectl rollout restart deploy/web     # stejný image, nové pody – načte změny konfigurace

Probes

Probes dělají rollout poctivým.

ProbeOtázkaSelhání znamená
readinessProbeumí obsloužit provoz?vyřazení z endpointů Service
livenessProbežije ještě?restart kontejneru
startupProbedokončil start?ostatní probes čekají
readinessProbe:
  httpGet: { path: /, port: 80 }
  initialDelaySeconds: 3
  periodSeconds: 5

Bez readiness probe považuje Kubernetes pod za připravený, jakmile naběhne proces – a rolling update ochotně pošle provoz do aplikace, která se teprve rozjíždí.

Reference