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.
- Kubernetes Beginners Tutorials
- How to Install and Deploy Kubernetes on Ubuntu 16.04
- How to Install and Deploy Kubernetes on CentOs 7
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:
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 metadata: name: first-deployment # The name of your deployment labels: app: nginx spec: replicas: 3 # The number of pods you want Selector: # this where you specify the pods to manage matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.1 # Image version ports: - 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
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:
- Rolling Update Deployment: The Deployment updates Pods in a rolling update fashion when
.spec.strategy.type=RollingUpdate. You can specify
maxSurgeto control the rolling update process:
We use it to specify the maximum number of Pods that can be unavailable during the update process.
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