Deployments in Kubernetes

Kubernetes is a container orchestration tool that helps us efficiently scale and maintain application containers. It offers a rolling update strategy, allowing us to deploy container updates without any downtime. However, depending on your application and use case, there are other deployment strategies you can consider.

Rolling Update Strategy: By using deployments in Kubernetes, we ensure that a fixed number of replicas always run in your clusters. With Max Unavailable and Max Surge, we can plan our code change deployment.

How it works: When we update our deployment with changes, such as a change in the container image, Kubernetes deletes old pods as specified by Max Unavailable while creating new pods with the latest changes as specified by Max Surge. For example, if your application’s desired state is 4 pods, with Max Unavailable set to 25% and Max Surge set to 25%, it will delete 1 old pod once a new pod is provisioned.

Canary Deployment: In this type of deployment, we can test and roll back new features directly in production with minimal user impact. As mentioned in the above example, if your application’s desired state is 4 pods, in a Canary deployment, we will create a deployment with 1 pod, while not altering the setup of the 4 pods. Using ingress, we will divert 10% of user traffic to the new code, while 90% remains on the old code. If no issues are observed, we can gradually divert traffic to the new changes while decommissioning the old environment.

Blue-Green Deployment: This is a slightly more costly approach. In this strategy, we create an exact replica of the current setup with the new code. We then point our load balancer to redirect traffic to the new environment. In case of any issues, we can simply update the load balancer to redirect traffic back to the old environment.