Rolling Updates and Rollbacks in Kubernetes
What is Rollout and Versioning in Kubernetes:
To understand the Rolling updates and Rollbacks in Kubernetes, we first need to understand, what is Rollout and Versioning in Kubernetes.
When we first create a deployment, it triggers a rollout and a new rollout creates a new deployment revision (Let’s call it revision1 for our understanding).
In the future, when the application is upgraded, meaning when the container version is updated to a new one, a new rollout is triggered and a new deployment revision is created (Let’s call it revision2 for our understanding).
This helps us to track the changes made to our deployment and enables us to roll back to a previous version of deployment if necessary.
- To see the status of our rollout, run the following command:
>kubectl rollout status deploy -n kube-system coredns
waiting for rollout to finish: 0 of 10 updated replicas are available...
waiting for rollout to finish: 1 of 10 updated replicas are available...
waiting for rollout to finish: 2 of 10 updated replicas are available...
waiting for rollout to finish: 3 of 10 updated replicas are available...
waiting for rollout to finish: 4 of 10 updated replicas are available...
waiting for rollout to finish: 5 of 10 updated replicas are available...
waiting for rollout to finish: 6 of 10 updated replicas are available...
waiting for rollout to finish: 7 of 10 updated replicas are available...
waiting for rollout to finish: 8 of 10 updated replicas are available...
waiting for rollout to finish: 9 of 10 updated replicas are available...
deployment "coredns" successfully rolled out- To see the revision and the history of rollout run the following command:
# kubectl rollout history deployment -n kube-system coredns
REVISION CHANGE-CAUSE
1 <none>
2 kubectl apply -f cordens.yaml --record=trueDeployment Strategy in Kubernetes
There are 2 types of deployment strategies. (Let’s say, we have five replicas of our web application instances).
One way to upgrade these to a newer version is to destroy all of these and create a newer version of application instances, which means first Destroy the five running instances and then deploy the five new instances of the new application version.
As understandable, the problem with this is that during the period of time after the older versions are down and before any newer version is up, the application is down and inaccessible to users.
This strategy is called, Recreate Strategy and it’s not the default deployment strategy.
The second strategy is where we did not destroy all of them at once. Instead, we take down the older version and bring up the newer version one by one. This way the application never goes down and the upgrade is seamless.
Remember, if you do not specify your strategy while creating the deployment, it will assume it to rollingUpdate. Means rollingUpdate is the default deployment strategy.
Application Update in Kubernetes:
An application update could be different things, such as updating the application version by updating the version of docker containers, updating their labels or updating the number of replicas, etc.
Let’s say we already have a deployment definition file, as below:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: default-http-backend
version: 1.0
name: default-http-backend
spec:
replicas: 3
selector:
matchLabels:
app: default-http-backend
version: 1.0
spec:
containers:
- image: ingress-nginx
name: default-http-backend
ports:
- containerPort: 8080
protocol: TCP
restartPolicy: Always
schedulerName: default-scheduler spec:
containers:
- image: ingress-nginx
name: default-http-backend
ports:
- containerPort: 8080
protocol: TCP
restartPolicy: Always
schedulerName: default-scheduler
Let’s change the image version in the deployment definition file:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: default-http-backend
version: 1.0
name: default-http-backend
spec:
replicas: 3
selector:
matchLabels:
app: default-http-backend
version: 1.0
spec:
containers:
- image: ingress-nginx:1.9.1
name: default-http-backend
ports:
- containerPort: 8080
protocol: TCP
restartPolicy: Always
schedulerName: default-schedulerOnce we make the necessary changes, we need to run the below command to apply the changes:
# kubectl apply -f deployment-definiation.yaml
deployment "default-http-backend" configuredAt same time, a new rollout is triggered and a new revision after deployment is created.
But there is another way to do the same thing, we can use the below command to update the image of our application:
# kubectl set image deployment/default-http-backend ingress-nginx=ingress-nginx:1.9.1
deployment "default-http-backend" image is updatedNote *** This way our deployment definition file will not be updated with the new image configuration. So we should be very careful when using the same definition file to make changes in the future. ***
Upgrade Kubernetes Deployment
Let’s understand how a deployment performs an upgrade!!!
When a new deployment is created, say to deploy 5 replicas, it first creates a replicaSet automatically, which in turn creates the number of pods required to meet the number of replicas.
When we upgrade the application, the Kubernetes deployment objects create a new replicaSet under the hood and start deploying the containers there, at the same time taking down the Pods in the old replicaSet following a rolling update strategy.
This can be seen, when we list the ReplicaSet with the following command:
# kubectl get replicasets
NAME DESIRED CURRENT READY AGE
default-http-backend-84c75b9cd 0 0 0 20m
default-http-backend-8c8fb949c 3 3 3 18mHere we can see the old replicaSet with 0 pods and the new replicaset with 3 pods
Rollback Kubernetes Deployment
Now, Let’s say once we upgrade our application, we realize something is wrong with the new version of the build, we used to upgrade. So we need to rollback our upgrade.
Kubernetes deployments allow us to rollback to a previous revision. To undo a change run the following command:
$ kubectl rollout undo deployment <name_of_deployment>
# kubectl rollout undo deployment default-http-backend
deployment "default-http-backend" rolled backThe Deployment will then destroy the pod in the new replicaset and bring the older one up in the old replica set (in same fashion, it did at the time of upgrade) and the application is back to its older format.
When you compare the output with the “kubectl get replicaset” command, you will be able to see the difference before and after the rollback
#### Output after the Rollback ####
# kubectl get replicasets
NAME DESIRED CURRENT READY AGE
default-http-backend-84c75b9cd 3 3 3 20m
default-http-backend-8c8fb949c 0 0 0 18mSome Important command for Kubernetes Deployment:
Create the Deployment : #kubectl create -f deployment-definiation.yml
Get the Deployment: #kubectl get deployments
Update the deployment: #kubectl apply -f deployment-definiation.yml
Update the deployment: #kubectl set image deployment <deployment_name> nginx=nginx:1.9.1
Status of deployment: #kubectl rollout status deployment <deployment_name>
History of deployment: #kubectl rollout history deployment <deployment_name>
Rollback of deployment: #kubectl rollout undo deployment <deployment_name>
Rolling Restart of Deployment: #kubectl rollout restart deployment <deployment_name>
That’s it for Kubernetes Deployment Strategies and Rollback/restart. Thanks for reading!!!
If this post was helpful, please click the clap 👏 button below a few times and follow to show your support.
Refer following articles for more insights on Kubernetes:-
Kubernetes workflow for Absolute Beginners
How kubectl apply command works?
Multiple Schedulers in Kubernetes
Kubernetes Services for Absolute Beginners — NodePort
Kubernetes Services for Absolute Beginners — ClusterIP
Special Thanks to Mumshad Mannambeth for the Ultimate CKA course: certified-kubernetes-administrator-with-practice-tests
