Déploiements sereins : Argo Rollouts, votre filet de sécurité pour Kubernetes

Argo Rollouts est un puissant contrôleur Kubernetes accompagné d'un ensemble de CRDs qui enrichit les capacités de déploiement : blue-green, analyse canary, expérimentation et livraison progressive sur Kubernetes.

Argo Rollouts s'intègre aux ingress controllers et aux service meshes pour rediriger progressivement le trafic vers les nouvelles versions lors d'une mise à jour. Rollouts collecte et analyse également des métriques issues de divers fournisseurs afin de vérifier les KPI clés et de promouvoir ou annuler la mise à jour de manière automatique.

À l'image de l'objet deployment, le contrôleur Argo Rollouts gère la création, la mise à l'échelle et la suppression des ReplicaSets. Ces ReplicaSets sont définis par le champ spec.template au sein de la ressource Rollout, qui utilise le même pod template que l'objet deployment. Argo Rollouts ne prend pas en charge les StatefulSet ni les DaemonSet.

Toute modification de spec.template signale au contrôleur Argo Rollouts qu'un nouveau ReplicaSet va être introduit. Le contrôleur s'appuie alors sur la stratégie définie dans le champ spec.strategy pour déterminer comment le rollout passera de l'ancien au nouveau ReplicaSet. Une fois ce nouveau ReplicaSet mis à l'échelle (et, le cas échéant, validé par une Analysis), le contrôleur le marque comme stable.

Vous pouvez également utiliser spec.WorkoadRef pour gérer des deployments existants dans Argo Rollouts sans supprimer la configuration en place.

Prérequis

• Cluster Kubernetes opérationnel avec kubectl installé et configuré.
• Installer le plugin kubectl Argo Rollouts sur votre machine.

Installer Argo Rollouts

• Exécutez les commandes ci-dessous pour installer Argo Rollouts dans le cluster. Reportez-vous à la documentation officielle pour plus d'options.

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

Stratégie de déploiement Blue-Green

Un déploiement blue-green consiste à exécuter en parallèle deux environnements identiques. Le bleu correspond à l'environnement de production actuel, tandis que le vert héberge la nouvelle version de l'application à déployer. Pendant cette phase, seule l'ancienne version reçoit le trafic de production. Cette approche permet aux développeurs de tester la nouvelle version avant de basculer le trafic en direct vers le nouvel environnement.

représentation visuelle d'un déploiement blue-green

Voyons comment utiliser Argo Rollouts pour la stratégie Blue-Green à partir d'un déploiement simple.

• Déployez un exemple d'application nginx dans le cluster avec la commande ci-dessous, qui jouera le rôle d'environnement bleu.

kubectl create deployment nginx --image nginx:1.19.10 --replicas 2

Pods de l'application d'exemple

• Créez deux services Kubernetes pour le deployment. L'un pour l'environnement actuel (bleu), l'autre pour le nouvel environnement (vert).

kubectl expose deployment nginx --name nginx-active --port 80 --target-port 80
kubectl expose deployment nginx --name nginx-preview --port 80 --target-port 80

Service d'exemple et endpoints

• Créez une ressource Argo Rollout avec la configuration nécessaire pour la stratégie Blue-Green. Reportez-vous à la documentation officielle pour l'ensemble des options.

cat <<EOF | kubectl apply -f -
---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: nginx
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  strategy:
    blueGreen: #Indicates that the rollout should use the Blue-Green strategy
      activeService: nginx-active # Reference to service that the rollout modifies as the active service.
      previewService: nginx-preview # Name of the service that the rollout modifies as the preview service.
      previewReplicaCount: 1 #The number of replicas to run under the preview service before the switchover.
      # Indicates if the rollout should automatically promote the new ReplicaSet
      # to the active service or enter a paused state. If not specified, the
      # default value is true. +optional
      autoPromotionEnabled: false
  # WorkloadRef holds a references to a workload that provides Pod template
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
EOF

• Vérifiez le nouveau replicaset et la configuration Argo Rollout comme indiqué ci-dessous.

