Kubernetes Rolling Update

Whenever a new code release is out and should be deployed by Kubernetes it may happen that developers are not sure how updates work in Kubernetes as you have the old application running. When they update the image version what happens to the deployment? Does it removes old pods and restart new ones with a new image? In that case, the application will not be accessible to users while the old pods get terminated as the new ones are being created. We may face application downtime which is a problem in a production environment. What if the new images have some issues? In this case how to roll back?

Rollout using ReplicaSet

When a deployment is first created it also creates what's called application rollout, and uses a component called replica set. A replicaset is created automatically when a deployment is created. It ensures that a specified number of pod replicaes are running at any given time. The flow is a deployment that creates replicaset that creates pods, so no direct interactions with replocasets or pods accept a specified number of repliocaset in the deployment TAML file.

Deployment update strategy

When we update. deployment with a new container image a new replica set gets created that is responsible for starting new pods with a new image version, while the old replicaset remains and is responsible for removing pods with the old image version. How does this update happen? In Kubernetes, we name it “Deployment Update Strategy”. The first strategy is simple, when deployment gets updated and replicaset removes old pods and a new replicaset creates new pods, it's called recreate strategy. This strategy will result in application downtime because of the time between removal and recreation. A second strategy resolves the downtime and instead of removing all pods and creating new ones, it deleted the old pod and create a new pod, and so on until all pods are created, this strategy operation use parallel automation of the pod's life cycle. It is also called rolling update and is the default strategy Kubernetes use. Using the default strategy the old replica set will remain in the cluster with zero pods in the desired and ready state while the new replicaset will be active. That is the reason why we see multiple replicasets of the same application in the cluster, if you want to see the difference always look at the prefix of the deployment and its own unique hash at the end. [deployment-name]-[randon-string]. If you want to view the strategy your deployment uses, type: kubectl describe deployment [deployment-name] and search for StrategyType. You can set the percentage of how many pods you want to roll as part of the update like max 25% Unavailable, meaning max of unavailable pods during the update. And max 25% Surge, meaning the max number that can be created.

Rollout History

when a deployment rollout triggers a new deployment revision created, a new revision is only created when the deployment template is changed. We can check it using: kubectl rollout history deployment [deployment-name].

RollBack

Every revision can help to rollback to the specific revision we want to by typing: kubectl rollout undo deployment [deployment-name] to check the status of the rollout type: kubectl rollout status deployment [deployment-name].

Join my Linkedin