Skip to content

Kubernetes Rolling Update Deployment Strategy

Rolling Update is the default deployment strategy used by [[kubernetes-deployments|Kubernetes Deployments]] to update applications^[400-devops__06-Kubernetes__k8s-ithelp__Day13__README.md]. Unlike strategies that replace all instances simultaneously, a Rolling Update incrementally replaces Pods to ensure service continuity.

概述

The Rolling Update strategy, often referred to as "Ramped," allows for updates without total service downtime^[400-devops__06-Kubernetes__k8s-ithelp__Day13__README.md]. It follows a "small steps, steady flow" approach where new Pods are brought up and old Pods are terminated gradually^[400-devops__06-Kubernetes__k8s-ithelp__Day13__README.md].

In Kubernetes, this is the default behavior for a Deployment resource, but it can be explicitly configured in the spec.strategy field^[400-devops__06-Kubernetes__k8s-ithelp__Day13__README.md].

Configuration Parameters

To control the pace and safety of the update, the RollingUpdate strategy utilizes two key parameters under spec.strategy.rollingUpdate:

  • maxSurge: Defines the maximum number of Pods that can be created above the desired number of replicas 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].

For example, setting maxSurge: 1 and maxUnavailable: 0 ensures that at least the original number of Pods is running at all times, allowing one extra Pod to be created temporarily^[400-devops__06-Kubernetes__k8s-ithelp__Day13__README.md].

Update Process

When a Deployment is updated (e.g., changing a container image version), the controller performs the following steps:

  1. Creates new Pods according to the maxSurge limit.
  2. Waits for new Pods to be ready.
  3. Terminates old Pods, respecting the maxUnavailable limit.

This cycle repeats until all old Pods are replaced by the new version^[400-devops__06-Kubernetes__k8s-ithelp__Day13__README.md].

Comparison with Recreate

The Rolling Update strategy contrasts with the [[kubernetes-recreate-strategy|Recreate]] strategy^[400-devops__06-Kubernetes__k8s-ithelp__Day13__README.md]. While Recreate terminates all Pods before bringing up new ones—causing service downtime—the Rolling Update ensures that the service remains available by maintaining a mix of old and new Pods during the transition^[400-devops__06-Kubernetes__k8s-ithelp__Day13__README.md].

Sources

^[400-devops__06-Kubernetes__k8s-ithelp__Day13__README.md]