Déploiement bleu-vert de clusters AKS

Azure Kubernetes Service (AKS)

Azure Application Gateway

Azure Container Registry

Azure Front Door

Azure DNS

Cet article fournit des conseils sur l’implémentation d’une stratégie de déploiement bleu-vert afin de tester une nouvelle version d’un cluster Azure Kubernetes Service (AKS), tout en continuant à exécuter la version actuelle. Une fois la nouvelle version validée, une modification de routage bascule le trafic utilisateur vers celle-ci. Ce mode de déploiement augmente la disponibilité lors de l’apport de modifications, y compris des mises à niveau, à des clusters AKS. Cet article décrit la conception et l’implémentation d’un déploiement bleu-vert d’AKS qui utilise des services gérés Azure et des fonctionnalités Kubernetes natives.

Architecture

Cette section décrit des architectures pour le déploiement bleu-vert de clusters AKS. Il existe deux cas :

Les applications et les API sont accessibles publiques.
Les applications et les API sont accessibles privées.

Il existe également un cas hybride, non abordé ici, avec un mélange d’applications et d’API publiques et privées dans le cluster.

Le diagramme suivant montre l’architecture du cas public :

Téléchargez un fichier Visio de cette architecture.

Azure Front Door et Azure DNS fournissent le mécanisme de routage qui bascule le trafic entre les clusters bleu et vert. Pour plus d’informations, consultez Déploiement bleu-vert avec Azure Front Door. L’utilisation d’Azure Front Door permet d’implémenter un commutateur complet ou un commutateur plus contrôlé basé sur des pondérations. Cette technique est la plus fiable et la plus efficace dans un environnement Azure. Si vous souhaitez utiliser vos propres DNS et équilibreur de charge, vous devez vous assurer qu’ils sont configurés pour fournir un commutateur sûr et fiable.

Azure Application Gateway fournit les serveurs frontaux qui sont dédiés aux points de terminaison publics.

Ce diagramme concerne le cas privé :

Téléchargez un fichier Visio de cette architecture.

Dans ce cas, une seule instance Azure DNS implémente le basculement du trafic entre les clusters bleu et vert. Pour ce faire, utilisez les enregistrements A et CNAME. Pour plus d’informations, consultez la section T3 : Basculer le trafic vers le cluster vert.

Application Gateway fournit les serveurs frontaux qui sont dédiés aux points de terminaison privés.

Workflow

Dans un déploiement bleu-vert, il existe cinq étapes pour mettre à jour la version actuelle du cluster vers la nouvelle version. Dans notre description, le cluster bleu est la version actuelle, et le cluster vert la nouvelle version.

Les étapes sont :

T0 : Le cluster bleu est activé.
T1 : Déployer le cluster vert.
T2 : Synchroniser l’état de Kubernetes entre les clusters bleu et vert.
T3 : Basculer le trafic vers le cluster vert.
T4 : Détruire le cluster bleu.

Une fois la nouvelle version active, elle devient le cluster bleu pour toute modification ou mise à jour ultérieure.

Les clusters bleu et vert s’exécutent en même temps, mais seulement pendant une période limitée, ce qui optimise les coûts et les efforts opérationnels.

Déclencheurs de transition

Les déclencheurs de la transition d’une étape à l’autre peuvent être automatisés. En attendant, tout ou partie d’entre eux sont manuels. Les déclencheurs sont liés aux éléments suivants :

Métriques de charge de travail, objectifs de niveau de service (SLO) et contrats de niveau de service (SLA) spécifiques : utilisés principalement à l’étape T3 pour valider l’état global du cluster AKS avant de basculer le trafic.
Métriques de plateforme Azure : utilisées pour évaluer l’état et l’intégrité des charges de travail et du cluster AKS. Elles sont utilisées dans toutes les transitions.

Détectabilité réseau des clusters

Vous pouvez fournir une détectabilité réseau pour les clusters en procédant comme suit :

