Kubernetes: Rolling Updates and Rollbacks

In the last article we studied about Static Pods. Now let us study about Rolling updates and Rollbacks and deployment strategies.
Roll-out and versioning are an important feature of kubernetes deployment. Each deployment creates a version of a deployment and it allows us to go back to last version of deployment if required. This is known as rollback.
We can have below deployment strategies
recreate: terminate the old version and release the new one
ramped/rolling: release a new version on a rolling update fashion, one after the other
blue/green: release a new version alongside the old version then switch traffic
canary: release a new version to a subset of users, then proceed to a full rollout
When using the RollingUpdate strategy, there are two more options that let you fine-tune the update process:
maxSurge: The number of pods that can be created above the desired amount of pods during an update
maxUnavailable: The number of pods that can be unavailable during the update process
Both maxSurge and maxUnavailable can be specified as either an integer (e.g. 2) or a percentage (e.g. 50%), and they cannot both be zero. When specified as an integer, it represents the actual number of pods; when specifying a percentage, that percentage of the desired number of pods is used, rounded down. Let's understand it in a better way by taking an example.
Create a deployment definition file like below
[root@node1 kubernetes]# cat nginx_deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 10
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
[root@node1 kubernetes]# kubectl create ns test
Now let us update the version of nginx from 14.1 to 16.1 and see how it happens.

Rollout History and rollback

kubectl rollout undo deployment.v1.apps/nginx-deployment
kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
So this is how we can update a deployment and if something is not right we can go the the previous version as well.
That is it for this article. In the next one we are going to study about ConfigMaps in Kubernetes.