Understanding Kubernetes Deployment Strategies

Rolling updates, recreates, ramped rollouts, canary deployments, and more

Photo by Bill Jelen on Unsplash.

Deployment resources within Kubernetes have simplified container deployments, and they are one of the most used Kubernetes resources. Deployments manage ReplicaSets, and they help create multiple deployment strategies by appropriately manipulating them to produce the desired effect.

Surprisingly, deployments only have two Strategy types: RollingUpdate and Recreate.

While RollingUpdate is the default strategy where Kubernetes creates a new ReplicaSet and starts scaling the new ReplicaSet up and simultaneously scaling the old ReplicaSet down, the Recreate strategy scales the old ReplicaSet to zero and creates a new one with the desired replicas immediately.

That does not limit Kubernetes’ ability, though, for more advanced deployments. There are more fine-grain controls on the deployment specification that can help us implement multiple deployment patterns and strategies. Let’s look at possible scenarios, when to use them, and how they look with hands-on examples.

Recreate

Now, one might question why someone would use this, but trust me, there are use cases for this and there is a reason why Kubernetes has still allowed this to exist in their API.

Use the Recreate strategy if:

• Your application does not support multiple versions.
• You have a ReadWriteOnce volume mounted to your Pod and you cannot share it with a Replica.
• You want to stop processing old data and need to run some prerequisites before you start up your new application.

To understand further, let’s create an NGINX deployment with the Recreate strategy:

Let’s update the image and see what happens to the replica sets:

kubectl set image deployment/nginx nginx=bharamicrosystems/nginx:v2