Deployment Strategies and Rollback

In the previous lesson, you successfully updated your Deployment from nginx:1.25 to nginx:1.26 using Kubernetes' default rolling update behavior. The update worked smoothly, but you relied entirely on Kubernetes' default settings for how quickly the update happened and how many Pods could be unavailable at once. In production environments, you need more control. What if your application needs to stay highly available during updates, or what if you need to update faster because you're fixing a critical security vulnerability? Even more importantly, what happens when an update introduces a bug and you need to quickly revert to the previous working version?

This lesson teaches you how to take control of your deployment strategy by configuring the maxSurge and maxUnavailable parameters to balance speed and availability. You'll also learn how to track your deployment history and perform rollbacks to recover from failed updates. These skills are essential for managing production releases safely and confidently.

When Kubernetes performs a rolling update, it needs to make decisions about how aggressively to replace old Pods with new ones. Should it create all new Pods at once for maximum speed, or should it be more conservative to minimize resource usage? Should it allow some Pods to be unavailable during the update, or should it guarantee that the full replica count is always available? These decisions are controlled by two parameters: maxSurge and maxUnavailable. Understanding these parameters gives you precise control over how your updates behave.

The maxSurge parameter defines how many Pods can exist above your desired replica count during an update. Think of it as your "burst capacity" during the transition. If you have a Deployment with 3 replicas and set maxSurge: 1, Kubernetes can temporarily create a 4th Pod while the update is in progress. This extra Pod allows Kubernetes to bring up new Pods before terminating old ones, which speeds up the update and ensures you always have at least your desired number of Pods running. You can specify maxSurge as an absolute number (like 1 or 2) or as a percentage (like 25% or 50%). A higher maxSurge value makes updates faster but uses more resources temporarily. A lower value conserves resources but slows down the update.

Let's look at concrete examples. With maxSurge: 1 on a 3-replica Deployment, Kubernetes can have 4 Pods running simultaneously during the update. It creates one new Pod, waits for it to become ready, then terminates one old Pod. With maxSurge: 2, Kubernetes could have up to 5 Pods running at once, creating two new Pods before terminating any old ones. This makes the update faster because more new Pods can start in parallel. With maxSurge: 50% on a 3-replica Deployment, Kubernetes calculates 50% of 3 (which rounds up to 2), so it can have up to 5 Pods running during the update, just like setting maxSurge: 2 explicitly.

The maxUnavailable parameter defines how many Pods can be unavailable during an update. This controls how many old Pods Kubernetes can terminate before their replacements are ready. If you set maxUnavailable: 1 on a 3-replica Deployment, Kubernetes can have only 2 Pods running at certain moments during the update. It might terminate an old Pod before the new replacement is fully ready, accepting temporarily reduced capacity in exchange for faster updates or lower resource usage. Like maxSurge, you can specify this as an absolute number or a percentage.

Here's where the trade-offs become clear. With maxUnavailable: 0, Kubernetes guarantees that your full replica count is always available during updates. It must wait for each new Pod to become ready before terminating any old Pod. This provides maximum availability but requires extra resources because maxSurge must be greater than 0 for the update to proceed — Kubernetes rejects a Deployment where both maxSurge and maxUnavailable are 0 since no progress could be made. With maxUnavailable: 1, Kubernetes can terminate an old Pod immediately and create its replacement, which speeds up the update and reduces peak resource usage, but you temporarily have fewer Pods available to handle traffic. With maxUnavailable: 25% on a 3-replica Deployment, Kubernetes calculates 25% of 3, which rounds down to 0. However, when both maxSurge and maxUnavailable would be 0 simultaneously (preventing any progress), Kubernetes adjusts maxUnavailable to 1 to allow the update to proceed.

Choosing the right values depends on your application's requirements. For a critical service that must maintain full capacity, you might use maxSurge: 1 and maxUnavailable: 0 to ensure all replicas are always available, even if it means using extra resources temporarily. For a less critical service where you want faster updates and lower resource usage, you might use maxSurge: 1 and maxUnavailable: 1 to allow Kubernetes to terminate old Pods more aggressively. For a large Deployment with many replicas, percentage-based values like maxSurge: 25% and maxUnavailable: 25% scale better than absolute numbers.