Deployments

Creare deployment

Un deployment ne dă opțiunea declarativă de a updata pod-uri și ReplicaSets. Într-un deployment descriem starea dorită, apoi un Deployment Controller are grijă ca clusterul să ajungă în starea descrisă. Putem folosi deployment-uri pentru a crea noi ReplicaSets sau chiar pentru a șterge un deployment existent și a adopta toate resursele sale.

Exemplu de deployment (varianta declarativă):

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

Task

• Creați deployment-ul definit în fișierul de mai sus, știm deja cum să folosim comanda apply.
• Verificați câte noduri există: kubectl get pods.
• Verificați câte ReplicaSets există: kubectl get rs # am folosit un shortcut aici
• Verificați că deployment-ul este up and running: kubectl get deploy

Upgrade deployment

Un deployment poate fi modificat prin upgrade. Un use-case relevant este unul des întâlnit în ziua de azi, presupunem că a apărut o nouă versiune a aplicației și vrem să folosim versiunea curentă.

În cazul deployment-ului nostru, vrem să folosim o nouă versiune a webserver-ului aplicației noastre, deci vrem să folosim o versiune mai nouă a nginx.

Tasks

• Creați un nou fișier plecând de la fișierul creat anterior. Schimbați imaginea folosită în nginx:1.21.1.
• Aplicați modificările făcute: kubectl apply -f mynewdep.yaml
• Listați pod-urile din cluster. Ce se întâmplă?

În primul rând, un aspect foarte important este că pod-urile sunt upgraded secvențial, nu toate odată, după ce un număr de noi pod-uri au fost create, urmează să se șteargă cele vechi, procedeul se repetă până când toate pod-urile au fost updated.

sugestie

Așa cum puteți observa, numele unui pod are următoarea structură: numeDeployment-identificatorReplicaSet-identificatorPod

Task

Listați toate obiectele de tip ReplicaSet din cluster: kubectl get rs # am folosit o prescurtare

Din câte puteți observa, avem două ReplicaSets care corespund aceluiași deployment. Motivul este pentru că în momentul în care am făcut upgrade deployment-ului, a fost creat un nou ReplicaSet cu nouă imagine de nginx folosită. Obiectul ReplicaSet vechi este și el păstrat pentru că există mereu o șansă să vrem să ne întoarcem la versiunea anterioară a aplicației.

Rollout deployment

Am realizat că avem o greșeală în deploymentul nostru, pentru a reveni la versiunea anterioară folosim următoarea comandă: kubectl rollout history deployment <depname>

Tasks

• Analizați din nou obiectele de ReplicaSet și Pod.
• Scalați deployment-ul la 2 replici: kubectl scale deployment <depname> –replicas=2
• Verificați numărul de pod-uri.
• Scalați din nou la 5 replici: kubectl scale deployment <depname> –replicas=5

Pentru a modifica imaginea folosită de un deployment, avem următoarea comandă: kubectl set image deployment <depname> nginx=nginx:failTest În comanda de mai sus am introdus intenționat o imagine care nu există. Dacă urmariți comportamentul deployment-ului, o să observați că noile pod-uri nu vor fi create deoarece nu poate fi gasită imaginea specificată.

Am ajuns în situația în care vrem să ne întoarcem la o versiunea anterioară. Pentru a vedea istoricul modificărilor făcute pe acest deployment, avem următoarea comandă: kubectl rollout history deployment <depname>

Observați ca avem mai multe "revizii" ale deployment-ului nostru. Pentru a ne întoarce la o anumită revizie, folosim următoarea comandă: kubectl rollout history deployment <depname> –revision=2

Dacă dorim să facem un restart deployment-ului nostru (de exemplu dacă facem update la variabile de mediu sau diferite configurați), putem folosi următoarea comandă: kubectl rollout restart <depname>