Pausing the rollout process

Trigger a rollout by changing the image to luksa/kubia:v4, but then immediately (within a few seconds) pause the rollout:

kubectl set image deployment kubia nodejs=luksa/kubia:v4

deployment.apps "kubia" image updated

kubectl rollout pause deployment kubia

deployment.apps "kubia" paused

A single new pod should have been created, but all original pods should also still be running. Once the new pod is up, a part of all requests to the service will be redirected to the new pod. This way, you’ve effectively run a canary release.

kubectl get rs

NAME               DESIRED   CURRENT   READY     AGE
kubia-54c887cf4d   0         0         0         31m
kubia-5857d5f9ff   0         0         0         39m
kubia-6bb8b7b85c   1         1         1         52s
kubia-6fc8ff6566   3         3         3         57m

A canary release is a technique for minimizing the risk of rolling out a bad version of an application and it affecting all your users. Instead of rolling out the new version to everyone, you replace only one or a small number of old pods with new ones. This way only a small number of users will initially hit the new version. You can then verify whether the new version is working fine or not and then either continue the rollout across all remaining pods or roll back to the previous version.

while true; do curl 35.232.43.157:32229; done

This is v4 running in pod kubia-6bb8b7b85c-zhh9t
This is v1 running in pod kubia-6fc8ff6566-vh5zj
This is v1 running in pod kubia-6fc8ff6566-9j26j
^C

Once you’re confident the new version works as it should, you can resume the deployment to replace all the old pods with new ones:

kubectl rollout resume deployment kubia

deployment.apps "kubia" resumed

kubectl get rs

NAME               DESIRED   CURRENT   READY     AGE
kubia-54c887cf4d   0         0         0         36m
kubia-5857d5f9ff   0         0         0         43m
kubia-6bb8b7b85c   3         3         3         5m

Obviously, having to pause the deployment at an exact point in the rollout process isn’t what you want to do. In the future, a new upgrade strategy may do that automatically, but currently, the proper way of performing a canary release is by using two different Deployments and scaling them appropriately.

Pausing a Deployment can also be used to prevent updates to the Deployment from kicking off the rollout process, allowing you to make multiple changes to the Deployment and starting the rollout only when you’re done making all the necessary changes. Once you’re ready for changes to take effect, you resume the Deployment and the rollout process will start.

If a Deployment is paused, the undo command won’t undo it until you resume the Deployment.