Vous devez disposer d’enregistrements DNS pointant vers les clusters. Par exemple :
- aks-blue.contoso.com pointe vers l'IP privée ou publique du cluster bleu.
- aks-green.contoso.com pointe vers l'IP privée ou publique du cluster vert.
Vous pouvez ensuite utiliser ces noms d’hôte directement ou dans la configuration de pool principal de la passerelle d’application qui se trouve devant chaque cluster.
Vous devez disposer d’enregistrements DNS pointant vers les passerelles applicatives. Par exemple :
- aks-blue.contoso.com pointe vers l’adresse IP privée ou publique de la passerelle applicative qui a comme pool principal l’adresse IP privée ou publique du cluster bleu.
- aks-green.contoso.com pointe vers l’adresse IP privée ou publique de la passerelle applicative qui a comme pool principal l’adresse IP privée ou publique du cluster vert.

T0 : Le cluster bleu est activé

L’étape initiale, T0, est que le cluster bleu soit actif. Cette étape prépare la nouvelle version du cluster pour le déploiement.

La condition de déclencheur pour l’étape T1 est la publication d’une nouvelle version du cluster, le cluster vert.

T1 : Déployer le cluster vert

Cette étape commence le déploiement du nouveau cluster vert. Le cluster bleu reste activé et le trafic actif y est toujours acheminé.

Le déclencheur pour passer à l’étape T2 est la validation du cluster AKS vert au niveau de la plateforme. La validation utilise des métriques Azure Monitor et des commandes CLI pour vérifier l’intégrité du déploiement. Pour plus d’informations, consultez Surveillance d’Azure Kubernetes Service (AKS) avec Monitor et Surveillance de la référence des données AKS.

La surveillance AKS peut être divisée en différents niveaux, comme l’illustre le diagramme suivant :

La santé du cluster est évaluée aux niveaux 1 et 2, et à une partie du niveau 3. Pour le niveau 1, vous pouvez utiliser la vue multicluster native de Monitor pour valider l’intégrité, comme illustré ici :

Au niveau 2, assurez-vous que le serveur d’API Kubernetes et Kubelet fonctionnent correctement. Vous pouvez utiliser le classeur Kubelet dans Monitor, plus précisément les deux grilles du classeur qui montrent les principales statistiques de fonctionnement des nœuds :

La grille de vue d’ensemble par nœud indique le nombre total d’opérations, le nombre total d’erreurs et les opérations réussies en pourcentage et en tendance pour chaque nœud.
La grille de vue d’ensemble par type d’opération fournit, pour chaque type d’opération, le nombre d’opérations, les erreurs et les opérations réussies en pourcentage et en tendance.

Le niveau 3 est dédié aux objets et applications Kubernetes qui sont déployés par défaut dans AKS, comme omsagent, kube-proxy, etc. Pour cette vérification, vous pouvez utiliser la vue Insights de Monitor pour vérifier l’état des déploiements AKS :

Vous pouvez également utiliser le classeur dédié documenté dans Déploiement et métriques HPA avec les aperçus de conteneurs. Voici un exemple :

Une fois la validation réussie, vous pouvez passer à l’étape T2.

T2 : Synchroniser l’état de Kubernetes entre les clusters bleu et vert

À ce stade, les applications, les opérateurs et les ressources Kubernetes ne sont pas encore déployés dans le cluster vert ou, du moins, ne sont pas tous applicables et déployés lorsque le cluster AKS est approvisionné. L’objectif final de cette étape est qu’à la fin de la synchronisation, le cluster vert présente une compatibilité descendante avec le cluster bleu. Si c’est le cas, il est possible de valider l’état du nouveau cluster avant de basculer le trafic vers le cluster vert.

Il existe différentes façons de synchroniser l’état de Kubernetes entre clusters :

Redéploiement par intégration continue et livraison continue (CI/CD). En règle générale, il suffit d’utiliser les mêmes pipelines de CI/CD que ceux utilisés pour le déploiement normal des applications. Les outils courants pour ce faire sont les suivants : GitHub Actions, Azure DevOps et Jenkins.
GitOps, avec des solutions promues sur le site web de la Cloud Native Computing Foundation (CNCF), comme Flux et ArgoCD.
Solution personnalisée qui stocke les configurations et les ressources de Kubernetes dans un magasin de données. En règle générale, ces solutions sont basées sur des générateurs de manifeste Kubernetes qui commencent à partir de définitions de métadonnées, puis stockent les manifestes Kubernetes générés dans un magasin de données comme Azure Cosmos DB. Il s’agit généralement de solutions personnalisées basées sur l’infrastructure de description d’application utilisée.

