Rolling Updates & Rollbacks

Rolling updates provide a mechanism for updating containers in a cluster without downtime. This powerful Kubernetes feature allows you to update containers while maintaining high availability.

To see this in action we’ll create a Deployment consisting of 3 nginx Pods using the definition below. Note that the container image we’re going to run is library/nginx:1.20.0.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: library/nginx:1.20.0
          imagePullPolicy: IfNotPresent

Run kubectl apply -f rolling-update-deployment.yaml to create the Deployment.  A quick listing will show 3 Pods running as follows.

Rolling Update

Now we’re going to use the kubectl set image command to perform a rolling update that will replace the 3 Pods running library/nginx:1.20.0, with 3 new Pods running library/nginx:1.21.0.  Kubernetes will perform these updates incrementally to ensure service availability is maintained.

The full command is kubectl set image deployment/rolling-update-deployment nginx=nginx:1.21.0 --record.

• deployment/rolling-update-deployment is the name of the Deployment we want to update
• nginx=nginx:1.21.0 is the name of the container followed by the new image we want to run
• --record tells Kubernetes to record the update information so that it can be used to roll back the update later, if needs be

After running the above command you can run kubectl get pods -w to tail the Pod activity in the default namespace.

The screenshot above shows new Pods being stood up and the existing Pods being terminated. Note that existing Pods aren’t terminated until a replacement is running.

Rollbacks

Rollbacks allow you to revert changes by rolling back to a previous cluster state. The  rollout history command displays a list of previous updates. For example, rollout history deployment/rolling-update-deployment.

To see detail for a specific deployment use the --revision flag as follows.  rollout history deployment/rolling-update-deployment --revision 2 displays detail associated with revision 2.

To undo the last revision use the kubectl rollout undo command. For example, kubectl rollout undo deployment/rolling-update-deployment. If you want to roll back to a specific revision you can use the --to-revision=<revision_number>, for example, kubectl rollout undo deployment/rolling-update-deployment --to-revision=2

Rolling Update Strategy

Kubernetes allows you to control the minimum and maximum number of pods that will run as part of a rolling update or roll back, using strategy.rollingUpdate. The maxSurge attribute indicates the maximum number of Pods that should be created. In the Deployment below, maxSurge is set at 50% which means that Kubernetes will not create more than 50% additional Pods as part of a rolling update. The Deployment specifies 4 Pod replicas by default, so no more than 6 Pods will ever run as part of a rolling update.

Similarly maxUnavailable tells Kubernetes the maximum number of Pods that can be unavailable during a rolling update. In the Deployment below maxUnavailable is set at 50% which means that Kubernetes will not allow the maximum unavailable Pods to fall below 50% of the specified number of replicas. Given that the Deployment specifies 4 Pod replicas, no more than 2 Pods will ever be unavailable as part of a rolling update.

Note that both maxSurge and maxUnavailable can be specified as a percentage of the number of Pod replicas, or as an absolute value.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update-deployment
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 50%
      maxUnavailable: 50%
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: library/nginx:1.20.0
          imagePullPolicy: IfNotPresent

The sample code for these notes is available on Github.