What is rolling update in Kubernetes?

A rolling update in Kubernetes is a deployment strategy that updates applications by gradually replacing old versions of Pods with new ones, ensuring zero downtime and continuous availability during the update process.

What is a Rolling Update?

Kubernetes Rolling Updates are a default and highly effective strategy for deploying new versions of applications or making configuration changes to existing ones without interrupting service availability. Instead of taking down all instances of an application simultaneously, a rolling update replaces them incrementally.

The process involves creating new Pods with the updated configuration, waiting for them to become ready and healthy, and then gradually terminating the old Pods. This ensures that a minimum number of application instances are always running and serving traffic, providing a seamless transition for users.

Key Benefits

• Zero Downtime: Users experience no interruption in service during the update.
• Rollback Capability: If the new version has issues, Kubernetes can quickly revert to the previous stable version.
• Controlled Deployment: The update process is gradual and can be paused or monitored, allowing for early detection of problems.
• Resource Efficiency: New Pods are brought online before old ones are fully terminated, avoiding a complete drain on resources.

How Kubernetes Implements Rolling Updates

Rolling updates are primarily managed by the Kubernetes Deployment controller. When a Deployment's Pod template is changed (e.g., updating an image tag, environment variable, or resource limits), the Deployment initiates a new rollout.

Controlling the Rollout Strategy: `maxUnavailable` and `maxSurge`

The behavior of a rolling update can be fine-tuned using two parameters within the strategy.rollingUpdate section of a Deployment manifest:

• maxUnavailable: Specifies the maximum number of Pods that can be unavailable during the update process. This can be an 'absolute number' (e.g., 1) or a 'percentage' of the desired Pods (e.g., "25%"). If set to 0%, the deployment ensures that at least 100% of the desired Pods are always running, creating new ones before terminating old ones.
• maxSurge: Specifies the maximum number of Pods that can be created over the desired number of Pods. This can also be an 'absolute number' or a 'percentage'. For example, if maxSurge is "25%" for a deployment of 4 Pods, an additional Pod (4 * 0.25 = 1) can be created, bringing the total to 5 Pods temporarily.

The default values for both maxUnavailable and maxSurge are "25%". This means that during an update, up to 25% of the old Pods can be unavailable, and up to 25% more than the desired number of Pods can be created temporarily.

Example Deployment Manifest

Here's a simplified example of a Deployment manifest with a rolling update strategy defined:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-registry/my-app:v2.0.0 # This image is updated from v1.0.0
        ports:
        - containerPort: 80

In this example, when the image my-registry/my-app:v2.0.0 is deployed (replacing a previous version like v1.0.0), Kubernetes will ensure that at most 1 Pod is unavailable and at most 1 extra Pod is running during the transition, maintaining high availability for the 3 desired replicas.

Conclusion

Rolling updates are a cornerstone of modern application deployment in Kubernetes, enabling organizations to continuously deliver updates and features without sacrificing availability. By strategically managing the replacement of Pods, Kubernetes ensures robust and resilient application lifecycle management.