# MaxUnavailable in Kubernetes

In simple terms, maxUnavailable defines how many pods in a StatefulSet can be unavailable during an update. It gives you control over the balance between application availability and the speed of updates, ensuring you don’t disrupt critical workloads while rolling out changes.

If you’ve worked with Kubernetes StatefulSets, you know they’re designed to manage stateful workloads—applications that need stable identities and persistent storage. But managing updates for these stateful applications can get tricky. That’s where `maxUnavailable` comes in.

Let’s break this down step by step.

## Why Does `maxUnavailable` Matter?

Imagine you’re updating a StatefulSet running a database [cluster.](/content/finops-glossary/kubernetes-cluster/index.html) By default, Kubernetes updates StatefulSet pods one at a time, ensuring that the next [pod](/content/finops-glossary/kubernetes-pods/index.html) isn’t updated until the previous one is running and ready. This is safe but slow, especially for large StatefulSets.

`maxUnavailable` allows you to adjust this behavior by permitting more than one pod to be unavailable simultaneously during updates. This means you can speed up updates while still maintaining control over availability.

For example:

- A `maxUnavailable` value of `1` (the default) ensures only one pod is down at a time.
- A higher value, like `2`, allows two pods to be updated simultaneously, speeding up the process.

## How Does `maxUnavailable` Work?

When you set `maxUnavailable` in your StatefulSet update strategy, Kubernetes uses this value to decide how many pods it can update concurrently during a rolling update. It calculates the number based on the total replicas of the StatefulSet and the `maxUnavailable` value.

#### Key Points:

1. **Default Behavior**: If `maxUnavailable` isn’t specified, the default value is `1`.
2. **Integer or Percentage**: You can specify `maxUnavailable` as an absolute number (e.g., `2`) or a percentage (e.g., `25%`).
3. **Granular Control**: By tweaking `maxUnavailable`, you can tailor the update process to suit your application’s tolerance for downtime.

## Setting `maxUnavailable` in a StatefulSet

Here’s a practical example to show how `maxUnavailable` works. Let’s say you have a StatefulSet with 5 replicas, and you want to allow up to 2 pods to be unavailable during updates.

#### Example YAML:

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: example-statefulset
spec:
  replicas: 5
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 2
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
      - name: app-container
        image: example-app:latest
```

## What Happens Here:

- Kubernetes ensures no more than 2 pods are unavailable at any point during the rolling update.
- If one pod is still terminating or starting up, Kubernetes won’t update additional pods until the number of unavailable pods is back within the `maxUnavailable` limit.

## When Should You Use `maxUnavailable`?

Here are some scenarios where adjusting `maxUnavailable` can be useful:

1. **Faster Updates**:
   - For large StatefulSets with non-critical workloads, increasing `maxUnavailable` can reduce the time it takes to complete updates.
2. **Maintaining Quorum**:
   - For distributed systems like Kafka or Zookeeper, keeping `maxUnavailable` low ensures the cluster maintains quorum and avoids service disruptions.
3. **Balancing Risk and Speed**:
   - Applications with medium fault tolerance can allow higher `maxUnavailable` values to balance downtime and update speed.

## Tips for Using `maxUnavailable`

1. **Know Your Application**: Understand your application’s tolerance for downtime. A database cluster might require a low `maxUnavailable` value, while a caching layer can tolerate higher values.
2. **Test in Staging**: Always test updates in a non-production environment to ensure the `maxUnavailable` setting works as expected.
3. **Use Percentages for Flexibility**: When scaling your StatefulSet up or down, percentages allow `maxUnavailable` to adjust dynamically based on the replica count.

## `maxUnavailable` vs. Default StatefulSet Behavior

By default, StatefulSets update one pod at a time. This ensures stability but can be slow. Here’s a quick comparison of default behavior and using `maxUnavailable`:

| **Behavior** | **Default (1 pod at a time)** | **With `maxUnavailable`** |
| --- | --- | --- |
| **Update Speed** | Slower | Faster (with more unavailable pods) |
| **Application Uptime** | Higher | Depends on the `maxUnavailable` value |
| **Use Case** | Critical, stateful applications | Non-critical or large StatefulSets |

## Best Practices for Using `maxUnavailable`

- **Start Small**: If you’re unsure of the right value, start with `1` or a low percentage to minimize risk.
- **Monitor During Updates**: Keep an eye on application metrics and pod health while testing new `maxUnavailable` settings.
- **Combine with Readiness Probes**: Ensure your StatefulSet pods have proper readiness probes configured to prevent Kubernetes from considering a pod “available” before it’s actually ready.

## Resources for Further Learning

1. **[Official Kubernetes Documentation](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#maximum-unavailable-pods)**
2. **[Kubernetes Blog Posts](https://kubernetes.io/blog/2022/05/27/maxunavailable-for-statefulset/)**
3. **YouTube Tutorial**