Statut des Pods, ReplicaSets et Argo Rollout

• Les pods gérés par le replicaset initial ne sont pas supprimés automatiquement. Il est recommandé de réduire manuellement les replicas du deployment à 0, puisque l'Argo Rollout en assume désormais la gestion. Exécutez la commande ci-dessous pour mettre à zéro les pods non gérés.

kubectl scale deployment nginx --replicas 0

• Passons la version de l'image à latest, ce qui déclenchera une nouvelle révision.

kubectl set image deployment/nginx nginx=nginx:latest

Statut du déploiement Blue-Green avant promotion

• L'environnement vert est désormais prêt et vous pouvez utiliser le service nginx-preview pour tester les changements sans impacter le trafic de production servi par le service nginx-active.
• Vous pouvez également utiliser le dashboard Argo Rollouts pour suivre l'état du rollout. Exécutez la commande ci-dessous pour y accéder.

kubectl argo rollouts dashboard -n default

Statut du rollout dans le dashboard Argo Rollouts

• Promouvez la nouvelle version en production avec la commande ci-dessous.

kubectl argo  rollouts promote nginx

Statut du déploiement Blue-Green après promotion

Un déploiement canary est un déploiement progressif d'une application qui répartit le trafic entre une version déjà déployée et une nouvelle version, en exposant cette dernière à un sous-ensemble d'utilisateurs avant un déploiement complet.

Les ingress controllers et service meshes, comme NGINX et Istio, permettent un traffic shaping plus avancé pour le canarying : répartition fine du trafic ou découpage basé sur les en-têtes HTTP.

représentation visuelle d'un déploiement canary

Voyons comment utiliser Argo Rollouts pour le déploiement Canary.

• Déployez un exemple d'application dans le cluster.

kubectl create deployment nginx-canary --image nginx:1.19.10 --replicas 5

• Créez un service Kubernetes pour le deployment. Contrairement au déploiement Blue-Green, le canary ne nécessite pas deux services Kubernetes distincts pour un même deployment, car les nouveaux endpoints de pods sont ajoutés au service Kubernetes en fonction du pourcentage Canary.

kubectl expose deployment nginx-canary --port 80 --target-port 80

Pods et service de l'application d'exemple

• Créez une ressource Argo Rollout pour la stratégie canary. Reportez-vous à la documentation officielle pour l'ensemble des options.

cat <<EOF | kubectl apply -f -
---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: nginx-canary
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx-canary
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-canary
  strategy:
    canary: #Indicates that the rollout should use the Canary strategy
      maxSurge: "25%"
      maxUnavailable: 0
      steps:
      - setWeight: 10
      - pause:
          duration: 1h #Pause for 1 hour and wait promote to next canary stage
      - setWeight: 30
      - pause: {} # pause indefinitely and requires manual promote action
      - setWeight: 100
      - pause: {} # pause indefinitely and requires manual promote action
EOF

Statut des Pods, du replicaset et de l'Argo Rollout

• Comme pour le déploiement blue-green, il faut réduire à zéro les replicas du deployment actuel afin que l'Argo Rollout puisse gérer l'ensemble des nouveaux pods rattachés au nouveau replicaset.

kubectl scale deployment nginx-canary --replicas 0

• Déployons une nouvelle version de l'application et observons le déploiement canary.

kubectl set image deployment/nginx-canary nginx=nginx:latest

Statut initial (10 %) du déploiement canary

Statut du rollout Canary dans le dashboard Argo

• Promouvez manuellement le rollout vers les étapes canary suivantes.

kubectl argo rollouts promote nginx-canary

Statut du rollout Canary à 30 %

Statut du rollout Canary dans le dashboard Argo

Statut du rollout Canary à 100 %

Statut du rollout Canary dans le dashboard Argo

Argo Rollouts propose une fonctionnalité d'analysis qui permet de définir et d'exécuter divers contrôles et tests sur votre application pendant ou après les déploiements, afin de valider la stabilité et les performances de la nouvelle version avant de la basculer sur l'intégralité du trafic de production.