Daily Exercise 002: How-Kubernetes-Deployments-Work

Day 1 Script

Today we will discuss how deployments in Kubernetes work, specifically how you can use them for reliable zero downtime upgrades. Suppose you have a simple application with three replicas controlled by a deployment. These replicas are pods and a load balancer provides traffic to each of them. In the deployment, you are likely using the first version of your container image. This means each of your three pods is running version one of your application. When you decide to push a new image to the deployment object, it will trigger a rollout process. The deployment itself takes responsibility for updating your application across the cluster. We will explore how this happens without interrupting the service for your users.

Day 1 Translate

Day 2 Script

When you change your deployment from version one to version two, the update does not happen immediately. It is not as if all your containers are replaced at the exact same moment. There are two main reasons for this gradual approach. First, if we replaced everything at once, we would take down every replica of your service and it would be unavailable. Second, you might have flaws in the new version. You do not want to move everything to version two if it is going to start crashing. Therefore, we need to perform a gradual rollout from one version to the next while maintaining access for all users. This careful process ensures that your application remains stable and available throughout the entire upgrade.

Day 2 Translate

Day 3 Script

To achieve a smooth rollout, Kubernetes uses two important concepts called liveness checks and readiness checks. Together, these define what it means for a pod to be healthy. A liveness check determines if a pod should be automatically restarted, for example if the application is stuck. A readiness check determines if your application is actually ready to serve traffic. When you change the version to version two, the deployment creates a new replica of your application. Assuming the container passes its liveness check, the system keeps it running but does not add it to the load balancer yet. Only when the readiness check passes, traffic is directed from the load balancer to this new container.

Day 3 Translate

Day 4 Script

Once the new container is up and serving traffic, the deployment decides to delete one of the old pods. However, we must ensure that existing user traffic is not interrupted during this deletion. To handle this, every pod has something called a termination grace period. By default, this period lasts for thirty seconds. When the deployment decides to delete a pod, the pod moves into a terminating state. The connection to the load balancer is severed, but the container stays running for the rest of the grace period. This means any active requests are processed successfully, but no new requests are sent to the old container. After thirty seconds, the container is fully deleted and removed from the system.

Day 4 Translate

Day 5 Script

After the first old pod is removed, the deployment moves on and creates another new pod. The same process repeats where the system waits for the liveness and readiness checks to pass. Once the new container is ready, traffic is directed to it and another old pod is scheduled for deletion. This cycle continues until all replicas are running version two. The deployment is also highly configurable. You can change how many containers are updated at a time or how long to wait between updates. You can even choose to add extra containers during the process to maintain capacity. This gives you a powerful way to manage application upgrades with zero downtime in your cluster.

Day 5 Translate