What are Deployments in Kubernetes?

As per official documentation A Deployment provides declarative updates for Pods and ReplicaSets.

In other words Deployments are the upgraded version of ReplicaSets. They manage the deployment of replica sets (earlier known as replication Controller) and have the capability to rollout and rollback to the previous versions of pods replica sets aka application versions.

You describe a desired state in a Deployment manifest file, and the Deployment Controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.

Why and when we need Deployments?

A Deployment runs multiple replicas of your application (as described in the manifest file or while creating deployments via command line) and automatically replaces and creates new instances against the one's which gets failed or become unresponsive. In a way it supervises the pods creation and maintains rollout and rollback activities.

By doing so Kubernetes Deployments ensures that one or more instances of your application are available to serve user requests all the time. Deployments are managed by the Kubernetes Deployment controller.

Deployments are very well-suited for stateless applications such as web servers that uses volumes of type ReadOnlyMany or ReadWriteMany mounted on multiple replicas, but are not well-suited for application which uses ReadWriteOnce volume types. Using StatefulSets is recommended for stateful applications such as MySQL, Kafka, Radis which uses ReadWriteOnce volumes types.

Deployments use cases

The following are typical use cases for Deployments:

• You create a Deployment to rollout a ReplicaSet. The ReplicaSet creates Pods in the background.
• When you need to update the application you update the pods state by updating the PodTemplateSpec of the Deployment. deployment controller will move pods from old ReplicaSet to the new one created after the state change.
• When you need to Rollback to an earlier application version because of instability with the newer version. This can be quickly done by using Deployments rollback strategy.
• When you need to scale up the Deployment in order to enable your application to handle more user requests aka load.
• High Availability (HA) can be achieved using Kubernetes Deployments.

Creating a Kubernetes Deployment Object

There are two methods of creating a Kubernetes Deployment.

Method 1 - using kubectl command

You can create a Deployment object by running the following command:

root@kube-master:~# kubectl create deployment lco-deployment-demo-nginx --image=nginx
deployment.apps/lco-deployment-demo-nginx created

Verify the status of Deployment created->

root@kube-master:~# kubectl get deployments
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
lco-deployment-demo-nginx   1/1     1            1           27s

Describe the Deployment created in last step to get more details about it

root@kube-master:~# kubectl describe deployments lco-deployment-demo-nginx

You can look at couple of properties here such as label, selector, Replicas, StrategyType and so on.

Pods that are running inside Kubernetes are running on a private, isolated network. By default they are visible from other pods and services within the same kubernetes cluster, but not outside that network. When we use kubectl, we're interacting through an API endpoint to communicate with our application.

We will cover other options on how to expose your application outside the kubernetes cluster in coming articles of this series.

Method 2 - using yaml manifest file command

Here is our yaml manifest file to create a deployment

root@kube-master:~/deployment# cat deployment-demo.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: lco-deployment-demo2-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Lets understand this file in detail:

• A Deployment named lco-deployment-demo2-nginx is created, mentioned as part ofmetadata : name field.
• The Deployment will have three replicated Pods running together, mentioned as part of replicas field.
• Under the the Pod template all the pods will be labelled as app: nginx, mentioned as part of spec field.
• The Pod template's specification, or template: spec field, indicates that the Pods run one container, nginx, which runs the nginx latest version image.
• Port 80 will be open for use by the Pods in order to receive user traffic.

Apply and create the Deployment->

You can create a Deployment by running the following command:

root@kube-master:~/deployment# kubectl apply -f deployment-demo.yml
deployment.apps/lco-deployment-demo2-nginx created

Verify the status of Deployment created->

root@kube-master:~/deployment# kubectl get deployments -o wide

Check the associated pods status->

root@kube-master:~/deployment# kubectl get pods

Describe the Deployment created in last step to get more details about it

root@kube-master:~/deployment# kubectl describe deployments lco-deployment-demo2-nginx

Deleting a Deployment

To delete a Deployment run the following kubectl command:

root@kube-master:~/deployment# kubectl delete deployments lco-deployment-demo2-nginx
deployment.apps "lco-deployment-demo2-nginx" deleted

Deployment Status and lifecycle

Deployments once created can be in one of three states during its lifecycle: progressing, completed, or failed.

progressing - This state indicates that the Deployment is in process of performing its tasks, like bringing up or scaling its Pods, creating new ReplicaSets, scaling down old ReplicaSet etc.

completed - This state indicates that the Deployment has successfully completed all its tasks like all the Replicas are updated as per their desired state configuration, no more old Replicas running etc.

failed - This state indicates that the Deployment has not completed all of its tasks and in between encountered one or more issues that preventing it from doing so. There might be multiple reasons but the common one's are like insufficient quotas or permissions, container image pull errors, limit ranges, or any runtime errors. Further investigation can be done using kubectl command and verify the status: conditions field. Another way is to see the event logs using kubectl get events command.

This is all about Kubernetes Deployments. In coming articles we will learn about Rolling out and Rolling back updates using Kubernetes deployments.

Hope you like the tutorial. Stay tuned and don't forget to provide your feedback in the response section.

Happy Learning!