Modern production systems cannot afford downtime.

Whether you're shipping microservices, APIs, or internal platforms, your deployment strategy must ensure:

• High availability

• Controlled risk

• Easy recovery from failure

In Kubernetes, this is handled primarily through Rolling Updates and Rollbacks, managed by the Deployment controller.

This article gives you a practical, production-ready understanding based on official Kubernetes documentation.

---

🚀 What Is a Rolling Update?

A Rolling Update is Kubernetes’ default deployment strategy.

Instead of terminating all old Pods at once, Kubernetes:

1. Creates new Pods gradually

2. Waits for them to become ready

3. Scales down old Pods incrementally

This ensures:

• ✅ Near zero downtime

• ✅ Controlled traffic shifting

• ✅ Safe incremental upgrades

---

⚙️ How Rolling Updates Work Internally

When you update a Deployment (for example, changing a container image):

kubectl set image deployment/myapp myapp=nginx:1.25

Kubernetes:

• Creates a new ReplicaSet

• Gradually increases replicas in the new ReplicaSet

• Gradually decreases replicas in the old ReplicaSet

• Maintains availability during transition

Each Deployment revision is tied to a ReplicaSet.

---

📊 Default Rolling Update Configuration

By default:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 25%
    maxSurge: 25%

Let’s break this down clearly.

🔹 maxUnavailable

Maximum number of Pods that can be unavailable during the update.

If you have 4 replicas:

• 25% = 1 Pod

• Only 1 Pod can be down at a time

🔹 maxSurge

Maximum number of extra Pods created temporarily during update.

If you have 4 replicas:

• 25% = 1 extra Pod

• Kubernetes may temporarily run 5 Pods

This ensures capacity remains stable.

---

🔁 What Is a Rollback?

Deployments sometimes fail:

• Bad container image

• CrashLoopBackOff

• Failed readiness probes

• Performance degradation

Kubernetes allows you to revert to a previous working version instantly.

To view history:

kubectl rollout history deployment/myapp

To rollback:

kubectl rollout undo deployment/myapp

Or to a specific revision:

kubectl rollout undo deployment/myapp --to-revision=1

Under the hood, Kubernetes simply scales up the previous ReplicaSet and scales down the faulty one.

---

🧠 Why Readiness Probes Matter

Rolling updates depend heavily on readiness probes.

A readiness probe determines when a Pod is ready to receive traffic.

If a Pod fails readiness:

• It is not added to the Service

• Traffic is not routed to it

• The rollout pauses

Without readiness probes, Kubernetes assumes Pods are ready immediately — which can cause downtime.

Example:

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

---

⏸️ Pausing and Resuming Rollouts

You can pause a deployment:

kubectl rollout pause deployment/myapp

Apply multiple changes, then resume:

kubectl rollout resume deployment/myapp

This prevents unnecessary intermediate rollouts.

---

🧨 Handling Failed Rollouts

You can define:

progressDeadlineSeconds: 600

If a rollout does not complete within this time:

• It is marked as failed

• You can investigate and rollback

---

🏗️ Production-Ready Deployment Example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 4
  revisionHistoryLimit: 5
  progressDeadlineSeconds: 600
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    spec:
      containers:
      - name: myapp
        image: myapp:v2
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

---

📌 Best Practices

✔ Always configure readiness probes
✔ Monitor rollout status (kubectl rollout status)
✔ Avoid aggressive maxUnavailable in production
✔ Keep revisionHistoryLimit > 0
✔ Test rollback procedures regularly
✔ Set resource requests and limits

---

🆚 Deployment Strategies Comparison

RollingUpdate remains the most widely used approach.

---

🎯 Final Thoughts

Rolling Updates and Rollbacks are what make Kubernetes production-safe.

They provide:

• Predictable deployments

• Automatic availability protection

• Fast recovery from failure

• Safer CI/CD pipelines

Understanding how ReplicaSets, probes, and rollout parameters interact is essential for operating reliable Kubernetes workloads.

---

📚 Official Documentation:

• https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

• https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/