A Kubernetes Deployment tells Kubernetes how to create or modify instances of the pods that hold a containerized application. Deployments can help to efficiently scale the number of replica pods, enable the rollout of updated code in a controlled manner, or roll back to an earlier deployment version if necessary. Kubernetes deployments are completed using kubectl, the command-line tool that can be installed on various platforms, including Linux, macOS, and Windows.
Kubernetes saves time and mitigates errors by automating the work and repetitive manual functions involved in deploying, scaling, and updating applications in production. Since the Kubernetes deployment controller continuously monitors the health of pods and nodes, it can make changes in real-time—like replacing a failed pod or bypassing down nodes—to ensure the continuity of critical applications.
Deployments automate the launching of pod instances and ensure they are running as defined across all the nodes in the Kubernetes cluster. More automation translates to faster deployments with fewer errors.
Kubernetes offers several deployment strategies to handle a broad range of application development and deployment needs. Once you define the desired state of the application, the deployment controller goes to work. It can make changes at a controlled rate to optimize the deployment.
The recreate strategy terminates pods that are currently running and ‘recreates’ them with the new version. This approach is commonly used in a development environment where user activity isn’t an issue.
Because the recreate deployment entirely refreshes the pods and the state of the application, you can expect downtime due to the shutdown of the old deployment and the initiation of new deployment instances.
The rolling update deployment provides an orderly, ramped migration from one version of an application to a newer version. A new ReplicaSet with the new version is launched, and replicas of the old version are terminated systematically as replicas of the new version launch. Eventually, all pods from the old version are replaced by the new version.
The rolling update deployment is beneficial because it provides an organized transition between versions. However, it can take time to complete.
The Blue/Green strategy offers a rapid transition from the old to new version once the new version is tested in production. Here the new ‘green’ version is deployed along with the existing ‘blue’ version. Once there is enough confidence that the ‘green’ version is working as designed, the version label is replaced in the selector field of the Kubernetes Service object that performs load balancing. This action immediately switches traffic to the new version.
The Kubernetes blue/green deployment option provides a rapid rollout that avoids versioning issues. However, this strategy doubles the resource utilization since both versions run until cutover.
In a canary deployment, a small group of users is routed to the new version of an application, which runs on a smaller subset of pods. The purpose of this approach is to test functionality in a production environment. Once satisfied that testing is error-free, replicas of the new version are scaled up, and the old version is replaced in an orderly manner.
Canary deployments are beneficial when you want to test new functionality on a smaller group of users. Since you can easily roll back canary deployments, this strategy helps gauge how new code will impact the overall system operation without significant risk.
Deployments are the easiest way to manage and scale how applications run on a Kubernetes cluster, and Kubernetes’ open API simplifies integration into CI/CD pipelines.
Here are some common use cases for deployments:
As with most Kubernetes functions, deployments are described in YAML (or JSON) files and then are created using kubectl apply.
For example, the YAML for an Nginx deployment called ‘web-deployment’ with four replicas would look like:
- name: nginx
ports:- containerPort: 80
In this example, the metadata shows that the ‘web-deployment’ was created with four replicated pods (replicas: 4), and the selector specifies how the deployment will find the pods using the label (app: nginx). The container (nginx) runs the container image at version 1.17.0, and the deployment will open port 80 for the pods to use.
You may also define environment variables for the containers by using the ‘env’ or ‘envFrom’ field in the configuration file. Once the deployment is defined, it is created from the YAML file with: kubectl apply -f https://[location/web-deployment.yaml]
You can update a Kubernetes deployment by changing the pod template spec within the deployment. That will automatically cause an update rollout.
Changing the Pod template will prevent running pods from accepting requests so they can be scaled back until all pods can be terminated. Once they have been terminated, the updated pod template will be used to create new pods.
If a deployment is deemed unstable or if there was an error in the deployment, you can roll back and update using kubectl. To roll back to the previous version, use the following command:
Kubectl rollout undo [deployment_name] Adding the argument–to-revision=will roll back to that specific version of the deployment
Deployments help scale the number of replicas as demand increases for a particular application. Use the kubectl scale command to perform this task. For example, to scale a deployment up to 20 replicas, enter the following into the command line:
Kubectl scale [deployment-name] –replicas 20