Deployment types in Kubernetes

Kubernetes Advocate

Published in

AVM Consulting Blog

7 min readJun 5, 2020

It’s what you use to scale, roll out, and roll back versions of your applications.

In a deployment we will tell K8s how many replicas of the pod we want to run in our cluster, Deployment looks after it

source Thanks to (https://matthewpalmer.net//)

What is Deployment?

A deployment is an object in Kubernetes that helps you to manage a group of identical pods.

Without a deployment, you’d got to produce, update, and delete a bunch of pods manually.

With a deployment, we tend to declare one object in a very YAML file.

Using Kubernetes deployment we can autoscale the applications very easily.

YAML reference example

Here’s some YAML that you simply will use as a template for making your deployments.
First, take a glance at the animation that annotates every section of the readying YAML. (Scroll down for code which will be copy-and-pasted.)

(You will ignore the extra comments regarding the “service” here — this readying was taken from a distinct example that conjointly incorporated services.)
First, the replicas key sets the number of instances of the pod that the readying ought to keep alive.
In this case, the deployments can produce pods that run Nginx-hostname and with the designed labels.

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: nginx-deployment
spec:
  # A deployment's specification really only 
  # has a few useful options
  
  # 1. How many copies of each pod do we want?
  replicas: 3# 2. How do want to update the pods?
  strategy: Recreate# 3. Which pods are managed by this deployment?
  selector:
    # This must match the labels we set on the pod!
    matchLabels:
      deploy: example
  
  # This template field is a regular pod configuration 
  # nested inside the deployment spec
  template:
    metadata:
      # Set labels on the pod.
      # This is used in the deployment selector.
      labels:
        deploy: example
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9

Deployment vs service

What’s the distinction between a Deployment and a service?
A Deployment is employed to stay a collection of pods running by making pods from a model.
A service is employed to permit network access to a collection of pods.

Both services and deployments will choose which pods they operate on using labels and label selectors. This is where the overlap is.

You can use deployments independent of services. You can use services independent of deployments. They just go together really nicely!

How to delete a deployment in Kubernetes

We can use kubectl delete -f deployment.yaml to delete your deployment
From the command line, you can use kubectl delete deployment my-deployment to delete your deployment.

Use Case

The following are typical use cases for Deployments in a Kubernetes cluster are :

We can create a Deployment to rollout a ReplicaSet. The ReplicaSet creates Pods within the background. We can check the status of the current deployment rollout was completed or not.
Declare the new state of the Pods by changing the PodTemplateSpec of the deployment. A brand new ReplicaSet is made and also the Deployment manages to move the Pods from the previous ReplicaSet to the new one at a controlled rate.
Rollback to an earlier Deployment revision if the present state of the deployment isn’t stable. every rollback updates the revision of the deployment in the K8s cluster.
Scale up the Deployment to facilitate more load. we can scale up the deployment during hours where we see huge traffic and network in/outs
We can Pause the Deployment to update/apply fixes and bugs to its pod spec and then can start a new rollout for changes to reflect

Updating a Deployment

Follow the steps given below to update your Deployment:

Let’s update the Nginx Pods to use the nginx:1.16.1 image instead of the nginx:1.14.2 image.

kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1

2. use the following command :

kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record

3. The output will be like this:

deployment.apps/nginx-deployment image updated

Alternatively, you can edit the Deployment and change .spec.template.spec.containers[0].image from nginx:1.14.2 to nginx:1.16.1:

kubectl edit deployment.v1.apps/nginx-deployment

2. The output will be like this:

deployment.apps/nginx-deployment edited

To see the rollout status, run the command :

kubectl rollout status deployment.v1.apps/nginx-deployment

3. Output :

Waiting for rollout to finish: 2 out of 3 new replicas have been updated...

deployment.apps/nginx-deployment successfully rolled out

After the rollout succeeds well, you can view the Deployment by running kubectl get deployments. The output is similar to this:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE nginx-deployment   3/3     3            3           36s

Run kubectl get rs to see that the Deployment updated the Pods by creating a new ReplicaSet and scaling it up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.

kubectl get rs

output :

NAME                          DESIRED   CURRENT   READY   AGE nginx-deployment-7645263451   3         3         3       6s nginx-deployment-6537289365   0         0         0       36s

Running get pods should now show only the new Pods:

kubectl get pods

Output:

NAME                                READY     STATUS    RESTARTS   AGE 
14S nginx-deployment-7645263451-khsh9   1/1       Running   0          14s nginx-deployment-7645263451-mast2   1/1       Running   0          14s nginx-deployment-7645263451-saju2   1/1       Running   0

Next time you want to update these Pods, you only need to update the Deployment’s pod template again.
Deployment ensures that only a certain number of Pods are down while they are being updated. By default, it ensures that at least 75% of the desired number of Pods are up (25% max unavailable).
The deployment also ensures that only a certain number of Pods are created above the desired number of Pods. By default, it ensures that at most 125% of the desired number of Pods are up (25% max surge).
For example, if you look at the above Deployment closely, you will see that it first created a new Pod, then deleted some old Pods, and created new ones. It does not kill old Pods until a sufficient number of new Pods have come up and does not create new Pods until a sufficient number of old Pods have been killed. It makes sure that at least 2 Pods are available and that at max 4 Pods in total are available.
Get details of your Deployment:

kubectl describe deployments

output :

yaml

Here you see that once you initially created the preparation, it created a ReplicaSet (Nginx-deployment-7645263451) and scaled it up to three replicas directly. once you updated the preparation, it created a replacement ReplicaSet (Nginx-deployment-6537289365) and scaled it up to one so scaled-down the recent ReplicaSet to a pair of, so that a minimum of a pair of Pods was offered and at the most four Pods were created the least bit times. It then continuing scaling up and down the new and also the recent ReplicaSet, with constant rolling update strategy. Finally, you will have three offered replicas within the new ReplicaSet, and also the recent ReplicaSet is scaled right down to zero.

Rolling Back a Deployment

At times when the deployment is not stable or we see any bugs what were not supposed to be there, such as crash looping, So by default the rollout history is stored in the system so that we can rollback the version anytime we want to deploy

Let us suppose you made a typing mistake while you were updating the files of deployment by writing and saving the image name as nginx:1.161 instead of nginx:1.16.1:

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true

The output will be like this :

deployment.apps/nginx-deployment image updated

If the rollout stocks and you are not sure if it worked then you can verify the status

kubectl rollout status deployment.v1.apps/nginx-deployment

The output will be like this:

Waiting for rollout to finish: 1 out of 3 new replicas have been updated....

You see that the number of old replicas (nginx-deployment-7645263451 and nginx-deployment-6537289365) is 2, and new replicas (Nginx-deployment-2044567123) is 1.
kubectl get rs

kubectl get rs

The output will be like this:

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-7645263451   3         3         3       25s   nginx-deployment-6537289365   0         0         0       36s nginx-deployment-2044567123        1         1         0        6s

Looking at the Pods created, you see that 1 Pod created by new ReplicaSet is stuck in an image pull loop.

kubectl get pods

The output will be like this:

NAME                                READY     STATUS             RESTARTS   AGE nginx-deployment-7645263451-78sae   1/1       Running            0          25s nginx-deployment-7645263451-jgsho   1/1       Running            0          25s nginx-deployment-7645263451-hyhst   1/1       Running            0          25s nginx-deployment-2044567123-lksng   0/1       ImagePullBackOff   0          6s

Note: The Deployment controller stops the bad rollout automatically, and stops scaling up the new ReplicaSet. This depends on the rolling-update parameters (maxUnavailable specifically) that you have specified. Kubernetes by default sets the value to 25%.
Get the description of the Deployment:

kubectl describe deployment

The output will be like this:

To fix this, you need to rollback to a previous revision of Deployment that is stable.

👋 Join us today !!

️Follow us on LinkedIn, Twitter, Facebook, and Instagram

If this post was helpful, please click the clap 👏 button below a few times to show your support! ⬇