
Deployments in Kubernetes

Let's forget about kubernetes and containers for sometime and imagine a normal scenario where any application is running in an environment, for obvious reasons we will want to have multiple instances of the applications running. Now, a newer version of application came in and application needs to be upgraded. Here we will want that application upgrade should happen on one instance at a time so that the users are not impacted.
This kind of upgrade is called Rolling updates.

Another thing is if in case one of the instance that were being updated went to an error state. now we would surely like to rollback the update and bring it back to the last stable state.
Let's say there are number of steps involved in an update and we would like to pause the environment so that after all steps are executed , all changes are deployed at once together.
The YAML syntax for deployment is very much same as that of a replica set except for a kind which is deployment here.
Example
In the below example we will create an nginx deployment running three replicas.
[root@node1 kubernetes]# cat nginx_deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
[root@node1 kubernetes]# kubectl create -f nginx_deployment.yaml
deployment.apps/nginx-deployment created
[root@node1 kubernetes]# kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 0/3 3 0 13s
Updating a deployment
Let's update the nginx Pods to use the nginx:1.16.1 image instead of the nginx:1.14.2 image.
[root@node1 kubernetes]# kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record
deployment.apps/nginx-deployment image updated
[root@node1 kubernetes]# kubectl rollout status deployment.v1.apps/nginx-deployment
Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...
deployment "nginx-deployment" successfully rolled out
Check roll out history of a deployment
[root@node1 kubernetes]# kubectl rollout history deployment.v1.apps/nginx-deployment
deployment.apps/nginx-deployment
REVISION CHANGE-CAUSE
1 <none>
2 kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record=true
Rolling back to a previous version
[root@node1 kubernetes]# kubectl rollout undo deployment.v1.apps/nginx-deployment
deployment.apps/nginx-deployment rolled back
[root@node1 kubernetes]# kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 12m
[root@node1 kubernetes]# kubectl describe deployment nginx-deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Tue, 16 Jun 2020 16:56:53 +0530
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision: 3
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.14.2
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-6b474476c4 (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 6m43s deployment-controller Scaled up replica set nginx-deployment-7b45d69949 to 1
Normal ScalingReplicaSet 5m58s deployment-controller Scaled down replica set nginx-deployment-6b474476c4 to 2
Normal ScalingReplicaSet 5m58s deployment-controller Scaled up replica set nginx-deployment-7b45d69949 to 2
Normal ScalingReplicaSet 5m20s deployment-controller Scaled down replica set nginx-deployment-6b474476c4 to 1
Normal ScalingReplicaSet 5m20s deployment-controller Scaled up replica set nginx-deployment-7b45d69949 to 3
Normal ScalingReplicaSet 5m18s deployment-controller Scaled down replica set nginx-deployment-6b474476c4 to 0
Normal ScalingReplicaSet 52s deployment-controller Scaled up replica set nginx-deployment-6b474476c4 to 1
Normal ScalingReplicaSet 50s deployment-controller Scaled down replica set nginx-deployment-7b45d69949 to 2
Normal ScalingReplicaSet 47s (x2 over 12m) deployment-controller Scaled up replica set nginx-deployment-6b474476c4 to 3
Normal ScalingReplicaSet 46s (x3 over 50s) deployment-controller (combined from similar events): Scaled down replica set nginx-deployment-7b45d69949 to 0
Scaling up/down a deployment
This is helpful when we want to increase/decrease the number of replicas.
[root@node1 kubernetes]# kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 14m
[root@node1 kubernetes]# kubectl scale deployment.v1.apps/nginx-deployment --replicas=5
deployment.apps/nginx-deployment scaled
[root@node1 kubernetes]# kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 5/5 5 5 14m
[root@node1 kubernetes]# kubectl scale deployment.v1.apps/nginx-deployment --replicas=2
deployment.apps/nginx-deployment scaled
[root@node1 kubernetes]# kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 2/2 2 2 15m
Canary deployments
If we desire that a newer version of the application should be made available to a certain set of people , we can do a canary deployment where pods of both application versions will co exist.
Blue-Green Deployments

A blue/green deployment is a change management strategy for releasing software code. Blue/green deployments, which may also be referred to as A/B deployments require two identical hardware environments that are configured exactly the same way. While one environment is active and serving end users, the other environment remains idle.
Hope you are enjoying the articles. Much more stuff coming up.
Humble Request :-)
If you liked the article then please like our Facebook page and follow us on LinkedIn.
Links are given below.