What is a Kubernetes Deployment?

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. 

What is a Kubernetes Recreate Deployment?

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.

What is a Kubernetes Rolling Update 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.

What is a Kubernetes Blue/Green Deployment?

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.

What is a Kubernetes Canary Deployment?

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:

• A popular use case for Kubernetes is to run stateless web servers like the popular open source nginx. The deployment can request a fixed number of pod replicas be instantiated, and Kubernetes will maintain that number of pods during the deployment.
• Applications that require persistent storage like a database instance would use the StatefulSet type deployment and mount a persistent volume to ensure data integrity and longevity.
• Deployments can automatically scale the number of replicas in the cluster as the workload increases, automatically balancing incoming requests between the replicas, creating new replicas as demand increases, and terminating replicas as demand subsides.

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:

apiVersion: apps/v1;

kind: Deployment

metadata:

name: web-deploymentspec:

selector:

matchLabels:

app: nginx

replicas: 4

template:

metadata:

labels:

app: nginx

spec:

containers:

- name: nginx

image: nginx:1.17.0

ports:- containerPort: 80

Once the deployment is defined, it is created from the YAML file with: kubectl apply -f https://[location/web-deployment.yaml]

What is the difference between JSON and YAML in Kubernetes?

Both YAML (YAML Ain’t Markup Language) and JSON (JavaScript Object Notation) can be used to define Kubernetes resources. Many users prefer YAML for its readability. However, since YAML is a superset of JSON, any valid JSON file is also a valid YAML file.

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–to-revision=will roll back to that specific version of the deployment