Kubernetes/Deployment, ReplicaSet and Pod

From Ever changing code
< Kubernetes
Revision as of 09:06, 23 July 2019 by Pio2pio (talk | contribs) (Created page with "''Deployment'' kind provides all required application life-cycle for your applications. Example YAML below: <source lang=yaml> apiVersion: apps/v1 kind: Deployment metadata:...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Deployment kind provides all required application life-cycle for your applications. Example YAML below:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubeapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: kubeapp
  template:
    metadata:
      name: kubeapp
      labels:
        app: kubeapp
    spec:
      containers:
      - image: nginx:1.16.0
        name: app


Create a deployment with a record (for rollbacks). Deployment appends a string of numbers to the end of the name, that is a hash of Pod template and the deployment. Deployment creates a ReplicaSet, that manages a number of Pods.

kubectl create -f kubeapp-deployment.yaml --record #records in a revision history, so it's easy to rollback
kubectl rollout status deployments kubeapp #Check the status of the rollout
deployment "kubeapp" successfully rolled out

kubectl get replicasets #name is <deploymentName> with appended <PodTemplateHash>
NAME                            DESIRED   CURRENT   READY   AGE
kubeapp-674dd4d9cd              3         3         3       93s

kubectl get pods        #name is <ReplicaSetName> with appended <generated-podID>
NAME                       READY   STATUS    RESTARTS   AGE
kubeapp-674dd4d9cd-f2rk8   1/1     Running   0          3m36s
kubeapp-674dd4d9cd-gnq7v   1/1     Running   0          5m51s
kubeapp-674dd4d9cd-kc6lt   1/1     Running   0          3m37s

Scale up your deployment by adding more replicas:

kubectl scale deployment kubeapp --replicas=5
kubectl get pods #notice ReplicaSet has different hash than Pods, as it's different object
NAME                       READY   STATUS    RESTARTS   AGE
kubeapp-674dd4d9cd-f2rk8   1/1     Running   0          3m36s
kubeapp-674dd4d9cd-gnq7v   1/1     Running   0          5m51s
kubeapp-674dd4d9cd-kc6lt   1/1     Running   0          3m37s
kubeapp-674dd4d9cd-n5wnp   1/1     Running   0          5m51s
kubeapp-674dd4d9cd-ptt26   1/1     Running   0          3m36s

#Expose the deployment and provide it a service
kubectl expose deployment kubeapp --port 80 --target-port 80 --type NodePort 
service/kubeapp exposed

kubectl get service
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubeapp      NodePort    10.111.72.150   <none>        80:31472/TCP   11m
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP        18d

#Set the minReadySeconds attribute to your deployment, slows down deployment, so can see changes in realtime
kubectl patch deployment kubeapp -p '{"spec": {"minReadySeconds": 10}}'
kubectl edit deployments.apps kubeapp #see the change above

#Use kubectl apply to update a deployment. It modifies an existing object to align to the new YAML, or creates if does not exists
kubectl describe deployments.apps kubeapp | grep Image #Before
    Image:        nginx:1.16.0
kubectl apply -f kubeapp-deployment.yaml #update the deployment file image from - image: nginx:1.16.0 -> 1.17.1
kubectl describe deployments.apps kubeapp | grep Image #After
    Image:        nginx:1.17.1

#Use kubectl replace to replace an existing deployment. It updates existing object, the object must exist before hand
kubectl replace -f kubeapp-deployment.yaml


Rolling update to prevent application downtime

#Run this curl look while the update happens:
while true; do curl http://<NodeIP>; done

#Perform the rolling update:
kubectl set image deployments/kubeapp app=nginx:1.17.1 --v 6 #--v verbose output

#Find that new ReplicaSet has been created
kubectl describe replicasets kubeapp-[hash]

kubectl get replicasets
NAME                 DESIRED   CURRENT   READY   AGE
kubeapp-674dd4d9cd   0         0         0       43m
kubeapp-99c897449    0         0         0       6m19s
kubeapp-d79844ffd    3         3         3       14m   #new deployment

#Look at the rollout history
kubectl rollout history deployment kubeapp
deployment.extensions/kubeapp 
REVISION  CHANGE-CAUSE
3         kubectl create --filename=kubeapp-deployment.yaml --record=true
4         <none>  #this is empty because no --record was set during kubectl execution
5         kubectl create --filename=kubeapp-deployment.yaml --record=true


Undo the rollout and roll back to the previous version. This is possible because deployment keeps a revision-history. The history is stored with underlying RelicaSet.

kubectl rollout undo deployment kubeapp --to-revision=2 #specific version if needed
kubectl rollout undo deployments kubeapp                #this has been applied

kubectl get replicasets
NAME                 DESIRED   CURRENT   READY   AGE
kubeapp-674dd4d9cd   0         0         0       46m
kubeapp-99c897449    3         3         3       8m52s  #rolled back to previous replicaset
kubeapp-d79844ffd    0         0         0       16m

#Pause the rollout in the middle of a rolling update (canary release)
kubectl rollout pause deployment kubeapp

#Resume the rollout after the rolling update looks good
kubectl rollout resume deployment kubeapp