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.
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
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.
- simple implementation
- no downtime between the version rollout
- easy to rollout/rollback
- convenient for stateful applications that can handle rebalancing of the data
- Rollout/Rollback takes time
- no control over traffic
Recreate Strategy, is like all-or nothing process. All the previous version pods are deleted and pods of the new version is recreated.
- easy to implement.
- Application state is entirely renewed.
- Has a downtime, that depends on the shutdown and booting up of the application.
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.
- version released for a subset of users
- convenient for error rate and performance monitoring
- fast rollback
- 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 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.
- instant rollout/rollback
- avoid versioning issue, change the entire cluster state in one go
- 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.
- A deep dive into Kubernetes Deployment strategies (educative.io)
- Kubernetes deployment strategies (container-solutions.com)
- Intro to Deployment Strategies: Blue-Green, Canary, and More | Harness