Once we have a running Kubernetes cluster, we can deploy your containerized applications on top of it. To accomplish this, we must first create a Kubernetes Deployment configuration. And that's the topic for this post.
A Deployment provides declarative updates for Pods and ReplicaSets. It describes the life cycle of an application, such as which images to use for the app, the number of pods that should exist, and how they should be updated. Once the Deployment is created, the Kubernetes control plane schedules the application instances included in that Deployment to run on individual Nodes in the cluster.
Before we proceed with the deployment, let's have a quick recap of what we've learned in the previous posts. When we run kubectl run, we see that the following components are created in our cluster.
- a deployment
- a ReplicaSet
- a pod
Now you're probably wondering why we get three different objects rather than just one container. These Kubernetes objects ensure that you can deploy, roll back, and scale your applications without any downtime.
As we know, the smallest unit of deployment is a pod rather than a container. A pod is simply a group of containers (or a single container) that run on the same machine and share a few resources. However we can never create a standalone container; the closest we can do is create a pod that contains a single container. That's what happens when we tell Kubernetes, "create me some ABC!" We're really saying, "I'd like a pod with a single container using the ABC image."
Now we have a pod, but why do we need replica sets when we can just have a pod. Kubernetes is a system that is declarative. This means we can't give it commands. We can't say, "Run this container". We can describe what we want and wait for Kubernetes to act to reconcile what we have and what we want. In other words, we can say, "I'd like a ABC POD with XYZ container that will run xyz image", and kubernetes will find such a container for us. If it's already there, it will do nothing since what we have already matches with what we want. If it doesn't exist, it will built it.
If we have a pod and we want more identical pod, we can ask kubernetes, "I'd like a POD named ABC, with the following specifications and re-use the same specifications as before". Then repeat as many times as we want to have pods. This is inconvenient because it is now our responsibility to keep track of all these pods and ensure that they are all in sync and follow the same specifications.
To make things easier, Kubernetes provides us with the replica set. A replica set specification is similar to a pod specification, except it includes a number indicating how many replicas we want. So we tell Kubernetes, "I'd like a replica set named web, with 4 pods that meet the following criteria:..." and Kubernetes will ensure that there are exactly 4 matching pods. The 4 pods will be created if we start from scratch. Nothing is done if we already have 4 pods because what we have already matches what we want.
What if, we change the replica set specification. Suddenly, there will be no pods that meet the new requirements. But, as kubernetes is declarative system, it should immediately create N pods matching the new specification. The old pods would simply remain until we manually cleaned them up. Wouldn't it be great if these pods could be removed automatically and the creation of new pods could be done more gradually.
This is precisely the function of deployments. The deployment specification appears to be very similar to the replica set specification. It includes a pod specification and a number of replicas. However, deployments do not directly create or delete pods. They assign that task to one or more replica sets. When we create a deployment, it creates a replica set based on the exact pod specifications we provide.
Why do we need Kubernetes Deployment?
Manually updating containerized applications can be tedious and time consuming. Upgrading a service to the next version necessitates starting the new version of the pod, stopping the old version of the pod, waiting and verifying that the new version has launched successfully, and sometimes rolling everything back to a previous version if it fails. Manually performing these steps can result in human errors, and properly scripting can require a significant amount of effort, both of which can cause the release process to become a bottleneck.
A Kubernetes deployment automates and repeats this process. The Kubernetes backend completely manages deployments, and the entire update process is performed on the server side without client interaction. A deployment ensures that the desired number of pods are always running and available. The update process is also fully documented and versioned, with options to pause, continue, and revert to previous versions.
Deployments are created by writing a manifest. The manifest is then applied to the Kubernetes cluster with kubectl apply, or a declarative deployment pattern can be used. Kubernetes configuration files can be written in YAML or JSON.
Kubernetes Deployment Strategies
There are two strategies available for a Kubernetes deployment: "Recreate" and "RollingUpdate."
The recreate strategy will first terminate all pods and then create new pods based on the replicas value based on the deployment changes. Recreate completely refreshes the pods and the application's state. As a result, there is downtime associated with both the shutdown of the old deployment and the initiation of new deployment instances.
On other hand, in RollingUpdate strategy, the Deployment updates the pods in a rolling fashion, ensuring that no downtime occurs for the apps running within the pods.
The rollout lifecycle is divided into three stages: progressing, complete, and failed. While performing update tasks, such as updating or scaling pods, a deployment is progressing. Complete indicates that all tasks were successfully completed and that the system is in the desired state. A failed state is caused by an error that prevents the deployment from completing its tasks.
Within this strategy, two additional optional fields are available -
maxUnavailable - We can use this field to specify how many pods or what percentage of pods can be brought down at any given time.
maxSurge - With this field, we can specify the maximum number of pods that can be created in excess of the desired number.
With that, I'll conclude this post.
Thank you for reading!
*** Explore | Share | Grow ***
Comments