Stratégies de déploiement dans Kubernetes : rolling, recreate, blue/green, canary, dark (tests A/B)

Rem. trad.: Ce document de Weaveworks présente les stratégies de déploiement d'applications les plus populaires et décrit comment mettre en œuvre certaines des plus avancées à l'aide de l'opérateur Kubernetes Flagger. Il est rédigé dans un langage simple et comprend des schémas clairs, permettant même aux ingénieurs débutants de comprendre le sujet.

Le schéma est tiré de une autre revue des stratégies de déploiement présentée par Container Solutions

L'un des plus grands défis lors du développement d'applications cloud natives aujourd'hui est d'accélérer le déploiement. Avec une approche microservices, les développeurs travaillent déjà avec des applications entièrement modulaires et les conçoivent, permettant à différentes équipes d'écrire du code et d'apporter des modifications de manière simultanée.

Des déploiements plus courts et plus fréquents présentent les avantages suivants :

• Le temps de mise sur le marché est réduit.
• Les nouvelles fonctionnalités atteignent plus rapidement les utilisateurs.
• Les retours des utilisateurs parviennent plus vite à l'équipe de développeurs. Cela signifie que l'équipe peut ajouter des fonctionnalités et corriger des problèmes plus rapidement.
• Le moral des développeurs s'améliore : travailler avec un plus grand nombre de fonctionnalités en développement est plus intéressant.

Cependant, avec une fréquence de version accrue, les risques d'affecter négativement la fiabilité de l'application ou l'expérience utilisateur augmentent également. C'est pourquoi il est crucial pour les équipes d'exploitation et DevOps de structurer les processus et de gérer les stratégies de déploiement de manière à minimiser le risque pour le produit et les utilisateurs. (En savoir plus sur l'automatisation des pipelines CI/CD peut le faire) ici.)

Dans cette publication, nous discuterons des différentes stratégies de déploiement dans Kubernetes, y compris les déploiements rolling et des méthodes plus avancées telles que les déploiements canary et leurs variations.

Stratégies de déploiement

Il existe plusieurs types de stratégies de déploiement que vous pouvez utiliser en fonction de vos objectifs. Par exemple, vous pourriez avoir besoin d'apporter des modifications à un certain environnement pour un test approfondi, à un sous-ensemble d'utilisateurs/clients, ou d'effectuer un test limité sur des utilisateurs avant de rendre une fonctionnalité publique.

Rolling (déploiement progressif, 'graduel')

Il s'agit d'une stratégie de déploiement standard dans Kubernetes. Elle remplace progressivement, un par un, les pods de l'ancienne version de l'application par des pods de la nouvelle version — sans temps d'arrêt pour le cluster.

Kubernetes attend que les nouveaux pods soient prêts à fonctionner (en les vérifiant grâce à des tests de disponibilité), avant de commencer à réduire les anciens. En cas de problème, une mise à jour progressive peut être interrompue sans arrêter l'intégralité du cluster. Dans le fichier YAML décrivant le type de déploiement, la nouvelle image remplace l'ancienne image :

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: awesomeapp
    spec:
      containers:
        - name: awesomeapp
          image: imagerepo-user/awesomeapp:new
          ports:
            - containerPort: 8080

Les paramètres de la mise à jour progressive peuvent être précisés dans le fichier de manifeste :

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

Recreate (recréation)

Dans ce type de déploiement le plus simple, les anciens pods sont détruits tous en même temps et remplacés par de nouveaux :

Le manifeste correspondant ressemble à ceci :

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

Blue/Green (déploiements bleu/vert)

La stratégie de déploiement bleu/vert (parfois appelée rouge/noir) prévoit le déploiement simultané des anciennes (vertes) et nouvelles (bleues) versions de l'application. Après le déploiement des deux versions, les utilisateurs normaux ont accès à la version verte, tandis que la bleue est accessible à l'équipe QA pour l'automatisation des tests via un service séparé ou un redirection directe des ports :

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

Une fois que la version bleue (nouvelle) a été testée et que sa mise en production a été approuvée, le service bascule vers elle, tandis que la version verte (ancienne) est réduite :

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

Canary (déploiements canari)

Les mises en production canari ressemblent aux déploiements bleu/vert, mais sont mieux gérées et utilisent une approche progressive . Ce type comprend plusieurs stratégies différentes, y compris les lancements « cachés » et les tests A/B.