Le diagramme suivant montre le processus de synchronisation de l’état de Kubernetes :

En règle générale, pendant la synchronisation, le déploiement de nouvelles versions d’applications n’est pas autorisé dans le cluster actif. Cette période commence avec la synchronisation et se termine une fois le basculement vers le cluster vert terminé. La façon de désactiver les déploiements dans Kubernetes peut varier. Il existe deux solutions possibles :

Désactiver les pipelines de déploiement.
Désactiver le compte de service Kubernetes qui exécute les déploiements.

Il est possible d’automatiser la désactivation du compte de service à l’aide de l’Open Policy Agent (OPA). Il n’est pas encore possible d’utiliser les fonctionnalités natives d’AKS à cette fin, car elles sont toujours en préversion.

Il est possible d’éviter la période de synchronisation en utilisant des mécanismes avancés qui gèrent l’état de Kubernetes dans plusieurs clusters.

Une fois la synchronisation terminée, la validation du cluster et des applications est requise. notamment :

Vérification des plateformes de surveillance et de journalisation pour valider l’intégrité du cluster. Vous pouvez envisager de procéder comme à l’étape T1 : Déployer le cluster vert.
Test fonctionnel de l’application en fonction de la chaîne d’outils actuellement utilisée.

Nous vous recommandons également d’exécuter une session de test de charge afin de comparer les performances des applications du cluster vert à une ligne de base de performances. Vous pouvez utiliser l’outil de votre choix ou le Test de charge Azure.

En règle générale, le cluster vert est exposé sur la passerelle applicative ou l’équilibreur de charge externe avec une URL interne qui n’est pas visible par des utilisateurs externes.

Une fois le nouveau cluster validé, vous pouvez passer à l’étape suivante pour basculer le trafic vers le nouveau cluster.

T3 : Basculer le trafic vers le cluster vert

Une fois la synchronisation terminée et le cluster vert validé aux niveaux de la plateforme et de l’application, il est prêt à être promu comme cluster principal et à commencer à recevoir le trafic actif. Le basculement est effectué au niveau de la mise en réseau. Les charges de travail sont souvent sans état. En revanche, si elles sont avec état, une solution supplémentaire doit être implémentée pour maintenir l’état et la mise en cache pendant le basculement.

Voici un diagramme montrant l’état cible après le basculement :

Les techniques décrites dans cet article implémentent des basculements complets : la totalité du trafic est acheminée vers le nouveau cluster. Cela est dû au fait que le routage est appliqué au niveau du DNS avec une attribution d’enregistrement A ou CNAME qui est mise à jour pour pointer vers le cluster vert, et qu’il existe une passerelle applicative pour chaque cluster.

Voici un exemple de configuration pour basculer des points de terminaison privés. La solution proposée utilise des enregistrements A pour opérer le basculement. Dans la perspective d’un mappage de DNS et d’adresse IP, avant le basculement, la situation est la suivante :

A enregistrement aks.priv.contoso.com pointe vers l'IP privée de la passerelle d'application bleue.
A enregistrement aks-blue.priv.contoso.com pointe vers l'IP privée de la passerelle d'application bleue.
A enregistrement aks-green.priv.contoso.com pointe vers l'IP privée de la passerelle d'application verte.

Le basculement reconfigure comme suit :

A enregistrement aks.priv.contoso.com pointe vers l'IP privée de la passerelle d'application verte.
A enregistrement aks-blue.priv.contoso.com pointe vers l'IP privée de la passerelle d'application bleue.
A enregistrement aks-green.priv.contoso.com pointe vers l'IP privée de la passerelle d'application verte.

Les utilisateurs des clusters verront le commutateur après l’expiration de la durée de vie (TTL) et la propagation DNS des enregistrements.

Pour les points de terminaison publics, l’approche recommandée utilise Azure Front Door et Azure DNS. La configuration avant le basculement est la suivante :

CNAME enregistrement official-aks.contoso.com pointe vers un enregistrement du domaine Azure Front Door autogénéré. Pour plus d’informations, consultez Didacticiel : Ajouter un domaine personnalisé à votre Front Door.
A enregistrement aks.contoso.com pointe vers l'IP publique de la passerelle d'application bleue.
La configuration d’origine d’Azure Front Door pointe vers le nom d’hôte aks.contoso.com. Pour plus d’informations sur la configuration des pools principaux, consultez Origines et groupes d’origines dans Azure Front Door.
- A enregistrement aks-blue.contoso.com pointe vers l'IP publique de la passerelle d'application bleue.
- A enregistrement aks-green.contoso.com pointe vers l'IP publique de la passerelle d'application verte.

