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.

---