All you need to know about Kubernetes Deployment

kubernetes deployment
kubernetes deployment

Till this moment we discussed what is a Pod, it’s life cycle and what is a ReplicaSet and we understand that both don’t give us nearly enough functionality to build robust applications and services that can communicate with one another. That’s why today we are going to talk about the Kubernetes Deployment which have a lot of benefits over a Pod or a ReplicaSet, so to start with this article you should have a  ready Kubernetes cluster with a basic knowledge about the concepts.

Useful links:

First of all we need to understand what is a Kubernetes deployment.

What is a Kubernetes Deployment

The Deployment is another controller concept used to build a Pod or a ReplicaSet and actually it’s the recommended way to do that because it comes with a rich features and it gives you more control over your cluster, below are the typical uses cases of a deployment:

  • It can be used to create Replica Set and Pods.
  • Find out the status of a ReplicaSet by checking the Deployment status.
  • You can update the Deployment to create new pods.
  • Rollback to an older Deployment revision in the case of any problem.
  • Pause and resume a Deployment.
  • Remove an older ReplicaSet if you don’t need it.

Also we should mention that the deployment have 3 stages on its life cycle which are:

  • Progressing
  • Complete
  • Failed

Example of a Kubernetes Deployment

Like any other Kubernetes object, you have to provide the metadata, and a specification in which you describe the desired state of this object, then Kubernetes tries very hard to make this desired state happen, reports on its progress under the status key of the object, this is an example of a YAML deployment file where we are going to create a simple deployment of nginx with 3 replicas:

apiVersion: apps/v1
kind: Deployment
  name: first-deployment # The name of your deployment
    app: nginx
  replicas: 3      # The number of pods you want
  Selector:        # this where you specify the pods to manage
      app: nginx
        app: nginx
      - name: nginx  
        image: nginx:1.7.1     # Image version
        - containerPort: 80

Let’s call this file first-deployment.yaml and use the following command:

kubectl create -f first-deployment.yaml
deployment.apps "first-deployment" created

How we can handle a Deployment?

First to see if the deployment was successfully created, you can run this command:

kubectl rollout status deployment first-deployment
deployment "first-deployment" successfully rolled out

If you want to see how many replicas are running, you can use this command:

kubectl get deployment
NAME                               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
first-deployment                 3         3         3            3           2m


  • There is a special argument that you should be aware of, it is called “–record” . You append this argument to kubectl and it records the command you going to run on the revisions history. this argument takes “true” or “false”.
  • If you made an update on the Deployment pod template which is  “spec.template”,a rollout is triggered and your pods will go down and new other pods will be created depending on the changes you made.

How Deployment handles rollouts?

Let’s go for an example:

Here we want to move nginx version to the latest, we will use this command to set the image and it’s the same as making modifications on the yaml file:

kubectl set image deployment  first-deployment nginx=nginx:latest --record=true
deployment.apps "first-deployment" image updated

In this case which is the case of a rollout, the Deployment will make sure that 25% of your pods are unavailable. This is great to make sure that all our nginx pods are not scaled down at the same time. It also makes sure that it does not create more that 25 percent of the desired number or replicas we specified while performing the rollout. 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. This is referred to as “Rolling Update Strategy”. Another key benefit of using deployment.

What if we want to rollback the changes?

Sometimes you run a command with a wrong version number by mistake or you migrate to a version that causes failures on your app and you want to rollback the changes you made.

To do that, simply you should run the rollout history command to get the revision number you want to go back to:

kubectl rollout history deployment first-deployment

And you will get the revision numbers of the commands executed before.

For example we want to rollout to the revision number “1”, we simply use the command below first to show more information about the revision we want:

kubectl rollout history deployment first-deployment --revision=1

Then we rollout to it by using the following command:

kubectl rollout undo  deployment first-deployment --to-revision=1

You can use the status command after to make sure that all is successfully rolled out.

How to update the number of Replicas we want?

To do that we have to use the kubectl scale command with the argument “–replicas” with assigning the number we want to it:

kubectl scale --replicas=4 deployment first-deployment

How to pause and resume our deployment?

Nothing is complicated, to pause our deployment we simply use the kubectl rollout pause command:

kubectl rollout pause deploy first-deployment

To resume it we just change pause by resume:

kubectl rollout resume deploy first-deployment


If any updates are made when the deployment is paused, no rollout will happens until you resume it.

One last thing that i should mention which is the

Deployment strategies

which are used to set the way we want to replace old Pods by new ones and we can use this by setting “spec.strategy.type” on the yaml file and it and it can take one of those 2 kinds:

  • Recreate : All existing Pods are killed before new ones are created: spec.strategy.type=Recreate.
  • Rolling Update Deployment: The Deployment updates Pods in a rolling update fashion when .spec.strategy.type=RollingUpdate. You can specify maxUnavailable and maxSurge to control the rolling update process:
Max Unavailable:

We use it to specify the maximum number of Pods that can be unavailable during the update process.

Max Surge:

We use it to specify the maximum number of Pods that can be created over the desired number of Pods.


It’s the end of this article, i hope that everything is clear for you and if not please do not hesitate to comment or message me your questions to discuss on my next articles!

See you guys



Please enter your comment!
Please enter your name here