Le basculement reconfigure comme suit :

CNAME enregistrement official-aks.contoso.com pointe vers un enregistrement du domaine Azure Front Door autogénéré.
A enregistrement aks.contoso.com pointe vers l'IP publique de la passerelle d'application verte.
La configuration d’origine d’Azure Front Door pointe vers le nom d’hôte aks.contoso.com.
- A enregistrement aks-blue.contoso.com pointe vers l'IP publique de la passerelle d'application bleue.
- A enregistrement aks-green.contoso.com pointe vers l'IP publique de la passerelle d'application verte.

D’autres techniques de basculement, telles que des commutateurs partiels pour les versions de contrôle de validité, sont possibles avec des services Azure supplémentaires comme Azure Front Door ou Traffic Manager. Pour une implémentation d’un commutateur de trafic bleu-vert au niveau d’Azure Front Door, consultez Déploiement bleu-vert avec Azure Front Door.

Comme décrit dans l’exemple, dans une perspective de mise en réseau, cette technique est basée sur la définition de quatre noms d’hôtes :

Nom d’hôte public officiel : nom d’hôte public officiel utilisé par les utilisateurs finaux et les consommateurs.
Nom d’hôte du cluster : nom d’hôte officiel utilisé par les consommateurs des charges de travail hébergées dans les clusters.
Nom d’hôte du cluster bleu : nom d’hôte dédié pour le cluster bleu.
Nom d’hôte du cluster vert : nom d’hôte dédié pour le cluster vert.

Le nom d’hôte du cluster est celui qui est configuré au niveau de la passerelle applicative pour gérer le trafic d’entrée. Le nom d’hôte fait également partie de la configuration d’entrée d’AKS afin de gérer correctement le protocole TLS (Transport Layer Security). Cet hôte est utilisé uniquement pour les transactions et les requêtes actives.

Si Azure Front Door fait également partie du déploiement, il n’est pas affecté par le commutateur, car il gère uniquement le nom d’hôte officiel du cluster. Il fournit l’abstraction appropriée pour les utilisateurs de l’application. Ceux-ci ne sont pas affectés par le basculement, car l’enregistrement DNS CNAME pointe toujours vers Azure Front Door.

Les noms d’hôtes de cluster bleu et vert sont principalement utilisés pour tester et valider les clusters. À ces fins, les noms d’hôtes sont exposés au niveau de la passerelle applicative avec des points de terminaison dédiés, ainsi qu’au niveau du contrôleur d’entrée AKS pour gérer correctement le protocole TLS.

À ce stade, la validation est basée sur les métriques de surveillance d’infrastructure et d’application, ainsi que sur les SLO et SLA officiels, s’ils sont disponibles. Si la validation réussit, passez à l’étape finale pour détruire le cluster bleu.

T4 : Détruire le cluster bleu

Le basculement du trafic nous amène à l’étape finale, qui inclut encore une validation et une surveillance pour s’assurer que le cluster vert fonctionne comme prévu avec le trafic actif. La validation et la surveillance couvrent les niveaux plateforme et application.

Une fois cette validation terminée, le cluster bleu peut être détruit. La destruction est une étape fortement recommandée afin de réduire les coûts et d’utiliser correctement l’élasticité qu’offre Azure, en particulier AKS.

Voici la situation après la destruction du cluster bleu :

Composants

