In this post, we will look at the deployment options for using the Kubernetes container-orchestration system to deploy containers. We will have learned how to deploy in the Kubernetes cluster in a variety of ways by the end of this article. If you really want to learn more about this topic, keep reading the article. The code can be found in the sections below.
What are Deployments in Kubernetes?
Kubernetes deployments are just ReplicaSets wrapped in a Kubernetes wrapper. Deployment monitors the number of operating pods, whereas the ReplicaSet manages the number of running pods. This allows for rolling updates, pod health checks, and easy rollback of updates.
The Deployment will only hold a single ReplicaSet during normal operations, ensuring that the number of required pods are operating.
You should not manage the ReplicaSet that the Deployment creates directly while utilizing Deployments. All operations conducted on a ReplicaSet should instead be performed on the Deployment, managing the ReplicaSet update process.
The ability to execute rolling updates is one of the key benefits of deployment. Deployments give you a lot of flexibility over rolling updates, allowing you to update your pods’ configuration gradually.
What are the Typical Use Cases for Deployment?
Deployments are commonly used in the following scenarios:
- To roll out a ReplicaSet, create a Deployment. In the background, the ReplicaSet builds Pods. Check the progress of the deployment to check if it was successful.
- Update the Deployment’s PodTemplateSpec to reflect the changed condition of the Pods. The Deployment is in charge of managing the controlled transfer of Pods from the old to the new ReplicaSet and forming a new one. With each new ReplicaSet, the Deployment’s revision is updated.
- Increase the Deployment’s capacity to handle greater traffic.
- Pause a Deployment’s rollout to make various changes to its PodTemplateSpec, then resume it to begin a new rollout.
- The Deployment status can be used to determine whether or not a rollout has been successful.
- Remove any previous ReplicaSets that you no longer require.
Prerequisites:
First, you need to install the Minikube cluster and begin Ubuntu 20.04. Now open a terminal to run the commands. For this purpose, press the shortcut “Ctrl+Alt+T” on the keyboard.
You can also write the command “start minikube” in the terminal. After this, wait for a while till it starts. The following is the result of this instruction:
How to Create a Deployment?
In Kubernetes, deployments are formed by specifying their requirements in a YAML definition file. Let’s use the example of a deployment named deploy.yaml with the following parameters to see how a rolling update deployment is configured:
The whole configuration file may be found here. To bring up three Pods, the code below creates a ReplicaSet. In the example, the.metadata.name column indicates that a Deployment named nginx-deployment has been created. The Deployment produces three replicated Pods, according to the.spec.replicas attribute.
The Deployment’s.spec.selector field specifies how it determines which Pods to manage. In this case, you’ll use the Pod template to select a label (app: nginx). More complicated selection rules are possible if the Pod template fits the criteria.
To create the deployment, execute the given command after configuring the deployment YAML:
Use the kubectl get deployments command to see if the Deployment was created, as shown below.
If there are any ongoing deployments, you can monitor the rollout status by writing this command.
After a few seconds, run kubectl to get deployments again to see the details.
To inspect the ReplicaSet (rs) created by the Deployment, use the kubectl get rs command. Here is the result.
Run kubectl get pods —show-labels to see the automatically produced labels for each Pod. The output might look like this:
How to Update a Deployment?
To update your Deployment, follow the steps elaborated below:
Let’s change the nginx Pods to employ the following version of nginx: Instead of using the nginx:1.14.2 image, use the 1.16.1 image.
Run the given command and view the rollout status.
After the rollout is complete, use kubectl to get deployments to see the Deployment. The following is the output:
To retrieve details about your deployment, run the following command:
Assume you made a mistake when changing the Deployment and typed nginx:1.161 instead of nginx:1.16.1 in the image name:
The rollout becomes stalled. You can check the rollout’s performance here:
To stop the above deployment status watch, use Ctrl-C.
What are the Benefits of Rolling Updates?
Rolling updates enable progressive integration of changes, giving you more flexibility and control over your application’s lifespan. The following are some of the advantages of using rolling updates for Kubernetes clusters:
- There is no downtime because the application’s pod instances are always running, even during an upgrade.
- Allows developers to test the impact of changes in a production environment without interfering with the user experience.
- It is a cost-effective deployment technique because it does not require additional resources assigned to the cluster.
- Complex upgrades can be accomplished effectively by making simple modifications to a deployment file, eliminating the need for time-consuming manual migration of configuration files.
Conclusion:
This post covered the basics of deployments, how rolling updates operate, and a variety of configuration choices for fine-tuning updates and pod scheduling. You should now be able to establish and alter deployments with confidence to achieve the correct state for your application.
