Course contentsShow
← Docker, Kubernetes & CI/CD
Lesson 273 of 8024. Kubernetes Architecture and Core ObjectsFree lesson

Executing Zero Downtime Rolling Updates

Master the process of updating container images while ensuring continuous service availability through controlled rolling replacement of pods.

In this lesson, you will learn how Kubernetes transitions your application from one version to another without interrupting user traffic by leveraging the rolling update strategy.

The Rolling Update Strategy

When you update a Deployment with a new container image, Kubernetes doesn’t simply kill all existing pods and restart them. Instead, it performs a Rolling Update. The Deployment controller slowly replaces old pods with new ones, ensuring that the number of available replicas never falls below a functional threshold.

How it works

Think of a rolling update like a bridge construction project where you replace one lane at a time. As the Deployment begins the update:

  1. It starts a new pod with the updated image.
  2. Once the new pod passes its readinessProbe (marking it as "ready" to receive traffic), the controller terminates one of the old pods.
  3. This process continues incrementally until every pod is running the new version.

This happens automatically because the Deployment object manages the underlying ReplicaSet. When you change the container image in your YAML definition, the Deployment creates a new ReplicaSet and scales it up while scaling the old ReplicaSet down.

Controlling the Pace

You can manage the "aggressiveness" of these updates using the strategy field in your Deployment manifest:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # How many extra pods can be created above the desired count
      maxUnavailable: 0  # How many pods can be unavailable during the update

By setting maxUnavailable: 0, you ensure that the total capacity of your service never drops below your requested replica count, effectively guaranteeing zero downtime. If maxSurge is set to 1, Kubernetes will temporarily spin up one extra pod before removing an old one, ensuring that you always have enough power to handle incoming requests while the transition occurs.

Because the Kubernetes control loop constantly monitors the state, it will pause the rollout if it detects that new pods are failing their health checks, preventing a bad update from breaking your entire production environment.

Key Takeaway: A rolling update ensures service availability by incrementally replacing old pods with new ones, governed by surge and availability limits you define in your Deployment strategy.