Application Gateway est un équilibreur de charge de trafic web (couche OSI 7) qui vous permet de gérer le trafic vers vos applications web. Dans cette solution, il est utilisé comme passerelle pour le trafic HTTP pour accéder aux clusters AKS.
Azure Kubernetes Service (AKS) est un service de Kubernetes managé qui permet de déployer de gérer des applications conteneurisées. Cette plateforme d’application est le composant principal de ce modèle.
Azure Container Registry est un service managé utilisé pour stocker et gérer les images conteneur et les artefacts associés. Dans cette solution, il permet de stocker et distribuer des images conteneur et des artefacts, tels que des graphiques Helm, dans les clusters AKS.
Azure Monitor est une solution de monitoring qui permet de collecter, d’analyser et de répondre aux données de monitoring à partir de vos environnements cloud et locaux. Il fournit les principales fonctionnalités de surveillance requises pour exécuter le déploiement bleu vert. Il est utilisé dans cette architecture en raison de son intégration avec AKS et de sa capacité à fournir des fonctionnalités de journalisation, de surveillance et d’alerte utilisables pour gérer les transitions entre étapes.
Azure Key Vault permet de résoudre les problèmes suivants : gestion des secrets, gestion des clés et gestion des certificats ; il est utilisé pour stocker et gérer les secrets et certificats requis au niveau de la plateforme et de l’application pour cette solution.
Azure Front Door est un système global d’équilibrage de charge et de gestion des points de terminaison d’application. Il est utilisé dans cette solution comme point de terminaison public pour les applications HTTP hébergées sur AKS. Dans cette solution, il a la responsabilité essentielle de gérer le basculement du trafic entre les passerelles d’applications bleu et vert.
Azure DNS est un service d’hébergement pour les domaines DNS, qui offre une résolution de noms à l’aide de l’infrastructure Microsoft Azure. Il gère les noms d’hôtes utilisés dans la solution pour les clusters bleu et vert et joue un rôle important dans les commutateurs de trafic, en particulier pour les points de terminaison privés.

Autres solutions

D’autres techniques d’implémentation des commutateurs de trafic peuvent fournir plus de contrôle. Par exemple, il est possible d’opérer un basculement partiel en utilisant des règles de trafic basées sur un ou plusieurs des éléments suivants :
- Pourcentage de trafic entrant
- En-têtes HTTP
- Cookies
Une alternative qui offre une meilleure protection contre les problèmes causés par des modifications consiste à opter pour des déploiements basés sur des boucles. Au lieu de n’avoir que des clusters bleus et verts, il est possible d’avoir plus de clusters, appelés boucles. Chaque boucle est suffisamment grande pour le nombre d’utilisateurs qui ont accès à la nouvelle version d’AKS. Comme pour le déploiement bleu-vert décrit ici, les boucles peuvent être supprimées afin de bénéficier d’une optimisation et d’un contrôle des coûts appropriés.
Les alternatives possibles à Application Gateway sont NGINX et HAProxy.
Une alternative possible à Container Registry est Harbor.
Dans certaines circonstances, il est possible d’utiliser des services d’équilibrage de charge et DNS autres qu’Azure Front Door et Azure DNS pour opérer les basculements de trafic.
Cette solution est basée sur les API Kubernetes du contrôleur d’entrée standard. Si votre solution bénéficie plutôt de l’API Gateway, utilisez Application Gateway pour les conteneurs. Il peut aider à gérer l’équilibrage de charge et à gérer le trafic d’entrée entre Application Gateway et les pods. Application Gateway pour les conteneurs contrôle les paramètres des passerelles d’application.

Détails du scénario

Les principaux avantages de la solution sont les suivants :

Temps d’arrêt réduit au minimum pendant le déploiement.
Stratégie de restauration planifiée.
Contrôle et opérations améliorés pendant la publication et le déploiement des modifications et mises à niveau d’AKS.
Test de la nécessité d’exécuter des procédures de récupération d’urgence (DR).

Les principes clés et les aspects fondamentaux du déploiement bleu-vert sont abordés dans les articles suivants :

Dans la perspective de l’automatisation et de la CI/CD, la solution peut être implémentée de plusieurs manières. Voici nos suggestions :

Bicep ou Terraform pour IaC.
Azure Pipelines ou GitHub Actions pour CI/CD.

Cas d’usage potentiels

Le déploiement bleu-vert permet d’apporter des modifications aux clusters sans que cela affecte les applications et charges de travail en cours d’exécution. Voici des exemples de modifications :

