How Kubernetes Balances Progress and Stability

James Clear once said - Intelligence follows curiosity.

15th May 2025, nearly lunch time.

I was casually checking the Kubernetes community on X.

To find something interesting to read. And then I noticed this post from Kavya. Well, a curious case to understand.

Kavya thinks Kubernetes is behaving not in the way she is expecting.

---

Basics first.

maxSurge and maxUnavailable are used in deployment configuration to control how the rolling update happens.

maxSurge = maximum number of additional pods allowed.

maxUnavailable = maximum number of pods that can be unavailable.

Example config

apiVersion: apps/v1
kind: Deployment
metadata:
  name: curious-deployment
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

And now, let's understand this scenario 😃

---

Based on the given input:

Here’s my observation.

• Minimum available active pods = total replica - maxUnavailable = 4 (5-1)

• Max active pods allowed = total replicas + maxSurge = 6 (5 + 1)

Hope it’s clear until this part. Because it’s important.

So what does it mean?

It means:

Kubernetes is allowed to have 1 extra pod (maxSurge) during the update process. To facilitate smooth transition. And the deployment controller doesn't follow this 1 pod up and then 1 pod down thing.

Second ...

The deployment controller primary job is to reach the desired state as fast as possible.

In this case, it's brining 5 new version of pods to life 🥳

---

So what is the deployment controller doing?

Well, it is trying to speed up the process. So it’s spinning 2 new pods at the same time. Note that it is also managing 4 active pods as Chitra rightly points out.

And that’s how Kubernetes clearly balances the act of progress and stability with precision👍

Did you explore this topic before? If you know more interesting things, let me know.

Hope this is clear and useful. A repost helps more people. Thank you.

---