Skip to content

Kubernetes Deployment Strategy: RollingUpdate

RollingUpdate (also known as Ramped Rolling-update) is the default deployment strategy for Deployment resources in Kubernetes^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

Unlike the [[Recreate]] strategy, which terminates all instances before starting new ones, RollingUpdate gradually replaces instances to ensure the service remains available with no downtime^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

Core Mechanism

The strategy operates on a "step-by-step" principle, incrementally updating Pods until all instances are running the new version^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md]. It is explicitly configured in the spec section of a Deployment manifest^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

Configuration Parameters

To control the rate and stability of the update, RollingUpdate uses two specific parameters under spec.strategy.rollingUpdate^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md]:

  • maxSurge: Defines the maximum number of Pods that can be created above the desired replica count during the update^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].
  • maxUnavailable: Defines the maximum number of Pods that can be unavailable during the update process^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

Example Configuration

In a YAML manifest, this strategy is applied as follows^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md]:

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    # ...

Update Process

When a Deployment is updated (e.g., changing the image version), the controller manages the transition based on the maxSurge and maxUnavailable settings^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

For example, with maxSurge: 1 and maxUnavailable: 0: 1. A new Pod is created (increasing the total count). 2. Once the new Pod is Ready, an old Pod is terminated. 3. This cycle repeats until all Pods are replaced^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

This ensures that the service capacity is maintained or temporarily increased, but never drops below the minimum required availability^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

Sources

^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md]