Cette stratégie est utilisée lorsqu'il est nécessaire de tester une nouvelle fonctionnalité, généralement dans le backend de l'application. L'idée est de créer deux serveurs presque identiques : l'un dessert presque tous les utilisateurs, tandis que l'autre, avec les nouvelles fonctionnalités, ne dessert qu'un petit sous-groupe d'utilisateurs, après quoi les résultats de leurs performances sont comparés. Si tout se passe sans erreurs, la nouvelle version est progressivement déployée sur l'ensemble de l'infrastructure.

Bien que cette stratégie puisse être mise en œuvre uniquement à l'aide de Kubernetes, en remplaçant les anciens pods par de nouveaux, il est beaucoup plus pratique et simple d'utiliser un service mesh tel qu'Istio.

Par exemple, vous pouvez avoir deux manifestes différents dans Git : un standard avec le tag 0.1.0 et un "canari" avec le tag 0.2.0. En modifiant les poids dans le manifeste du passerelle virtuelle Istio, vous pouvez gérer la distribution du trafic entre ces deux déploiements :

Un guide étape par étape sur la mise en œuvre des déploiements canari avec Istio se trouve dans le document GitOps Workflows with Istio. (Note de traduction.: Nous avons également traduit un article sur les déploiements canari dans Istio ici.)

Déploiements canari avec Weaveworks Flagger

Weaveworks Flagger permet de gérer facilement et efficacement les déploiements canari.

Flagger automatise leur gestion. Il utilise Istio ou AWS App Mesh pour le routage et le basculement du trafic, ainsi que des métriques Prometheus pour analyser les résultats. De plus, l'analyse des déploiements canari peut être complétée par des webhooks pour effectuer des tests d'acceptation, des tests de charge et tout autre type de vérification.

En se basant sur le déploiement Kubernetes et, si nécessaire, sur l'échelle horizontale des pods (HPA), Flagger crée des ensembles d'objets (déploiements Kubernetes, services ClusterIP et services virtuels Istio ou App Mesh) pour effectuer l'analyse et la mise en œuvre des déploiements canari :

En mettant en œuvre une boucle de contrôle (control loop), Flagger bascule progressivement le trafic vers le serveur canari, tout en mesurant des indicateurs clés de performance, tels que le taux de requêtes HTTP réussies, la durée moyenne des requêtes et la santé des pods. En se basant sur l'analyse des KPI (indicateurs clés de performance), la partie canari soit se développe, soit se réduit, et les résultats de l'analyse sont publiés sur Slack. Une description et une démonstration de ce processus se trouvent dans le document Progressive Delivery for App Mesh.

Déploiements sombres (cachés) ou A/B

Le déploiement caché est une autre variation de la stratégie canarienne (à noter que Flagger peut également travailler avec cela). La différence entre un déploiement caché et un déploiement canarien est que les déploiements cachés concernent le frontend, et non le backend comme les canariens.

Un autre nom pour ces déploiements est A/B testing. Au lieu de permettre l'accès à une nouvelle fonctionnalité à tous les utilisateurs, elle est proposée à seulement une partie limitée d'entre eux. En général, ces utilisateurs ne savent pas qu'ils sont des testeurs précurseurs (ce qui donne lieu au terme « déploiement caché »).

À l'aide de commutateurs de fonctionnalité (feature toggles) et d'autres outils, il est possible de suivre comment les utilisateurs interagissent avec la nouvelle fonctionnalité, si cela les attire ou s'ils trouvent la nouvelle interface utilisateur déroutante, ainsi que d'autres types de métriques.

Flagger et A/B déploiements

En plus du routage basé sur le poids, Flagger peut également diriger le trafic vers le serveur canarien en fonction des paramètres HTTP. Lors des tests A/B, il est possible d'utiliser des en-têtes HTTP ou des cookies pour rediriger un segment spécifique d'utilisateurs. Cela est particulièrement efficace dans le cas d'applications frontend nécessitant une affinité de session au serveur (session affinity). Des informations supplémentaires peuvent être trouvées dans la documentation de Flagger.

L'auteur remercie Stefan Prodan, ingénieur chez Weaveworks (et créateur de Flagger), pour tous ces schémas de déploiement impressionnants.

P.S. de l'auteur

Lisez aussi dans notre blog :

• «Aperçu et comparaison des contrôleurs Ingress pour Kubernetes»;
• «werf est notre outil pour CI/CD dans Kubernetes (aperçu et vidéo de la présentation).»;
• «Construction et déploiement de microservices similaires avec werf et GitLab CI.»;
• «Qu'est-ce que GitOps ?».

Source : habr.com