Remarque perev.: Ce document de revue de Weaveworks présente les stratégies de déploiement d'applications les plus populaires et parle de la possibilité de mettre en œuvre les plus avancées d'entre elles à l'aide de l'opérateur Kubernetes Flagger. Il est écrit dans un langage simple et contient des diagrammes visuels qui permettent aux ingénieurs, même novices, de comprendre le problème.
Le diagramme est tiré d' un autre examen des stratégies de déploiement effectuées chez Container Solutions.Aujourd'hui, l'un des plus gros problèmes de développement d'applications natives cloud est le déploiement de déploiement. Avec l'approche microservice, 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 à l'application en même temps.
Les 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 les utilisateurs plus rapidement.
- Les commentaires des utilisateurs parviennent plus rapidement à l'équipe de développement. Cela signifie que l'équipe peut compléter les fonctions et résoudre les problèmes plus rapidement.
- Le moral des développeurs augmente: il est plus intéressant de travailler avec un grand nombre de fonctions en développement.
Mais avec l'augmentation des fréquences de publication, les chances de nuire à la fiabilité des applications ou à l'expérience utilisateur augmentent également. C'est pourquoi il est important pour les équipes opérationnelles et DevOps de créer des processus et de gérer les stratégies de déploiement de manière à minimiser les risques pour le produit et les utilisateurs. (En savoir plus sur l'automatisation du pipeline CI / CD
ici .)
Dans cet article, nous discuterons de diverses stratégies de déploiement chez Kubernetes, y compris des déploiements roulants et des méthodes plus avancées telles que les déploiements canaries et leurs variantes.
Stratégies de déploiement
Il existe plusieurs types de stratégies de déploiement que vous pouvez utiliser en fonction de votre objectif. Par exemple, vous devrez peut-être apporter des modifications à un certain environnement pour des tests supplémentaires, ou à un sous-ensemble d'utilisateurs / clients, ou vous devrez peut-être effectuer des tests limités sur les utilisateurs avant de rendre certaines fonctions
accessibles au public .
Rolling (déploiement progressif et «glissant»)
Il s'agit d'une stratégie de déploiement standard dans Kubernetes. Il remplace progressivement, un par un, les pods avec l'ancienne version de l'application par des pods avec la nouvelle version - sans temps d'arrêt du cluster.
Kubernetes attend que les nouveaux pods soient prêts pour le travail (en les vérifiant avec des
tests de préparation ) avant de commencer à réduire les anciens. Si un problème se produit, une telle mise à jour continue peut être interrompue sans arrêter l'intégralité du cluster. Dans le fichier YAML de 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 d'une mise à jour continue peuvent être spécifiés dans le fichier manifeste:
spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 25% maxUnavailable: 25% template: ...
Recréer (recréation)
Dans ce type de déploiement le plus simple, les anciens pods sont tués en même temps et remplacés par de nouveaux:
Le manifeste correspondant ressemble à ceci:
spec: replicas: 3 strategy: type: Recreate template: ...
Bleu / vert (déploiement bleu-vert)
La stratégie de déploiement bleu-vert (parfois aussi appelée rouge / noir, c'est-à-dire rouge-noir) implique le déploiement simultané de l'ancienne (verte) et de la nouvelle (bleue) versions de l'application. Après avoir placé les deux versions, les utilisateurs ordinaires ont accès à la version verte, tandis que la version bleue est disponible pour l'équipe QA pour automatiser les tests via un service distinct ou une redirection de port directe:
apiVersion: apps/v1beta1 kind: Deployment metadata: name: awesomeapp-02 spec: template: metadata: labels: app: awesomeapp version: "02"
Une fois la version bleue (nouvelle) testée et sa version approuvée, le service y bascule et le vert (ancien) est minimisé:
apiVersion: v1 kind: Service metadata: name: awesomeapp spec: selector: app: awesomeapp version: "02" ...
Canaries (déploiement canari)
Les rouleaux canaris ressemblent à du bleu-vert, mais sont mieux gérés et utilisent une approche
progressive par étapes. 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 faire l'expérience de nouvelles fonctionnalités, en règle générale, dans le backend de l'application. L'essence de l'approche est de créer deux serveurs presque identiques: l'un dessert presque tous les utilisateurs et l'autre, avec de nouvelles fonctionnalités, ne dessert qu'un petit sous-ensemble d'utilisateurs, après quoi leurs résultats sont comparés. Si tout se passe bien, la nouvelle version se déploie progressivement sur l'ensemble de l'infrastructure.
Bien que cette stratégie ne puisse être mise en œuvre qu'en utilisant les outils Kubernetes, en remplaçant les anciens pods par de nouveaux, il est beaucoup plus pratique et plus facile d'utiliser un maillage de service comme Istio.
Par exemple, vous pouvez avoir deux manifestes différents dans Git: le régulier avec la balise 0.1.0 et le canari avec la balise 0.2.0. En modifiant les poids dans le manifeste de la passerelle virtuelle Istio, vous pouvez contrôler la répartition du trafic entre ces deux déploiements:
Pour une procédure pas à pas sur l'implémentation de déploiements canaries avec Istio, consultez
GitOps Workflows with Istio .
( Remarque : nous avons également traduit ici du matériel sur les rouleaux de canaris à Istio.)Déploiements des Canaries avec Weaveworks Flagger
Weaveworks Flagger permet de gérer facilement et efficacement les déploiements des canaris.
Flagger automatise le travail avec eux. Il utilise Istio ou AWS App Mesh pour acheminer et commuter le trafic, ainsi que les métriques Prometheus pour analyser les résultats. De plus, l'analyse des déploiements canaris peut être complétée par des webhooks pour les tests d'acceptation, les tests de stress et tout autre type de contrôles.
Sur la base du déploiement de Kubernetes et, si nécessaire, de la mise à 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 l'analyse et la mise en œuvre des déploiements canaries:
Implémentant une
boucle de contrôle , Flagger bascule progressivement le trafic vers le serveur canari, tout en mesurant simultanément les indicateurs de performance clés, tels que le pourcentage de requêtes HTTP réussies, la durée moyenne des requêtes et la santé des pods. Sur la base de l'analyse des KPI (indicateurs clés de performance), la partie canari croît ou s'effondre, et les résultats de l'analyse sont publiés dans Slack. Une description et une démonstration de ce processus peuvent être trouvées dans la
livraison progressive pour le maillage d'application .
Déploiement sombre (caché) ou A / B
Le déploiement secret est une autre variante de la stratégie canarienne (Flagger peut également fonctionner avec, d'ailleurs). La différence entre les déploiements secrets et canaris est que les déploiements secrets traitent avec le frontend et non le backend, comme ceux des canaris.
Un autre nom pour ces déploiements est A / B testing. Au lieu d'ouvrir l'accès à la nouvelle fonction à tous les utilisateurs, elle n'est proposée qu'à une partie limitée. Généralement, ces utilisateurs ne savent pas qu'ils sont des testeurs pionniers (d'où le terme «déploiement secret»).
À l'aide des
bascules de fonction et d'autres outils, vous pouvez surveiller la façon dont les utilisateurs interagissent avec la nouvelle fonction, si elle les captive ou s'ils trouvent la nouvelle interface utilisateur déroutante et d'autres types de mesures.
Flagger et déploiements A / B
En plus du routage pondéré, Flagger peut également diriger le trafic vers le serveur canary, en fonction des paramètres HTTP. Pour les tests A / B, vous pouvez utiliser des en-têtes HTTP ou des cookies pour rediriger un segment spécifique d'utilisateurs. Ceci est particulièrement efficace pour les applications frontales qui nécessitent une
affinité de session pour le serveur. Pour plus d'informations, consultez la documentation de Flagger.
L'auteur remercie Stefan Prodan , ingénieur Weaveworks (et créateur de Flagger), pour tous ces déploiements impressionnants.PS du traducteur
Lisez aussi dans notre blog: