Rolling Updates in Deployments

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.