Mises à jour progressives et Rollbacks dans Kubernetes

L’un des avantages de l’utilisation d’un déploiement est la possibilité d’effectuer des mises à jour progressives et de créer une stratégie de mise à jour progressive. Les mises à jour progressives nous permettent de mettre à jour la configuration des pods progressivement.

Une stratégie de mise à jour (k8s rollingupdate, k8s update strategy) est l’option la plus importante à configurer pour les mises à jour progressives. Dans la définition du déploiement, spec.strategy.type a deux valeurs possibles :

• RollingUpdate : De nouveaux pods sont ajoutés progressivement et les anciens pods sont terminés progressivement.
• Recreate : Tous les anciens pods sont terminés en une seule fois avant que de nouveaux pods ne soient ajoutés.

Il y a 2 autres options lors de la mise à jour du déploiement en utilisant RollingUpdate.

• maxSurge : Le nombre de pods qui peuvent être créés au-dessus du nombre souhaité de pods pendant une mise à jour.
• maxUnavailable : Le nombre de pods qui peuvent être indisponibles pendant le processus de mise à jour.

En utilisant les mises à jour progressives de déploiement, nous pouvons mettre à niveau l’image utilisée par un déploiement. L’état du déploiement (kubectl rollout status) est sauvegardé, ce qui nous permet de revenir à n’importe quelle version précédente du déploiement.

Lorsqu’une application échoue en raison d’une image incorrecte ou que le déploiement est instable, nous pouvons vouloir revenir en arrière sur le déploiement (k8s rollback). Par défaut, tout l’historique de déploiement est conservé dans le système, ce qui peut être utilisé ultérieurement pour revenir en arrière en cas de déploiement instable. Nous pouvons utiliser cet historique pour revenir en arrière à tout moment.

Pour en savoir plus sur les mises à jour progressives et les rollbacks, consultez la documentation officielle de Kubernetes ici.

Dans cet article, nous allons mettre à jour le déploiement avec la stratégie de mise à jour progressive par défaut et revenir en arrière sur le déploiement. Pour revenir en arrière sur le déploiement, nous utiliserons l’image incorrecte dans l’une des mises à jour du déploiement.

Prérequis

1. Cluster Kubernetes avec au moins 1 nœud de travail.
   Si vous souhaitez apprendre à créer un cluster Kubernetes, cliquez ici. Ce guide vous aidera à créer un cluster Kubernetes avec 1 Master et 2 Nœuds sur des instances EC2 AWS Ubuntu 18.04.

Que allons-nous faire ?

1. Mise à jour progressive et rollback

Mise à jour progressive et Rollback

Créez un fichier de définition de déploiement pour Nginx avec le modèle de pod du déploiement. Dans ce fichier, nous avons spécifié la version de Nginx comme “nginx:1.14.2”.

vim my-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update-demo
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Vérifions les pods existants et créons un déploiement.

kubectl get pods

kubectl create -f my-deployment.yml

Obtenez les détails du déploiement que nous venons de créer. Ce déploiement a créé 4 pods et est contrôlé par le replicaset.

kubectl get deployments

kubectl get pods

kubectl get replicaset

Dans la capture d’écran ci-dessus, vous pouvez voir que nous avons 1 déploiement sous lequel nous avons 1 replicaset et 4 pods contrôlés par le replicaset.

Maintenant, changeons la version de Nginx de “nginx:1.14.2” à “nginx:1.61.1”

vim my-deployment.yml

Appliquez le changement au déploiement et obtenez les détails des pods, du replicaset et du déploiement.

kubectl apply -f my-deployment.yml

kubectl get pods

kubectl get deployments

kubectl get replicaset

Dans la capture d’écran ci-dessus, on peut voir qu’un nouveau replicaset a été créé et qu’il a 4 pods sous lui. Mais nous voyons toujours l’ancien replicaset avec 0 pods.

Maintenant, si nous changeons à nouveau la version de Nginx, mais cette fois nous donnons une mauvaise version de Nginx, le déploiement échouera car l’image Nginx n’existe pas pour la mauvaise version.

vim my-deployment.yml

Appliquons le changement au déploiement.

kubectl apply -f my-deployment.yml

kubectl get pods

kubectl get deployments

Maintenant, essayons d’obtenir les détails du replicaset.

kubectl get replicaset

Dans la capture d’écran ci-dessus, on peut voir que les nouveaux Pods échouent avec l’erreur “ErrImagePull”. Les pods échouent car l’image Nginx n’existe pas pour la version “ngin:1.1.1”.

Maintenant, si nous voulons revenir aux images de travail précédentes, nous pouvons revenir à une révision précédente si l’état de la mise à jour n’est pas correct.

Pour revenir en arrière, nous pouvons d’abord obtenir l’historique de mise à jour du déploiement en utilisant la commande suivante.

kubectl rollout history deployments rolling-update-demo

Maintenant, en utilisant la commande suivante avec “–revision=2”, nous pouvons vérifier les détails du déploiement que nous avons dans “–revision=2”

kubectl rollout history deployments rolling-update-demo --revision=2

Dans la capture d’écran ci-dessus, vous pouvez voir que la révision-2 a la version de l’image Nginx “nginx:1.16.1” qui fonctionnait avant que nous ne mettions à jour notre déploiement avec la version Nginx “ngin:1.1.1” qui a échoué.

Maintenant, revenons en arrière sur le déploiement à la dernière révision que nous avons avant le déploiement échoué actuel.

kubectl get deployments

kubectl rollout undo deployment rolling-update-demo

kubectl get pods

kubectl get replicaset

Dans la capture d’écran ci-dessus, vous pouvez voir que nous avons annulé le dernier déploiement et maintenant nous avons une révision de déploiement qui fonctionnait avant la dernière mise à jour.

Pour en savoir plus sur le déploiement, il peut être décrit en utilisant la commande suivante.

kubectl get deployments

kubectl describe deployment rolling-update-demo

Conclusion

Dans cet article, nous avons vu les étapes pour créer un déploiement et le mettre à jour. Nous avons vu comment un déploiement peut être annulé s’il échoue pour une raison quelconque, ici l’erreur que nous avons vue pour le déploiement échoué était “ErrImagePull”. Nous avons vu comment le déploiement conserve sa révision à laquelle il peut revenir en arrière au cas où nous ne voudrions pas conserver les dernières mises à jour dans le déploiement.