A Kubernetes Deployment is used to tell Kubernetes how to create or modify instances of the pods that hold a containerized application. Deployments can scale the number of replica pods, enable rollout of updated code in a controlled manner, or roll back to an earlier deployment version if necessary.
Kubernetes automates the work and repetitive manual functions that are involved in deploying, scaling, and updating applications in production.
Since the Kubernetes deployment controller is always monitoring the health of pods and nodes, it can replace a failed pod or bypass down nodes, replacing those pods to ensure continuity of critical applications.
Deployments automate the launching of pod instances and ensure they are running as defined across all the nodes in the 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 making the desired changes at a controlled rate of change.
The recreate strategy terminates the currently running pod instances and ‘recreates’ them with the new version. Commonly used in a development environment where user activity isn’t an issue.
Recreate entirely refreshes the pods and the state of the application. As a result, there is downtime associated with both the shutdown of the old deployment and initiation of instances of the new deployment.
The rolling update strategy allows an orderly, ramped migration from one version of an application to a newer version. In this deployment a new ReplicaSet with the new version is launched, and as replicas of the new version are launched, replicas of the old version are terminated. Eventually all of the old version pods are terminated and replaced by the new version.
Rolling updates enable an orderly transition between versions, however the transition can take some time.
The Blue/Green strategy offers a rapid transition from old to new application version once the new version is tested in production. Here the new ‘green’ version is deployed along with the existing ‘blue’ version. When confident 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 switches traffic to the new version immediately.
Although this provides a rapid rollout that avoids versioning issues, this strategy requires twice the resource utilization since both versions are running until cutover.
In a canary deployment, a smaller group of users are routed to the new version of an application, which is running on a smaller subset of pods to test functionality in a production environment. Once satisfied that testing was error-free, replicas of the new version are scaled up, and the old version is thus replaced in an orderly manner.
Canary deployments are good for testing new functionality on a smaller group of users and are easily rolled back. Thus, canary deployments are good to gauge how new code will impact the overall operation of a system.
Deployments are the easiest way to manage and scale how applications run on a cluster, and Kubernetes’ open API simplifies integration into CI/CD pipelines.
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 4 replicas would look like:
- name: nginx
- containerPort: 80
Once the deployment is defined, it is created from the YAML file with:
kubectl apply -f https://[location/web-deployment.yaml]
Deployments can be updated by making changes to the Pod template spec within the deployment, which automatically causes an update rollout.
Changing the Pod template will cause running pods to stop 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, rolling back to the previous version is done with the command:
Kubectl rollout undo [deployment_name]
Adding the argument
will roll back to that specific version of the deployment
Deployments are useful for scaling the number of replicas as demand increases for a particular application and can be done the via kubectl scale command. For example, to scale a deployment up to 20 replicas, one would use:
Kubectl scale [deployment-name] –replicas 20