Modifications opérationnelles
Activation de nouvelles fonctionnalités d’AKS
Modifications apportées à des ressources partagées dans les clusters
Mise à jour de la version de Kubernetes
Modification de ressources et objets Kubernetes, comme la passerelle d’entrée, le maillage du service, des opérateurs, des stratégies réseau, etc.
Restauration de la version précédente d’un cluster AKS toujours déployé, sans que cela affecte les charges de travail en cours d’exécution dans le cluster.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Un déploiement bleu-vert peut être entièrement automatisé, comme un déploiement sans intervention. En règle générale, une implémentation initiale inclut des déclencheurs manuels pour activer les étapes. En cours de route et avec les fonctionnalités de maturité et de surveillance appropriées, il est possible d’automatiser les déclencheurs. Cela signifie qu’il existe des tests automatisés et des métriques spécifiques, un contrat SLA et un SLO pour automatiser les déclencheurs.
Il est important d’avoir des noms d’hôtes dédiés pour les clusters bleu et vert, ainsi que d’avoir des configurations de point de terminaison dédiées sur les passerelles et les équilibreurs de charge qui se trouvent devant les clusters. Cela est essentiel pour améliorer la fiabilité et la validité du déploiement du nouveau cluster. De cette façon, la validation du déploiement se produit avec la même architecture et les mêmes configurations qu’un cluster de production standard.
Considérez une situation dans laquelle les clusters AKS sont des ressources partagées pour plusieurs applications gérées par différentes unités commerciales. Dans ce cas, il est courant que la plateforme AKS elle-même soit gérée par une équipe dédiée responsable de l’exploitation globale et du cycle de vie des clusters, et qu’il existe dans les clusters des points de terminaison dédiés à l’administration et à l’exploitation. Nous suggérons que ces points de terminaison disposent d’un contrôleur d’entrée dédié dans les clusters AKS pour assurer une séparation appropriée des préoccupations et pour la fiabilité.
Un déploiement bleu-vert est utile pour implémenter et tester des solutions de continuité d’activité et reprise d’activité (BCDR) pour AKS et les charges de travail associées. En particulier, il fournit les structures fondamentales pour la gestion de plusieurs clusters, y compris dans les cas où les clusters sont répartis entre plusieurs régions.
La réussite d’un déploiement bleu-vert repose sur l’application de tous les aspects de l’implémentation, tels que l’automatisation, la supervision et la validation, non seulement à la plateforme AKS, mais aussi aux charges de travail et aux applications déployées sur la celle-ci. Cela vous permet de tirer le meilleur parti d’un déploiement bleu-vert.
Dans la solution proposée, il existe deux passerelles Application Gateway par scénario public et privé, donc quatre au total. Cette décision consiste à appliquer un déploiement bleu vert au niveau d’Azure Application Gateway pour éviter les temps d’arrêt causés par une mauvaise configuration des passerelles. L’inconvénient principal de cette décision est le coût, car il existe quatre instances Application Gateway. Elles s’exécutent en parallèle uniquement pendant la période au cours de laquelle des modifications pertinentes sont apportées aux configurations d’Application Gateway, telles que les stratégies WAF ou une configuration de mise à l’échelle. Pour optimiser davantage les coûts, vous pouvez opter pour une passerelle Application Gateway unique par scénario, donc deux Applications Gateway au total. Cela vous oblige à déplacer la logique bleu/vert vers la passerelle d’application, plutôt que Azure Front Door. Par conséquent, ce n’est plus Azure Front Door qui doit être impérativement contrôlé, mais Application Gateway.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Un déploiement bleu-vert a un effet direct et positif sur la disponibilité de la plateforme AKS et des charges de travail. En particulier, il augmente la disponibilité pendant le déploiement des modifications de la plateforme AKS. Il y a peu de temps d’arrêt si les sessions utilisateur sont bien gérées.
Un déploiement bleu-vert fournit une couverture pour la fiabilité pendant le déploiement car, par défaut, il permet de revenir à la version précédente du cluster AKS en cas de problème dans sa nouvelle version.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et à améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Le déploiement bleu-vert est largement adopté dans Azure en raison de l’élasticité native qu’offre le cloud. Cela permet d’optimiser les coûts en termes d’opérations et de consommation de ressources. La plupart des économies résultent de la suppression du cluster qui n’est plus nécessaire après le déploiement d’une nouvelle version du cluster.
Quand une nouvelle version est déployée, il est courant d’héberger les clusters bleu et vert dans le même sous-réseau, afin de conserver la même ligne de base de coût. Toutes les connexions réseau, ainsi que l’accès aux ressources et services sont les mêmes pour les deux clusters, et tous les services et ressources Azure restent les mêmes.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

