# RollingUpdate in Kubernetes

RollingUpdate is a deployment strategy in Kubernetes that incrementally replaces old versions of a pod with new ones, ensuring zero downtime and continued availability during updates. It’s the default strategy used in Kubernetes Deployments.

## What problem does RollingUpdate solves?

Imagine you’re running a popular web app with thousands of users. You need to roll out a new version — but you can’t afford even a few seconds of downtime. You also can’t spin up 100% new pods at once, as that could overload your cluster. This is where **RollingUpdate** comes in.

Instead of tearing everything down and starting over, Kubernetes **gradually replaces pods**, one or a few at a time, monitoring for health and availability after each step.

## How It Works

A **RollingUpdate strategy** allows Kubernetes to:

- **Start a new pod with the updated spec**  
- **Wait until it becomes healthy**  
- **Terminate an old pod**  
- Repeat this process until all pods are updated

This ensures your service stays up during the rollout and minimizes the risk of mass failure.

By default, it uses two important parameters:

### Key Settings in RollingUpdate

```none
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1
    maxSurge: 1
```

- **maxUnavailable**: The maximum number of pods that can be unavailable during the update. A value of `1` means at most one old pod can be down.  
- **maxSurge**: The number of extra pods that can be added temporarily during the update. A value of `1` allows one more than the desired number of pods to exist during the rollout.

Together, these settings let Kubernetes balance availability and speed.

## Example

Let’s say you have a Deployment with **4 replicas**:

- `maxUnavailable: 1`  
- `maxSurge: 1`

During the update:

1. Kubernetes adds 1 new pod (total 5 pods)  
2. Once that new pod is healthy, it removes 1 old pod (back to 4)  
3. Repeats this step-by-step until all 4 pods are updated

## Advantages of RollingUpdate

✅ **Zero downtime**  
✅ **Incremental rollout** (great for catching errors early)  
✅ **Built-in health checks**  
✅ **Can pause or rollback if something goes wrong**

## When It Might Fail

RollingUpdate depends heavily on **readiness probes** and **robust application health**. If your new pods don’t pass health checks, the rollout can **stall** or **get stuck halfway**.

Common failure scenarios:

- Bad image or broken startup logic  
- Readiness probe misconfigured  
- Network dependency not available yet

Kubernetes won’t kill old pods until the new ones are healthy — so if things go wrong, your app stays running, but the rollout halts.

## Use Cases in Practice

### Good Fit:

- Web servers  
- Microservices  
- APIs where backward compatibility is maintained

### Not Ideal:

- Databases or workloads that require **strict ordering** or **state migration**  
- Systems where **multiple versions** cannot run side by side

For these, consider **Recreate**, **Blue/Green**, or **Canary** deployments instead.

## How to Trigger a RollingUpdate

Any change to the Deployment spec will start a new rollout:

```none
kubectl set image deployment/my-app my-app=my-image:v2
```

You can monitor it with:

```none
kubectl rollout status deployment/my-app
```

Or pause/resume as needed:

```none
kubectl rollout pause deployment/my-app
kubectl rollout resume deployment/my-app
```

## Summary

> **RollingUpdate** is Kubernetes’ default and safest strategy for updating applications without taking them offline. It offers a balance between speed and reliability, giving you a smooth, controlled rollout backed by health checks and built-in rollback mechanisms.