Configuring Deployment Update Strategies

In this lesson, you will learn how to fine-tune your application’s rollout behavior by controlling the pace and availability of your updates using maxSurge and maxUnavailable.

When you trigger a rollout in a Kubernetes Deployment, the default strategy is a "RollingUpdate." While this ensures zero downtime, you might want to control exactly how many pods are replaced at once. Kubernetes allows you to dictate this process using two specific parameters: maxSurge and maxUnavailable.

Tuning the Update Strategy

These settings live within your Deployment specification under the spec.strategy.rollingUpdate field.

• maxSurge: This defines the maximum number of pods that can be created above the desired number of replicas during an update. For example, if you set this to 1, Kubernetes will spin up one new pod before terminating an old one. If you set it to a percentage (like 25%), it calculates the surge based on your replica count.
• maxUnavailable: This defines the maximum number of pods that can be unavailable during the update process. If you have 4 replicas and set this to 1, Kubernetes ensures that at least 3 pods are always running and serving traffic while the update progresses.

Here is how you define these in your manifest:

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

Why does this matter?

If your application is resource-heavy, you might want a low maxSurge to avoid exceeding your cluster’s available CPU or memory during the transition. Conversely, if your application is extremely traffic-sensitive, you might set maxUnavailable to 0 to ensure that you never have fewer pods than your original capacity, even if it means temporary resource spikes as you spin up the "surged" pods first. By balancing these two numbers, you decide the exact trade-off between deployment speed and resource utilization.

Key Takeaway: Use maxSurge to control how many extra pods are created during an update, and maxUnavailable to guarantee the minimum number of pods that remain active, allowing you to tailor deployments to your cluster’s specific resource and availability requirements.