How to Set Replicas, MaxSurge, and MaxUnavailable Values for Rolling Updates

Rolling updates are a common strategy for deploying changes to a Kubernetes cluster without downtime. In this article, we’ll explore the key configuration values—Replicas, MaxSurge, and MaxUnavailable—that control the behavior of rolling updates. We’ll also discuss how these values affect deployment time and provide a code example to tie it all together.

---

What Are Replicas, MaxSurge, and MaxUnavailable?

Replicas

The replicas value specifies the desired number of pod instances for a deployment. These pods run simultaneously and ensure high availability and scalability.
For example, in the following code:

spec:
  replicas: 20

The deployment ensures 20 pods are running. During a rolling update, Kubernetes will work to maintain the specified number of pods, adjusting how many are added or removed based on the other values.

MaxSurge

The maxSurge value defines how many additional pods can be temporarily created during a rolling update. These extra pods allow the system to handle requests while new pods are being initialized.
For example, in the following code:

rollingUpdate:
  maxSurge: 1

This configuration allows 1 additional pod to be created above the specified replicas during an update.

MaxUnavailable

The maxUnavailable value controls how many pods can be unavailable (e.g., terminated or not ready) at a time during a rolling update.
For example, in the following code:

rollingUpdate:
  maxUnavailable: 1

This configuration ensures that no more than 1 pod is unavailable at any time during the update process.

---

What is a rolling update?

A rolling update is a Kubernetes deployment strategy that replaces pods incrementally to avoid downtime. Instead of shutting down all pods and starting new ones, rolling updates replace pods one by one (or based on configured limits). This ensures continuous availability of the application while updates are being applied.

---

How Do Replicas, MaxSurge, and MaxUnavailable Affect Rolling Updates?

1. Replicas: Dictates the baseline number of pods. For example, with replicas: 20, Kubernetes tries to maintain 20 functional pods throughout the update.
2. MaxSurge: Controls how many extra pods can be created during the update. Higher values allow for faster updates but may temporarily increase resource usage.
3. MaxUnavailable: Sets a limit on how many pods can be unavailable. Lower values ensure better availability but may slow down the update process.

---

Exapmle Scenario

Given the configuration below;

spec:
  replicas: 20
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate

• Replicas: 20 ensures 20 pods are running.
• MaxSurge: 1 allows Kubernetes to temporarily run 21 pods (20 + 1 extra).
• MaxUnavailable: 1 ensures no more than 1 pod is unavailable during the update.

In this setup, Kubernetes updates 1 pod at a time:

1. Creates a new pod (total: 21).
2. Waits for the new pod to be ready.
3. Terminates 1 old pod (total: 20). This process repeats until all pods are updated.

---

How These Values Impact Update Time

• Higher MaxSurge: Speeds up updates by creating more extra pods but increases temporary resource usage.
• Higher MaxUnavailable: Speeds up updates by tolerating more unavailable pods but risks reduced availability.
• Lower Values for Both: Slower updates but ensures higher availability and controlled resource usage.

---

Conclusion

By understanding and configuring replicas, maxSurge, and maxUnavailable, you can control the balance between availability, resource usage, and deployment speed during rolling updates. Tuning these values to match your application's needs ensures a smooth deployment process without compromising user experience.

---