Gestione di Deployment e Rollout

Un Deployment, specificato da un manifest in Yaml, gestisce Pods e ReplicaSets in modo flessibile, ottenendo lo stato desiderato a partire dallo stato corrente.

NOTA: Non gestire manualmente i ReplicaSet che appartengono ad un Deployment.

Generazione di Deployment

Esempio. Un Deployment di nginx che gestisce un RepkicaSet con 3 pod.

vim ~/scripts/nginx-depl.yml

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

Creare il deployment:

kubectl apply -f ~/scripts/nginx-depl.yml

Visualizzare il deploymant:

kubectl get deployments

Ogni deploymant è un rollout. Visualizzarne lo status:

kubectl rollout status deployment/nginx-deployment

Visualizzare il replicaset:

kubectl get rs

Visualizzare i pod e le loro etichette:

kubectl get pods --show-labels

Ogni pod acquisisce automaticamente l'etichetta pod-template-hash, che lo collega al ReplicaSet.

Update di Deployment

Cambiare la versione di nginx usata:

kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1

Si può naturalmente modificare il file di specifiche ~/scripts/nginx-depl.yml e risottometterlo.

Si può inoltre editare direttamente con:

kubectl edit deployment/nginx-deployment

Verificare lo stato del rollout:

kubectl rollout status deployment/nginx-deployment

Solo un certo numero di pod sono disattivati durante il rollout. Default 25% - parametro maxUnavailable.

Solo un certo numero di pod nuovi sono creati durante il rollout. Default 25% - parametro maxSurge.

I dettagli sul deployment si ottengono con:

kubectl describe deployments

Ogni rollout che cambia i pod crea una revisione. La revisione non viene creata quando si cambia il numero di pod con un'operazione di scale.

Rollback di un Deployment

Utile quando la nuova versione è in un loop di crash.

Per esempio un update con un errore tipografico:

kubectl set image deployment/nginx-deployment nginx=nginx:1.161

Il sintomo di fallimento è l'output del comando:

kubectl rollout status deployment/nginx-deployment

che rimane piantato a lungo.

Altri sintomi si deducono dai comandi:

kubectl get rs
kubectl get pods
kubectl describe deployment

La storia delle revisioni si ottiene con:

kubectl rollout history deployment/nginx-deployment

Per avere dettagli di una specifica revisione:

kubectl rollout history deployment/nginx-deployment --revision=2

Per compiere il rollback alla revisione precedente:

kubectl rollout undo deployment/nginx-deployment

Per compiere il rollback ad una revisione specifica:

kubectl rollout undo deployment/nginx-deployment --to-revision=2

Controllare il risultato con:

kubectl get deployment nginx-deployment

e con:

kubectl describe deployment nginx-deployment

Scalare un Deployment

Oltre che modificare il manifest, ~/scripts/nginx-depl.yml, e risottometterlo, si può modificare il Deployment col comando diretto:

kubectl scale deployment/nginx-deployment --replicas=10

Se è presente uno autoscaler, si può anche dare il comando:

kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80

Questo introduce in Kubernetes un oggetto HPA - Horizontal Pod Autoscaler. Questo avviene anche se lo autoscaler non è abilitato.

Si possono vedere gli oggetti HPA con:

kubectl get hpa
kubectl get hpa -w

L'oggetto si cancella con:

kubectl delete hpa nginx-deployment

Il cluster Kind non fornisce un autoscaler. Minikube si.

Terminare l'Esercizio

kubectl delete -f ~/scripts/nginx-depl.yml