In the previous lesson, you scaled your Deployment to run three nginx Pods for better reliability and capacity. But what happens when you need to update those Pods to a newer version of nginx? Maybe there's a security patch you need to apply, a new feature you want to use, or a bug fix that improves stability. You can't just delete all three Pods and create new ones — that would cause downtime while your application is unavailable. Your users would see errors, and your service would be interrupted.

Kubernetes solves this problem with rolling updates, a strategy that gradually replaces old Pods with new ones while keeping your application available throughout the entire process. In this lesson, you'll update your Deployment from nginx:1.25 to nginx:1.26 and watch Kubernetes perform a seamless, zero-downtime version change.

When you update a Deployment, Kubernetes doesn't replace all your Pods at once. Instead, it uses a rolling update strategy that gradually transitions from the old version to the new version. This strategy ensures that some Pods are always running and ready to serve traffic, even while the update is in progress.

Here's how the rolling update process works step by step. First, Kubernetes creates a new Pod running the updated version of your container. It waits for that new Pod to become ready and pass its health checks. Only after the new Pod is confirmed healthy does Kubernetes terminate one of the old Pods. Then it creates another new Pod, waits for it to become ready, and terminates another old Pod. This cycle continues until all old Pods have been replaced by new Pods. At any given moment during this process, you have a mix of old and new Pods running, but you always have enough Pods to handle traffic.

Kubernetes offers two update strategies: RollingUpdate and Recreate. The RollingUpdate strategy is the default and the one you'll use in this lesson. It's the gradual replacement approach we just described. The Recreate strategy, on the other hand, terminates all old Pods before creating any new ones. This causes downtime but can be useful in specific scenarios where you can't have old and new versions running simultaneously. For most applications, RollingUpdate is the right choice because it keeps your service available.

The rolling update strategy has two important parameters that control how aggressive the update is: maxUnavailable and maxSurge. The maxUnavailable parameter defines how many Pods can be unavailable during the update (either as a number or a percentage). The maxSurge parameter defines how many extra Pods can be created above your desired replica count during the update. By default, Kubernetes sets maxUnavailable to 25% and maxSurge to 25%, which means it can temporarily create one extra Pod and have one Pod unavailable during the update for a three-Pod Deployment. You don't need to worry about these parameters right now — the defaults work well for most cases — but it's good to know they exist if you need to fine-tune update behavior later.

Let's update your Deployment to use a newer version of the nginx image. You'll change the image from nginx:1.25 to nginx:1.26. This is a common real-world scenario — you're upgrading to a newer release of the software your application depends on. The process is remarkably simple: you modify the image version in your YAML file and reapply the configuration.

Note: Kubernetes also provides kubectl set image deployment/nginx-deployment nginx=nginx:1.26 as a quick imperative alternative for updating container images. While this works well for one-off changes, we're using the declarative YAML approach in this course because it provides better version control, documentation, and repeatability — you can commit your YAML files to Git, review changes in pull requests, and reproduce exact configurations. In production environments, the declarative approach is generally preferred because it makes your infrastructure configuration explicit and auditable.

Here's your current Deployment from the previous lesson:

To update to the new version, you only need to change one line. Find the image: nginx:1.25 line in the container specification and change it to image: nginx:1.26. Save this modified version to a new file called deployment-updated.yaml:

Kubernetes provides a special command for watching the progress of a rolling update: kubectl rollout status. This command shows you real-time updates as Kubernetes replaces old Pods with new ones. Run it with the -w flag (which stands for "watch") to keep the command running until the rollout completes:

You'll see output that tracks the rollout progress:

Let's break down what you're seeing here. The first few lines show Kubernetes creating new Pods with the updated image. The message "1 out of 3 new replicas have been updated" means one new Pod is running the nginx:1.26 image. As the rollout progresses, this number increases to 2, then 3. The lines about "old replicas are pending termination" indicate that Kubernetes is waiting for old Pods to shut down gracefully. Finally, you see "successfully rolled out," which means all three Pods are now running the new version and the update is complete.

The entire rollout process typically takes 30–60 seconds for a small Deployment like this, depending on how quickly the new Pods can start and become ready. During this entire time, your application remains available. At no point do all three Pods go down simultaneously. Kubernetes carefully orchestrates the transition to maintain service availability.

While the rollout is happening (or immediately after it completes), you can watch the Pods themselves change:

Behind the scenes of every rolling update, Kubernetes uses ReplicaSets to manage the transition between versions. You learned about ReplicaSets briefly in Lesson 2 — they're the intermediate controllers that actually create and manage Pods on behalf of Deployments. During a rolling update, something interesting happens: Kubernetes creates a new ReplicaSet for the updated version while keeping the old ReplicaSet around. This dual-ReplicaSet approach is what enables the smooth, gradual transition.

Here's how it works in detail. When you first created your Deployment with nginx:1.25, Kubernetes created a ReplicaSet to manage those Pods. That ReplicaSet had a replica count of 3, so it created three Pods. When you updated the Deployment to use nginx:1.26, Kubernetes didn't modify the existing ReplicaSet. Instead, it created a brand new ReplicaSet for the new template version. This new ReplicaSet started with a replica count of 0. Then, Kubernetes began the rolling update by gradually increasing the new ReplicaSet's replica count (0 → 1 → 2 → 3) while simultaneously decreasing the old ReplicaSet's replica count (3 → 2 → 1 → 0). This coordinated scaling is what creates the rolling effect.

Let's look at the ReplicaSets in your cluster to see this in action:

You'll see output showing two ReplicaSets:

The first ReplicaSet (7d64f8b9c4) is the old one that managed your nginx:1.25 Pods. Notice that its DESIRED count is now 0 — Kubernetes scaled it down to zero during the rolling update. The second ReplicaSet (8f9c7b6d5a) is the new one managing your nginx:1.26 Pods. Its count is 3, matching your Deployment's replica specification. Both ReplicaSets still exist in your cluster, but only the new one is actively managing Pods.

Updating a Deployment in Kubernetes is as simple as changing the container image version in your YAML file and reapplying the configuration. Kubernetes handles all the complexity of performing a rolling update — gradually replacing old Pods with new ones while maintaining service availability.

The Deployment creates a new ReplicaSet for the updated version and carefully orchestrates the transition by scaling the new ReplicaSet up while scaling the old ReplicaSet down. You can watch this process in real time using kubectl rollout status and observe the old and new Pods coexisting during the update. In the upcoming practice exercises, you'll perform rolling updates yourself, experiment with different image versions, and see how Kubernetes maintains zero downtime during version changes.