Note traduction: Cet aperçu de Weaveworks présente les stratégies de déploiement d'applications les plus populaires et montre comment les plus avancées peuvent être mises en œuvre à l'aide de l'opérateur Kubernetes Flagger. Il est rédigé dans un langage simple et contient des diagrammes visuels qui permettent même aux ingénieurs novices de comprendre le problème.
Le diagramme est tiré de stratégies de déploiement made in Container Solutions
L’un des plus grands défis actuels du développement d’applications cloud natives est l’accélération du déploiement. Dans une approche de microservices, les développeurs travaillent déjà avec et conçoivent des applications entièrement modulaires, permettant à différentes équipes d'écrire simultanément du code et d'apporter des modifications à l'application.
Des déploiements plus courts et plus fréquents présentent les avantages suivants :
- Les délais de mise sur le marché sont réduits.
- 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 ajouter des fonctionnalités et résoudre les problèmes plus rapidement.
- Le moral des développeurs augmente : plus de fonctionnalités en développement sont plus amusantes à utiliser.
Mais à mesure que la fréquence des versions augmente, les risques d'impact négatif sur la fiabilité de l'application ou sur l'expérience utilisateur augmentent également. C'est pourquoi il est important que les équipes opérationnelles et DevOps élaborent des processus et gèrent les stratégies de déploiement de manière à minimiser les risques pour le produit et les utilisateurs. (Vous pouvez en savoir plus sur l'automatisation du pipeline CI/CD .)
Dans cet article, nous aborderons diverses stratégies de déploiement dans Kubernetes, y compris les déploiements continus et les méthodes plus avancées telles que les déploiements Canary 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 plus approfondis, ou à un sous-ensemble d'utilisateurs/clients, ou vous devrez peut-être effectuer des tests utilisateur limités avant de créer une fonctionnalité. disponible au public.
Rolling (déploiement progressif, « rolling »)
Il s'agit de la 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 à fonctionner (en les vérifiant à l'aide de ), avant de commencer à enrouler les anciens. Si un problème survient, cette mise à jour continue peut être interrompue sans arrêter l'ensemble 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: 8080Les paramètres de mise à jour par roulement peuvent être spécifiés dans le fichier manifeste :
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recréer
Dans ce type de déploiement le plus simple, les anciens pods sont supprimés d’un seul coup et remplacés par de nouveaux :
Le manifeste correspondant ressemble à ceci :
spec:
replicas: 3
strategy:
type: Recreate
template:
...Bleu/Vert (déploiements bleu-vert)
La stratégie de déploiement bleu-vert (parfois aussi appelée rouge/noir) implique le déploiement simultané de l'ancienne (verte) et de la nouvelle (bleue) version de l'application. Après avoir publié les deux versions, les utilisateurs réguliers ont accès à la version verte, tandis que la bleue est disponible pour l'équipe QA afin d'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 que la (nouvelle) version bleue a été testée et que sa sortie a été approuvée, le service y bascule et la version verte (ancienne) est pliée :
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (déploiements Canary)
Les déploiements Canary sont similaires aux déploiements bleu-vert, mais offrent un meilleur contrôle et une meilleure utilisation. approche étape par étape. Ce type comprend plusieurs stratégies différentes, notamment les lancements « furtifs » et les tests A/B.
Cette stratégie est utilisée lorsqu'il est nécessaire d'essayer de nouvelles fonctionnalités, généralement dans le backend de l'application. L'essence de l'approche est de créer deux serveurs presque identiques : l'un sert presque tous les utilisateurs et l'autre, avec de nouvelles fonctions, ne dessert qu'un petit sous-groupe d'utilisateurs, après quoi les résultats de leur travail sont comparés. Si tout se passe sans erreur, la nouvelle version est progressivement déployée sur l'ensemble de l'infrastructure.
Bien que cette stratégie puisse être mise en œuvre exclusivement à l'aide de Kubernetes, en remplaçant les anciens pods par de nouveaux, il est beaucoup plus pratique et plus simple d'utiliser un maillage de services comme Istio.
Par exemple, vous pouvez avoir deux manifestes différents dans Git : un manifeste standard avec la balise 0.1.0 et un manifeste Canary avec la balise 0.2.0. En modifiant les pondérations dans le manifeste de la passerelle virtuelle Istio, vous pouvez contrôler la répartition du trafic entre ces deux déploiements :
Pour un guide étape par étape sur la mise en œuvre des déploiements Canary à l'aide d'Istio, consultez . (Noter. trad. : Nous avons également traduit des documents sur les déploiements Canary dans Istio. .)
Déploiements Canary avec Weaveworks Flagger
vous permet de gérer facilement et efficacement les déploiements Canary.
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 Canary peut être complétée par des webhooks pour effectuer des tests d'acceptation, des tests de charge et tout autre type de contrôle.
Sur la base du déploiement 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 analyser et mettre en œuvre les déploiements Canary :
Implémentation de la boucle de contrôle (boucle de contrôle),Flagger bascule progressivement le trafic vers le serveur Canary, tout en mesurant simultanément des indicateurs de performances clés tels que le pourcentage de requêtes HTTP réussies, la durée moyenne des requêtes et l'état des pods. Sur la base de l'analyse des KPI (Key Performance Indicators), le canari grandit 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 le matériel .
Déploiements sombres (cachés) ou A/B
Le déploiement furtif est une autre variante de la stratégie Canary (avec laquelle, d'ailleurs, Flagger peut également travailler). La différence entre les déploiements furtifs et Canary est que les déploiements furtifs traitent le frontend plutôt que le backend comme les déploiements Canary.
Un autre nom pour ces déploiements est les tests A/B. Au lieu de rendre la nouvelle fonctionnalité accessible à tous les utilisateurs, elle n’est proposée qu’à une partie limitée d’entre eux. Généralement, ces utilisateurs ignorent qu’ils sont des testeurs pionniers (d’où le terme « déploiement furtif »).
Utilisation des commutateurs de fonctionnalité (bascule de fonctionnalité) et d'autres outils, vous pouvez surveiller la manière dont les utilisateurs interagissent avec la nouvelle fonctionnalité, s'ils sont intéressés par celle-ci ou s'ils trouvent la nouvelle interface utilisateur déroutante, ainsi que d'autres types de mesures.
Déploiements Flagger et A/B
En plus du routage basé sur le poids, Flagger peut également acheminer le trafic vers le serveur Canary en fonction des paramètres HTTP. Dans les tests A/B, vous pouvez utiliser des en-têtes HTTP ou des cookies pour cibler un segment spécifique d'utilisateurs. Ceci est particulièrement efficace dans le cas d'applications frontales qui nécessitent une liaison de session au serveur. (affinité de session). Plus d’informations peuvent être trouvées dans la documentation Flagger.
L'auteur est reconnaissant , ingénieur Weaveworks (et créateur de Flagger), pour tous ces modèles de déploiement étonnants.
PS du traducteur
A lire aussi sur notre blog :
- «";
- «";
- «";
- «».
Source: habr.com