Scribd
Upload
25 views2 pages

Day 16 Deployment

The document discusses deployment and migration of pods in Kubernetes. It explains how deployments support rolling updates and rollbacks, unlike replicasets. It provides an example of creating a deployment and then progressively migrating the nginx image version through multiple rolling updates. It also shows how to view the revision history and rollback a deployment.

Uploaded by

chaudheryaws
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
25 views2 pages

Day 16 Deployment

The document discusses deployment and migration of pods in Kubernetes. It explains how deployments support rolling updates and rollbacks, unlike replicasets. It provides an example of creating a deployment and then progressively migrating the nginx image version through multiple rolling updates. It also shows how to view the revision history and rollback a deployment.

Uploaded by

chaudheryaws
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 2

------------------------------------

Deployment --> Rolling upding + Roll back (prod)

Networking --> we will create network service

-------------------------------------

Migration of Pods :
- Its an API-resource of k8s likewise pod, rs
- Deployment ---> it supports rolling update and rollback which not allowed
in replicaset.
- To avoid manually migration of s/w version in deployment.
- Replica Set is the base of Deployment resource.
- Its namespace oriented resource of k8s

Deployment = RC / RS + Rolling update + Roll back

-----------------------
vi deploy-test.yaml
-----------------------
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp2
namespace: cdts
spec:
replicas: 10
selector:
matchLabels:
app: nginx
env: prod
template:
metadata:
labels:
app: nginx
env: prod
spec:
containers:
- name: c1
image: nginx:1.14
ports:
- containerPort: 80
--------------------------------

kubectl create -f deploy-test.yaml

kubectl get all -n cdts

Now test for migration of app (Rolling update)

nginx:1.14 ---> nginx:1.5 ----> nginx:1.16 --> nginx:1.20 --->


nginx:1.21

Tip: login to any pod and test with followin command:


Ex: nginx -v
-----------------------------------------------------------------
Now test migrate nginx 1.14 to 1.15 and so on....
kubectl set image deployment myapp2 c1=nginx:1.15 -n cdts --record

kubectl set image deployment myapp2 c1=nginx:1.16 -n cdts --record

kubectl set image deployment myapp2 c1=nginx:1.17 -n cdts --record

kubectl set image deployment myapp2 c1=nginx:1.20 -n cdts --record

kubectl set image deployment myapp2 c1=nginx:1.21 -n cdts --record

------------------------------------------------------------------------------
We can check revision hisotry of rolling update ( migration / rollback )
------------------------------------------------------------------------------
kubectl rollout history deployment myapp2 -n cdts

kubectl rollout undo deployment myapp2 -n cdts --to-revision=4

-----------------------------------------------------------------------
We can change surge value which help to create pods without minimal downtime , we
can follow this

kubectl edit deploy myapp2 -n cdts

We need to change as per below : ( deploy edit will open in vi editor so save
properly )

strategy:
rollingUpdate:
maxSurge: 25% ---> 50%
maxUnavailable: 25% --> 50%

-------------------------------------------------------

When we deploy next time it will create new pods as per updated surge value.

--------------------------------------------------------

You might also like