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
- name: nginx
kubectl apply -f rolling-update-deployment.yaml to create the
Deployment. A quick listing will show 3
Pods running as follows.
Now we’re going to use the
kubectl set image command to perform a rolling update that will replace the 3
library/nginx:1.20.0, with 3 new
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 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
maxSurge attribute indicates the maximum number of Pods that should be created. In the
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.
maxUnavailable tells Kubernetes the maximum number of Pods that can be unavailable during a rolling update. In the
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
maxUnavailable can be specified as a percentage of the number of Pod replicas, or as an absolute value.
- name: nginx
The sample code for these notes is available on Github.