База на знаења

Kubernetes Deployments support rolling updates natively — gradually replacing old Pods with new ones so your application stays available throughout a deployment, with instant rollback if something goes wrong.

How Rolling Updates Work by Default

When you update a Deployment's image, Kubernetes doesn't replace all Pods at once — it creates new Pods gradually while terminating old ones, controlled by the update strategy settings.

Configuring the Rolling Update Strategy

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  replicas: 3

maxSurge: 1 allows one extra Pod above the desired replica count during the update; maxUnavailable: 0 ensures no reduction in available replicas at any point — together, this achieves genuinely zero-downtime updates.

Triggering a Rolling Update

kubectl set image deployment/my-app my-app=myregistry/my-app:v2

Watching the Rollout Progress

kubectl rollout status deployment/my-app

Viewing Rollout History

kubectl rollout history deployment/my-app

Viewing Details of a Specific Revision

kubectl rollout history deployment/my-app --revision=2

Rolling Back to the Previous Version

kubectl rollout undo deployment/my-app

Rolling Back to a Specific Revision

kubectl rollout undo deployment/my-app --to-revision=3

Pausing a Rollout Mid-Update (For Manual Verification)

kubectl rollout pause deployment/my-app

kubectl rollout resume deployment/my-app

Useful for canary-style verification — pause after a few new Pods are up, verify they're healthy, then resume the full rollout.

Adding Readiness Probes (Critical for Safe Rollouts)

spec:
  containers:
  - name: my-app
    image: myregistry/my-app:v2
    readinessProbe:
      httpGet:
        path: /health
        port: 3000
      initialDelaySeconds: 5
      periodSeconds: 10

Without a readiness probe, Kubernetes might route traffic to a new Pod before it's actually ready to serve requests, causing errors during rollout — the readiness probe ensures traffic only reaches genuinely ready Pods.

Adding Liveness Probes (Automatic Restart of Unhealthy Pods)

livenessProbe:
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 15
  periodSeconds: 20

Unlike readiness (which controls traffic routing), a failing liveness probe causes Kubernetes to restart the container automatically.

Common Errors

Rollout hangs indefinitely — usually means new Pods are failing their readiness probe; check with kubectl describe pod POD_NAME and kubectl logs for the underlying cause.

Brief errors during deployment despite rolling update configuration — verify readiness probes are correctly configured; without them, Kubernetes may consider a Pod "ready" as soon as it starts, even if the application inside hasn't finished initializing.

FAQ

How is this different from blue-green or canary deployment?
Rolling updates gradually replace all instances with no distinct "old" and "new" environment coexisting deliberately, while blue-green/canary (see How to Set Up Blue-Green Deployment on a VPS and Canary Deployments: Gradually Rolling Out Changes) offer more explicit control over traffic splitting during the transition.

Continue Reading

• How to Deploy a Stateless Web App to Kubernetes (Step-by-Step)
• How to Set Up Horizontal Pod Autoscaling in Kubernetes
• How to Roll Back a Bad Deployment Quickly

Browse more articles in Kubernetes & Container Orchestration.