Kubernetes is one of the most popular automation platforms for deploying, scaling, and operating application containers on a cluster of hosts or nodes.
This article will discuss one of the central objects in Kubernetes: deployment. The goal is to understand its behavior and how to create, update, and delete it.
What is a Deployment?
A Deployment is one of the objects used to launch Pods. Kubernetes best practices encourage the use of deployments for stateless applications. Without a deployment, you would need to manually create, update, and delete multiple Pods, which would be tedious and unfeasible for many Pods.
A deployment declares a single object in YAML which not only creates the Pods but also ensures that they are up-to-date, and running. You can also easily auto-scale your applications using a deployment on Kubernetes. Thus, a deployment is used to scale, deploy, and roll back versions of your applications in Pods.
A deployment also tells Kubernetes how many copies of a Pod we want to run, and Kubernetes takes care of the rest. The associated controller will create a ReplicaSet from your configuration when creating a deployment. The controller associated with the ReplicaSet will create a series of Pods from the ReplicaSet configuration.
The advantages of using a deployment instead of directly creating a ReplicaSet are:
- Historization of the object: each change in the object (via an “apply” or an “edit”) will create a backup of the previous version.
- Rollout and rollback management: You can go back on a configuration in connection with the previous point.
Creating a Deployment
There are two methods we can use to create a Kubernetes deployment:
The Kubernetes APIs allow a more direct and imperative approach without requiring configuration files or YAML-formatted manifests. In this approach, all we need to do is say what we want done, and Kubernetes will take responsibility for defining what must be done to achieve the expected result.
To use the imperative method, just use the command below:
kubectl create deployment nginx-deployment --image nginx --port=80
In this method, you have to declare everything, and when you use this code, Kubernetes just reads your definitions and create exactly as presented or declared.
To use declarative deployment you will have to create a YAML file.
YAML file for deployment with the name
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: #Specifies the number of Pod Copies replicas: 3 #Selects the Pod to be managed by the deployment selector: #Matches the defined labels matchLabels: deploy: example template: metadata: #Specifies the labels on the Pod. labels: deploy: example spec: containers: - name: nginx image: nginx:1.20.2
In this YAML file, after defining the Kubernetes API version, the type of object you are creating, and the name of the deployment, there is the spec section. In this section, you first define the replicas key, which indicates the number of Pod instances the deployment must keep active.
Use a selector label to identify the Pods in the deployment. For this, you can use the deploy label, which tells that all pods that match these labels are grouped in deployment.
After that, you have the template object where you have a Pod model inside your deployment specification. When the deployment creates Pods, it creates them using this template. The specification of a regular pod can be found under the template key.
With this deployment, Nginx images with labels will be deployed to Pods. Moreover, you also have to be careful on this point, and the Pod is the scalability unit in Kubernetes, so you have to think about the pattern you want to use if you put several containers in the same Pod.
Next, apply the
new_deployment.yaml Yaml file, use the following command:
kubectl apply -f new_deployment.yaml
After a few seconds, you can get the deployment status using the following:
kubectl get all
Retrieve and Update Deployment
Note that you have the Pods created, the deployment and also a Replicaset. So a deployment always creates and manages a Replicaset. Now you can use the following command to describe the deployment:
kubectl describe deployment nginx-deployment
Now you have a full description of the deployment. It highlights the strategy used to create/rebuild the pods when an update has been defined as RollingUpdate.
The RollingUpdate strategy allows for an orderly migration of one version of an application to a newer version. It is the default strategy used in Kubernetes.
In addition to this, we also have the following strategies:
- Recreate: Terminates the currently running Pod instances and ‘recreates’ them with the new version;
- Blue/Green: This strategy creates two separate but identical environments. In the blue environment, the application is running as is, whereas in the green environment, the application is running as it will be in the future;
- Canary: A deployment strategy where a subset of users is involved in the incremental release of an application or service.
If you opt for “rolling-update,” you can configure its behavior about the number of replicas desired.
maxSurgeallows you to indicate (in percentage or absolute terms) how many Pods it can create in addition to the number of replicas currently configured.
maxUnavailableallows you to indicate (in percentage or absolute terms) how many Pods can be “unavailable” during the update, depending on the number of replicas configured.
Depending on your application and your autoscaler, these configurations will allow you to ensure QoS or speed up your deployments.
Next, you have to scale the Pods to 10 and change the Nginx image tag to the latest.
kubectl scale deployment nginx-deployment --replicas=10
Note that we have 5 containers being created, and out of 10 Pods, we have 5 available.
After a few seconds, use the following command:
kubectl get all
Here you can see that all Pods have been created, and the containers are running.
Deleting your Deployment
To delete a Kubernetes deployment, you can use the following commands:
kubectl delete deploy nginx-deployment kubectl delete deploy new_deployment.yaml
Helm: Simplify Deployments
When you want to deploy a complex application that uses tens or even hundreds of Kubernetes resources, the kubectl tool becomes unsuitable, which is why the Helm tool was developed. Helm is a package manager for Kubernetes that builds on kubectl and simplifies application deployments.
In the Helm vocabulary, an application is called a release. It is associated with a chart, i.e., a collection of configuration files in YAML format containing global variables and templates describing Kubernetes resources.
The deployment is an essential Kubernetes object. As a great power implies a great responsibility, you must be careful when configuring it or risk having unexpected behaviors. To go further with the Deployment configurations, you can refer to the Kubernetes documentation.
You may also explore some of the best Kubernetes tutorials to learn from scratch and become an expert.