Le déploiement bleu-vert, quand il est correctement implémenté, assure une automatisation, une livraison continue et un déploiement résilient.
L’un des aspects clés de la livraison continue est qu’elle fournit de manière itérative des incréments de modifications de plateforme et de charge de travail. Avec un déploiement bleu-vert d’AKS, vous obtenez une livraison continue au niveau de la plateforme, de manière contrôlée et sûre.
La résilience est fondamentale pour un déploiement bleu-vert car elle inclut la possibilité de restaurer le cluster précédent.
Un déploiement bleu-vert offre le niveau d’automatisation approprié pour réduire les efforts liés à la stratégie de continuité d’activité.
La surveillance de la plateforme et des applications est cruciale pour une implémentation réussie. Pour la plateforme, il est possible d’utiliser les fonctionnalités de surveillance natives d’Azure. Pour les applications, une surveillance doit être conçue et implémentée.

Déployer ce scénario

Pour obtenir un exemple implémenté d’un déploiement bleu-vert décrit dans ce guide, consultez Accélérateur de zone d’atterrissage AKS.

Cette implémentation de référence est basée sur Application Gateway et le Contrôleur d’entrée Application Gateway (AGIC). Chaque cluster a sa propre passerelle applicative et le basculement du trafic s’effectue via DNS, en particulier via la configuration de CNAME.

Important

Pour les charges de travail stratégiques, il est important de combiner des déploiements bleus/verts, comme souligné dans ce guide, avec l’automatisation du déploiement et la validation continue pour obtenir des déploiements sans temps d’arrêt. Des informations et des conseils supplémentaires sont disponibles dans la méthodologie des conceptions critiques.

Aspects à prendre en compte au sujet des régions

Vous pouvez déployer les clusters bleu et vert dans des régions distinctes ou dans la même région. Ce choix n’affecte pas les principes de conception et d’exploitation. Toutefois, certains types de configurations de mise en réseau supplémentaires peuvent être affectés, par exemple :

Un réseau virtuel et un sous-réseau dédiés pour AKS et la passerelle applicative.
Connexion à des services de soutien tels que Monitor, Container Registry et Key Vault.
Visibilité de la passerelle applicative par Azure Front Door.

Il existe des conditions préalables au déploiement dans la même région :

Les réseaux virtuels et les sous-réseaux doivent être dimensionnés pour héberger deux clusters.
L’abonnement Azure doit fournir une capacité suffisante pour les deux clusters.

Déploiement du contrôleur d’entrée et des équilibreurs de charge externes

Il existe différentes approches du déploiement du contrôleur d’entrée et des équilibreurs de charge externes :

Vous pouvez avoir un unique contrôleur d’entrée avec un équilibreur de charge externe dédié, comme dans l’implémentation de référence de l’architecture décrite dans ce guide. AGIC est une application Kubernetes qui permet d’utiliser l’équilibreur de charge Application Gateway L7 pour exposer des logiciels cloud à Internet. Dans certains scénarios, il existe des points de terminaison d’administration dans les clusters AKS en plus des points de terminaison d’application. Les points de terminaison d’administration sont destinés à l’exécution de tâches opérationnelles sur les applications ou de tâches de configuration telles que la mise à jour des mappages de configuration, des secrets, des stratégies réseau et des manifestes.
Vous pouvez avoir un seul équilibreur de charge externe qui sert plusieurs contrôleurs d’entrée déployés sur le même cluster ou sur plusieurs clusters. Cette approche n’est pas couverte dans l’implémentation de référence. Dans ce scénario, nous vous recommandons de disposer de passerelles d’application distinctes pour les points de terminaison publics et privés.
L’architecture proposée et illustrée, découlant de ce guide, est basée sur un contrôleur d’entrée standard déployé en même temps que le cluster AKS, comme celles qui sont basées sur NGINX et Envoy. Dans l’implémentation de référence, nous utilisons AGIC, ce qui signifie qu’il existe une connexion directe entre la passerelle applicative et les pods AKS, mais cela n’affecte pas l’architecture bleue-verte globale.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Vincenzo Morra | Architecte Incubation SAO

Autres contributeurs :

Oscar Pla Alvarez | Architecte de solution de domaine

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Partager via

Déploiement bleu-vert de clusters AKS