Deployment types in Kubernetes
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
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 thenginx: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
fromnginx:1.14.2
tonginx: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...
or
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 :
- 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 ofnginx: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 andnginx-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 !!
If this post was helpful, please click the clap 👏 button below a few times to show your support! ⬇