Introduction to Kubernetes Deployment Strategies

Table of contents

Reading Time: 3 minutes

Kubernetes provides Deployment resource which tells the Kubernetes the desired state for the application.
Deployment are declarative, which means that they have what to achieve not how to achieve. To achieve this desired state, under the hood deployment uses ReplicaSets, which further maintains the required sets of the pods.

Update in Deployments

Using deployment we can achieve the desired state of an application in K8s Cluster, but what if we have to update the version of the application.
In this case K8s Deployment helps in updating the application. Without the Deployment, we have to manually update the application by creating the new version pods and deleting the old version pods, then check if every thing is working as expected.
Deployment automate this whole process, we can simply update the pod template of the desired state then give it to the K8s, in background it will do all the necessary action to met the new desired state.
In case you want to go back to the previous configuration then also you can easily go back to the previous desired state of the deployment.

Deployment Strategies

K8s Deployment has different types of strategies to update the deployment. Each has difference in the way to how the achieve the new desired state.

Rolling Update
Recreate
Canary
Blue/Green

Rolling Update

Rolling Update Strategy is the default strategy used by Kubernetes.
In this the deployment strategy, a new pod with new version is created when that pod is up and running then the connection from the old version pod is directed towards the new version, gradually all the old version pods are replaced and the deployment is updated.

Pros

simple implementation
no downtime between the version rollout
easy to rollout/rollback
convenient for stateful applications that can handle rebalancing of the data

Cons

Rollout/Rollback takes time
no control over traffic

Recreate

Recreate Strategy, is like all-or nothing process. All the previous version pods are deleted and pods of the new version is recreated.

Pros

easy to implement.
Application state is entirely renewed.

Cons

Has a downtime, that depends on the shutdown and booting up of the application.

Canary

The canary deployment is a deployment strategy that releases an application or service incrementally to a subset of users. A canary release is the lowest risk-prone, compared to all other deployment strategies, because of this control.

Pros

version released for a subset of users
convenient for error rate and performance monitoring
fast rollback

Cons

slow rollout
fine tuned traffic distribution can be expensive (99% A/ 1%B = 99 pod A, 1 pod B) nay have to use additional tools like Istio and Linkerd.

Blue/Green

Blue-green deployment is a deployment strategy that utilizes two identical environments, a “blue” (aka staging) and a “green” (aka production) environment with different versions of an application or service.
Both are simultaneously deployed, after the testing of the newer version, K8s service that plays the role of load balancer is updated to send traffic to the newer version.

Pros

instant rollout/rollback
avoid versioning issue, change the entire cluster state in one go

Cons

requires double the resources
proper test of the entire platform should be done before releasing to production
handling stateful applications can be hard

To Sum Up

There are different ways to deploy an application, when releasing to development/staging environments, a recreate or rolling update deployment is usually a good choice.
When it comes to production and no downtime it is a good choice to go for rolling update or blue/green.
If the stability is not guaranteed and may effect release then it is a good choice to go for canary. This way the consumer will themselves test the application.
It depends on how we want to use the deployment and how we want it to be.