About Deployment in Kubernetes

In this blog we will discuss about one of the most high-level object in kubernetes that is Deployment object.

What is Deployment in kubernetes ?

Deployment is a one of the high-level object in kubernetes that works on top of replica set. A Kubernetes Deployment is a resource object that provides updates and rollbacks to applications. Deployment handles the entire software update process without user intervention. This eliminates the need to manually update and deploy applications, which is time-consuming and may lead to human error. Pods and Deployments are the basic building blocks of large-scale Kubernetes environments
a deployment is a management tool used to control the way pods behave.

Why do we need Deployment object in kubernetes ?

Let me give an example if I am running the whatsapp application. Suppose if I gave two releases for the application both the versions are working well. Now I want to release the new version of the application that is the third release. After the third release, users reported a few issues (let say new users are not able to login to the application). In this situation I want to revert back to the older version of the application which was bug free.

At this point deployment will revert back to the older version very quickly.

Like replicaset creates the new pod when any of the pod goes down. in the same way deployment will create the replicaset if we delete rs accidentally.

Manifest file to create deployment

Example 1:- In this manifest we will see the basic deployment manifest.

kind: Deployment
apiVersion: apps/v1
metadata:
   name: whats-app
spec:
   replicas: 2
   selector:     
    matchLabels:
     name: whats-app1
   template:
     metadata:
       name: testpod
       labels:
         name: whats-app1
     spec:
      containers:
        - name: c00
          image: ubuntu
          command: ["/bin/bash", "-c", "while true; do echo whats-app is running; sleep 5; done"]

Properties inside the above deployment manifest:-

1. Kind:- deployment (which represents the kubernetes object)
2. apiVersion:- apps/v1
3. metadata:- contains the information about the deployment
4. spec:- specifications of the deployment. Behind the scences which will create the replica set based on this specifications.
5. replicas:- 3(this number defines the number of replicas that we want to create the pods under the replica set)
6. selector:- very imporant property in the deployment. Based on the selector match lable, deployment and replica set the pods.
7. Template:- this contains the pod specifications. In this we need to give the pod lable which will match the deployment selector.

Note:-

1. when we update pod specifications like image, metadata or port etc. At the time of updating the deployment every time deployment will create a new revision with number.
2. Find the below image which will give the deep understanding about the deployment object.
3. Important thing to notice here is when we revert back to the previous version of the deployment. it will keep the number of pods that are mentioned in current replica number.

Like in the below diagram this replica set works on top of pods. Deployment will work on top of Replica set.

Let’s Do hands on

Command to apply the manifest file. Save the above manifest file with deployment-1.yaml.

To apply the deployment

kubectl apply -f deployment-1.yaml

To know the deployment objects running inside the cluster.

kubectl get deploy

To know the complete information of the deployment

kubectl describe deploy/whats-app 
kubectl describe deployment whats-app

To Create the deployment directly with the command

kubectl create deploy name of deployment  --image=image name and tag
kubectl create deploy deployment-1-nginx --image=nginx:1.13.1

To Change the pod image directly using the command

kubectl set image deploymentt nginx-deployment nginx=nginx:1.14.1

Giving a message for the revision in the output (change-cause). use

Get Praveen Kumar’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

— — record=true. It will save entire command in the change-cause message

kubectl set image deploymentt nginx-deployment nginx=nginx:1.15.1 --record=true

whenever you change the image of the pod or if you changed the pod specifications of the pod in yaml file. Deployment will create a new revision.

To know the all the rollout history of deployment.

kubectl rollout history deployment/deployment-name
kubectl rollout history deploy/whats-app

To check the details fo specific revision. for example 3rd version

kubectl rollout history deployment/whats-app --revision=3

To revert back to the previous version of the application

kubectl rollout undo deployment whats-app

To rollback to specific version of the revision

kubectl rollout undo deployment whats-app --to-revision=1

To scale up/down the number of replicas count in the deployment

kubectl scale --replicas=5 deploy whats-app

To know the rollout status of the deployment

kubectl rollout status deployment whats-app

To edit the deployment

kubectl edit deployment whats-app
kubectl edit deploy/whats-app

Lets take other example of deployment

kind: Deployment
apiVersion: apps/v1
metadata:
   name: whats-app
spec:
   replicas: 2
   selector:     
    matchLabels:
     name: whats-app1
   minReadySeconds: 10
   strategy:
     rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
   template:
     metadata:
       name: testpod
       labels:
         name: whats-app1
     spec:
      containers:
        - name: c00
          image: ubuntu
          command: ["/bin/bash", "-c", "while true; do echo whats-app is running; sleep 5; done"]

Added peroperties in the manifest.

minReadySeconds: It will wait for the old pod to delete after the successful running of the new pod.

strategy: Allow Deployment’s update to take place with zero downtime by incrementally updating Pods instances with new ones.

maxSurge: it will define, how many number of pods it can create beyond the replicas count at the time of rollinig upgrading.

maxUnavailable: it is optional field. the number of pods from that set that can be unavailable after the eviction. If this value mentioned as 1 in the yaml file then replica set will always keeps 2 pods all the time.

The above mentioned properties will define how to we can upgrade the pods.

Let’s imagine if we apply the above manifest file. What happens behind the scenes is. It will create a new replica set first then it will create a new pod with new image specifications. Now there will be 4 copies of pods running because maxSurge is 1. After the successful creation of a new pod. Deployment will wait for 10 sec (minReadySeconds) to delete the old pod. This process will be continued till the rest of the pods are created successfully. In this way the new replica set will be created.

Kubernetes Deployment Status and Lifecycle

A Kubernetes Deployment object has the following lifecycle stages:

Progressing — this means the Deployment is currently making changes to the cluster to meet the desired state in the declarative configuration.

Completed — this means the deployment has finished matching cluster state to the desired state. All required pods are available and running the latest pods specification, and old pods are no longer running.

Failed — this means that the deployment encountered a problem while trying to reconcile cluster state with desired state. For example, there may have been insufficient resources or errors when running pods. To understand the cause of a failed deployment, use the command kubectl rollout status.

Thanks for reading the blog. See you in next blog.

DO FOLLOW ME ON INSTAGRAM

https://www.instagram.com/learn_with_praveen/

— — — — — — — — — — — — — — — Praveen Writings