Construire un cluster Kubernetes à haute disponibilité sur Azure Stack Hub

Cet article explique comment créer l’architecture d’une infrastructure Kubernetes à haute disponibilité et comment la faire fonctionner à l’aide du moteur Azure Kubernetes Service (AKS) sur Azure Stack Hub. La solution est basée sur un scénario qui compte un ensemble strict de contraintes. L’application doit s’exécuter localement et aucune donnée personnelle ne doit atteindre les services cloud publics. Les données de supervision et les données autres que les informations d'identification personnelle peuvent être envoyées à Azure et traitées ici. Des services externes, comme un registre de conteneurs public, sont accessibles mais peuvent être filtrés par le biais d’un pare-feu ou d’un serveur proxy.

Helm et Let’s Encrypt sont des marques déposées de leurs sociétés respectives. L’utilisation de ces marques n’implique aucune approbation.

Architecture

Téléchargez un fichier Visio de tous les diagrammes de cet article.

Workflow

Le diagramme ci-dessus montre l’architecture de l’exemple d’application s’exécutant sur Kubernetes, sur Azure Stack Hub. L’application comprend ces composants :

1. Un cluster Kubernetes, basé sur le moteur AKS, sur Azure Stack Hub.
2. cert-manager, qui fournit une suite d’outils pour la gestion des certificats dans Kubernetes. Ce composant est utilisé pour demander automatiquement des certificats à Let’s Encrypt.
3. Un espace de noms Kubernetes qui contient les composants d’application pour :
   1. le front-end (ratings-web)
   2. l’API (ratings-api)
   3. la base de données (ratings-mongodb)
4. Un contrôleur d’entrée qui route le trafic HTTP/HTTPS vers les points de terminaison au sein du cluster Kubernetes.

L’exemple d’application est utilisé pour illustrer l’architecture de l’application. Tous les composants sont des exemples. L’architecture contient un seul déploiement d’application. Pour obtenir une haute disponibilité, le déploiement s’exécute au moins deux fois sur deux instances Azure Stack Hub. Elles peuvent s’exécuter dans un emplacement unique ou sur deux sites ou plus :

Les services, comme Azure Container Registry et Azure Monitor, sont hébergés en dehors d’Azure Stack Hub dans Azure ou localement. Cette conception hybride protège la solution contre les pannes d’une instance Azure Stack Hub unique.

Composants

• Azure Stack Hub est une extension d’Azure qui peut exécuter des charges de travail dans un environnement local en fournissant des services Azure dans votre centre de données.
• AKS Engine pour Azure Stack fournit un outil en ligne de commande pour faciliter le provisionnement d’un cluster Kubernetes auto-managé sur Azure Stack Hub. Il utilise Azure Resource Manager pour créer, détruire et maintenir des clusters approvisionnés avec des ressources IaaS de base dans Azure Stack Hub.
• Le service Réseau virtuel fournit l’infrastructure réseau sur chaque instance Azure Stack Hub pour les machines virtuelles qui hébergent l’infrastructure de cluster Kubernetes.
• Azure Load Balancer est utilisé pour le point de terminaison de l’API Kubernetes et le contrôleur d’entrée Nginx. L’équilibreur de charge route le trafic externe (par exemple, Internet) vers les nœuds et les machines virtuelles qui fournissent un service spécifique.
• Container Registry est utilisé pour stocker des images Docker privées et des charts Helm qui sont déployés sur le cluster. Le moteur AKS peut s’authentifier avec le registre de conteneurs en utilisant une identité Microsoft Entra. Kubernetes ne nécessite pas Container Registry. Vous pouvez utiliser d’autres registres de conteneurs, comme Docker Hub.
• Azure Repos est un ensemble d’outils de gestion de versions que vous pouvez utiliser pour gérer votre code. Vous pouvez également utiliser GitHub ou d’autres dépôts Git.
• Azure Pipelines fait partie d’Azure DevOps Services. Il exécute des builds, des tests et des déploiements automatisés. Vous pouvez également utiliser des solutions CI/CD tierces comme Jenkins.
• Azure Monitor recueille et stocke les métriques et journaux d’activité, notamment les métriques de plateforme pour les services Azure dans les données de télémétrie d’application et de solution. Utilisez ces données pour superviser l’application, définir des alertes et des tableaux de bord et effectuer une analyse de la cause racine des échecs. Azure Monitor s’intègre à Kubernetes pour collecter des métriques auprès des contrôleurs, nœuds, conteneurs, journaux d’activité des conteneurs et journaux d’activité des nœuds de plan de contrôle.
• Azure Traffic Manager est un équilibreur de charge du trafic DNS que vous pouvez utiliser pour distribuer le trafic de façon optimale aux services entre différentes régions Azure ou entre différents déploiements Azure Stack Hub. Traffic Manager offre également une haute disponibilité et une haute réactivité. Les points de terminaison d’application doivent être accessibles à partir de l’extérieur pour être ajoutés en tant que tels à Azure Traffic Manager.
• Un contrôleur d’entrée Kubernetes expose les routes HTTP(S) aux services dans un cluster Kubernetes. Vous pouvez utiliser NGINX ou tout contrôleur d’entrée approprié.
• Helm est un gestionnaire de package pour déploiement Kubernetes. Il permet de regrouper différents objets Kubernetes, comme Deployments, Services et Secrets, dans un seul « chart ». Vous pouvez publier, déployer, versionner et mettre à jour un objet de chart. Vous pouvez utiliser Container Registry comme référentiel pour stocker les charts Helm empaquetés.

Autres solutions

Azure Traffic Manager fait partie des choix possibles pour distribuer le trafic entre deux points de terminaison accessibles par l’Internet. D’autres solutions d’équilibrage de charge peuvent également être utilisées pour distribuer le trafic entre les instances Azure Stack Hub. Il peut arriver que les points de terminaison d’application hébergés dans Azure Stack Hub doivent être limités à votre réseau privé. Dans de tels cas, on peut utiliser des équilibreurs de charge tiers pour équilibrer le trafic entre les instances d’Azure Stack Hub au sein de votre réseau, qu’elles soient situées dans un même centre de données ou déployées dans plusieurs centres de données.

Détails du scénario

L’exemple d’application présenté ici est conçu pour utiliser des solutions natives Kubernetes plutôt que des services natifs de plateforme chaque fois que c’est possible. Cette conception évite toute situation de monopole des fournisseurs. Par exemple, l’application utilise un back-end de base de données MongoDB auto-hébergé au lieu d’un service PaaS ou d’un service de base de données externe. Pour plus d’informations, consultez le parcours d’apprentissage Présentation de Kubernetes sur Azure.

Cas d’usage potentiels

De nombreuses organisations développent des solutions cloud natives qui tirent parti de services et de technologies de pointe, comme Kubernetes. Bien qu’Azure fournisse des centres de données dans la plupart des régions du monde, certaines applications vitales pour l’entreprise doivent parfois s’exécuter à un emplacement particulier. Les préoccupations éventuelles sont les suivantes :

• Sensibilité de l’emplacement.
• Latence entre l’application et les systèmes locaux.
• Conservation de la bande passante.
• Connectivité.
• Obligations réglementaires ou statutaires.

Azure, en combinaison avec Azure Stack Hub, répond à la plupart de ces préoccupations. Cet article fournit un large ensemble d’options, de décisions et de considérations pour vous aider à concevoir une architecture de solutions hautement disponibles basées sur Kubernetes sur Azure Stack Hub.

Le scénario décrit ici est courant pour les organisations qui ont des charges de travail critiques dans des environnements hautement confidentiels et réglementés. Il est applicable dans des domaines comme la finance, la défense et le secteur public.

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.

Conception

Cette solution intègre quelques recommandations générales décrites plus en détail dans les sections ultérieures de cet article :

• Pour éviter les situations de monopole des fournisseurs, l’application utilise des solutions natives Kubernetes.
• L’application utilise une architecture de microservices.
• Azure Stack Hub n’a pas besoin de connectivité Internet entrante. Mais il autorise la connectivité Internet sortante.

Ces pratiques recommandées s’appliquent également aux charges de travail et aux scénarios réels.

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é.

La scalabilité permet de fournir un accès cohérent, fiable et performant à l’application.

L’exemple de scénario implémente la scalabilité dans trois couches de la pile d’applications. Voici une vue d’ensemble des couches :

Niveau architecture	Éléments affectés	Comment faire ?
Application	Application	Mise à l’échelle horizontale en fonction du nombre de pods/réplicas/instances de conteneur.*
Cluster	Cluster Kubernetes	Nombre de nœuds (entre 1 et 50), tailles de référence SKU de machine virtuelle et, par le biais de la commande manuelle scale du moteur AKS, pools de nœuds.
Infrastructure	Azure Stack Hub	Nombre de nœuds, capacité et unités d’échelle au sein d’un déploiement Azure Stack Hub.

* Par le biais de HorizontalPodAutoscaler de Kubernetes, qui fournit une mise à l’échelle automatique basée sur des métriques ou une mise à l’échelle verticale en redimensionnant les instances de conteneur (processeur ou mémoire).

Azure Stack Hub (niveau infrastructure)

Étant donné qu’Azure Stack Hub s’exécute sur du matériel physique dans un centre de données, l’infrastructure Azure Stack Hub est la base de cette implémentation. Quand vous choisissez le matériel de votre hub, vous devez faire des choix pour le processeur, la densité de la mémoire, la configuration du stockage et le nombre de serveurs. Pour en savoir plus sur la scalabilité d’Azure Stack Hub, consultez ces ressources :

• Vue d’ensemble de la planification de la capacité pour Azure Stack Hub
• Ajouter des nœuds d’unité d’échelle dans Azure Stack Hub

Cluster Kubernetes (niveau cluster)

Le cluster Kubernetes lui-même est constitué de composants IaaS Azure Stack Hub et Azure sur lesquels il s’appuie, notamment des ressources de calcul, de stockage et réseau. Les solutions Kubernetes sont composées de nœuds de plan de contrôle et de nœuds Worker, qui sont déployés en tant que machines virtuelles dans Azure et Azure Stack Hub.

• Les nœuds de plan de contrôle fournissent les services Kubernetes de base et l’orchestration des charges de travail d’application.
• Les nœuds Worker exécutent vos charges de travail d’application.

Quand vous choisissez des tailles de machine virtuelle pour votre déploiement initial, prenez en compte les points suivants :

• Coût. Quand vous planifiez vos nœuds Worker, tenez compte du coût global par machine virtuelle. Par exemple, si vos charges de travail d’application nécessitent des ressources limitées, vous devez prévoir de déployer des machines virtuelles plus petites. Azure Stack Hub, comme Azure, est normalement facturé en fonction de la consommation : un dimensionnement approprié des machines virtuelles pour les rôles Kubernetes est donc crucial pour optimiser les coûts de la consommation.

• Scalabilité. Vous obtenez la scalabilité du cluster en effectuant un scale-in et un scale-out du nombre de nœuds de plan de contrôle et Worker, ou en ajoutant des pools de nœuds. (Vous ne pouvez actuellement pas ajouter de pools de nœuds sur Azure Stack Hub.) Vous pouvez mettre à l’échelle le cluster en fonction des données de performances collectées avec Container Insights (Azure Monitor et Log Analytics).

  Si votre application a besoin de plus ou de moins de ressources, vous pouvez effectuer un scale-out ou un scale-in horizontal du nombre de nœuds, entre 1 et 50 nœuds. Si vous avez besoin de plus de 50 nœuds, vous pouvez créer un autre cluster dans un abonnement distinct. Vous ne pouvez effectuer un scale-up vertical des machines virtuelles réelles vers une autre taille de machine virtuelle sans redéployer le cluster.

  Implémentez la mise à l’échelle manuellement à l’aide de la machine virtuelle d’assistance du moteur AKS que vous avez utilisée pour déployer le cluster Kubernetes. Pour plus d’informations, consultez Mise à l’échelle des clusters Kubernetes.

• Quotas. Considérez les quotas que vous avez configurés quand vous planifiez un déploiement AKS sur Azure Stack Hub. Vérifiez que chaque abonnement dispose des plans et des quotas appropriés configurés. L’abonnement va devoir prendre en charge la quantité de calcul, de stockage et d’autres services nécessaires à vos clusters au fur et à mesure de leur scale-out.

• Charges de travail d’application. Consultez les concepts des clusters et des charges de travail dans l’article Concepts de base de Kubernetes pour Azure Kubernetes Service. Cet article peut vous aider à étendre la taille de votre machine virtuelle en fonction des besoins en calcul et en mémoire de votre application.

Application (niveau application)

Sur la couche Application, la solution utilise l’objet HorizontalPodAutoscaler de Kubernetes. L’objet HorizontalPodAutoscaler peut augmenter ou diminuer le nombre de réplicas (pods/instances de conteneur) dans le déploiement en fonction de différentes métriques, comme l’utilisation du processeur.

Une autre option est de mettre à l’échelle verticalement les instances de conteneur. Vous pouvez effectuer ce type de mise à l’échelle en modifiant la quantité de processeur et de mémoire demandée et disponible pour un déploiement spécifique. Pour plus d’informations, consultez Gestion des ressources pour les conteneurs.

Mise en réseau et connectivité

La mise en réseau et la connectivité affectent également les trois couches décrites précédemment. Le tableau suivant montre les couches et les services qu’elles contiennent.

Couche	Éléments affectés	Quoi ?
Application	Application	Manière d’accéder à l’application. Si elle est exposée à Internet ou non.
Cluster	Cluster Kubernetes	API Kubernetes, machine virtuelle du moteur AKS, extraction d’images conteneur (sortie), envoi des données de monitoring et de télémétrie (sortie).
Infrastructure	Azure Stack Hub	Accessibilité des points de terminaison de gestion Azure Stack Hub, comme le portail et les points de terminaison Azure Resource Manager.

Application

Sur la couche Application, la considération la plus importante est de savoir si l’application est exposée à Internet et accessible depuis Internet. Du point de vue de Kubernetes, l’accessibilité Internet exige l’exposition d’un déploiement ou d’un pod en utilisant un service Kubernetes ou un contrôleur d’entrée.

Une application peut être exposée avec une adresse IP publique par le biais d’un équilibreur de charge ou d’un contrôleur d’entrée sans être accessible par le biais d’Internet. Azure Stack Hub peut avoir une adresse IP publique visible uniquement sur l’intranet local. Toutes les adresses IP publiques ne sont pas vraiment accessibles sur Internet.

Outre le trafic d’entrée vers l’application, vous devez également prendre en compte le trafic sortant (ou de sortie). Voici quelques cas d’utilisation qui nécessitent un trafic sortant :

• Extraction d’images conteneur stockées dans Docker Hub ou Container Registry
• Récupération de charts Helm
• Émission de données Application Insights ou d’autres données de monitoring
• Connexion à des applications externes

Certains environnements d’entreprise peuvent nécessiter l’utilisation de serveurs proxy transparents ou non transparents. Ces serveurs nécessitent une configuration spécifique sur les différents composants du cluster. La documentation du moteur AKS contient des informations détaillées sur la prise en charge des proxys réseau. Pour plus d’informations, consultez Moteur AKS et serveurs proxy.

Enfin, un trafic entre les clusters doit circuler entre les instances Azure Stack Hub. La solution décrite ici se compose de clusters Kubernetes individuels qui s’exécutent sur des instances Azure Stack Hub individuelles. Le trafic entre ces instances, par exemple le trafic de réplication entre deux bases de données, est considéré comme du trafic externe. Le trafic externe doit être acheminé par le biais d’un VPN site à site ou d’adresses IP publiques Azure Stack Hub. Le VPN site à site offre une sécurité accrue pour les transferts de données et doit être privilégié.

Cluster

Le cluster Kubernetes n’a pas nécessairement besoin d’être accessible par Internet. La partie pertinente est l’API Kubernetes qui est utilisée pour faire fonctionner un cluster, par exemple, par le biais de kubectl. Toute personne qui fait fonctionner le cluster ou qui déploie des applications et des services sur celui-ci doit être capable d’accéder au point de terminaison de l’API Kubernetes. Ce sujet est traité plus en détail du point de vue de DevOps dans la section Déploiement (CI/CD) de cet article.

Au niveau du cluster, quelques points sont également à prendre en considération pour le trafic sortant :

• Mises à jour des nœuds (pour Ubuntu)
• Données de monitoring (envoyées à Log Analytics)
• Autres agents nécessitant un trafic sortant (propres à l’environnement de chaque utilisateur effectuant un déploiement)

Avant de déployer votre cluster Kubernetes en utilisant le moteur AKS, planifiez la conception finale de la mise en réseau. Il peut s’avérer plus efficace de déployer un cluster dans un réseau existant, au lieu de créer un réseau virtuel dédié. Par exemple, vous pouvez utiliser une connexion VPN site à site existante qui est déjà configurée dans votre environnement Azure Stack Hub.

Infrastructure

L’infrastructure fait référence à l’accès aux points de terminaison de gestion d’Azure Stack Hub. Les points de terminaison incluent les portails de locataire et d’administration, ainsi que les points de terminaison d’administration et de locataire de Resource Manager. Ces points de terminaison sont nécessaires pour utiliser Azure Stack Hub et ses services de base.

Données et stockage

Deux instances de l’application sont déployées sur deux clusters Kubernetes individuels, sur deux instances Azure Stack Hub. Pour cette conception, vous avez besoin de réfléchir à la façon de répliquer et de synchroniser les données entre les instances.

Azure fournit la capacité intégrée de répliquer le stockage entre plusieurs régions et zones au sein du cloud. Actuellement, il n’existe aucun moyen natif de répliquer le stockage sur deux instances Azure Stack Hub. Elles forment deux clouds indépendants et il n’existe aucun moyen global de les gérer comme un tout. Quand vous planifiez la résilience des applications qui s’exécutent sur Azure Stack Hub, prenez en compte cette indépendance dans la conception et les déploiements de votre application.

Dans la plupart des cas, la réplication du stockage n’est pas nécessaire pour une application résiliente et à haute disponibilité déployée sur AKS. Vous devez cependant envisager un stockage indépendant par instance Azure Stack Hub dans la conception de votre application. Si cette conception pose problème, envisagez les solutions d’attachement de stockage offertes par les partenaires Microsoft. Les attachements de stockage fournissent une solution de réplication du stockage entre plusieurs instances Azure Stack Hub et Azure. Pour plus d’informations, consultez la section Solutions de partenaires dans cet article.

Cette architecture prend ces éléments en considération :

Configuration

Cette catégorie comprend la configuration d’Azure Stack Hub, du moteur AKS et du cluster Kubernetes lui-même. Vous avez intérêt à automatiser la configuration autant que possible et à la stocker sous forme d’infrastructure en tant que code dans un système de gestion de version basé sur Git, comme Azure DevOps ou GitHub. Vous ne pouvez pas synchroniser facilement ces paramètres entre plusieurs déploiements. Nous vous recommandons de stocker et d’appliquer la configuration depuis l’extérieur, et d’utiliser un pipeline DevOps.

Application

Vous devez stocker l’application dans un dépôt basé sur Git. Ce faisant, chaque fois qu’il y a un nouveau déploiement, des modifications apportées à l’application ou une reprise d’activité après sinistre, vous pouvez déployer facilement l’application en utilisant Azure Pipelines.

Données

La question des données est ce qu’il y a de plus important à considérer dans la plupart des conceptions d’application. Les données d’application doivent rester synchronisées entre les différentes instances de l’application. Vous avez également besoin d’une stratégie de sauvegarde et de reprise d’activité pour les données en cas de panne.

Si vous utilisez des données réparties sur plusieurs emplacements, l’implémentation d’une solution à haut niveau de disponibilité et résiliente est encore plus complexe. Considérez les aspects suivants :

• Latence et connectivité réseau entre les instances Azure Stack Hub.
• Disponibilité des identités pour les services et les autorisations. Chaque instance Azure Stack Hub s’intègre à un annuaire externe. Pendant le déploiement, vous choisissez d’utiliser Microsoft Entra ID ou les services de fédération Active Directory (AD FS). Ainsi, vous avez la possibilité d’utiliser une seule identité capable d’interagir avec plusieurs instances Azure Stack Hub indépendantes.

Continuité d’activité et reprise d’activité

La continuité d’activité et la reprise d’activité (BCDR) sont une considération importante à la fois pour Azure Stack Hub et Azure. La principale différence est que, pour Azure Stack Hub, l’opérateur doit gérer l’ensemble du processus BCDR. Pour Azure, les parties BCDR sont automatiquement gérés par Microsoft.

BCDR affecte les mêmes points que ceux abordés dans la section précédente :

• Infrastructure et configuration
• Disponibilité de l’application
• Données d'application

Ces points relèvent de la responsabilité de l’opérateur Azure Stack Hub. Les détails peuvent varier en fonction de l’organisation. Planifiez le BCDR en fonction de vos outils et processus disponibles.

Infrastructure et configuration

Cette section traite de l’infrastructure physique et logique, et de la configuration d’Azure Stack Hub. Elle couvre les actions dans les espaces du locataire et de l’administrateur.

L’opérateur (ou l’administrateur) Azure Stack Hub est responsable de la maintenance des instances Azure Stack Hub, qui inclut le réseau, le stockage, l’identité et d’autres éléments qui sortent du champ de cet article. Pour plus d’informations sur les spécificités des opérations Azure Stack Hub, consultez ces ressources :

• Récupérer des données dans Azure Stack Hub avec le service Infrastructure Backup
• Activer la sauvegarde d’Azure Stack Hub à partir du portail administrateur
• Récupérer des données suite à une perte catastrophique
• Meilleures pratiques concernant le service de sauvegarde de l’infrastructure

Azure Stack Hub est la plateforme et la structure sur lesquelles les applications Kubernetes sont déployées. Le propriétaire de l’application Kubernetes est un utilisateur d’Azure Stack Hub, doté de l’accès requis pour déployer l’infrastructure d’application nécessaire pour la solution. Dans ce cas, l’infrastructure d’application correspond au cluster Kubernetes, déployé en utilisant le moteur AKS, et aux services environnants.

Ces composants sont déployés dans Azure Stack Hub. Les composants sont limités par l’offre Azure Stack Hub. Vérifiez que l’offre acceptée par le propriétaire de l’application Kubernetes a une capacité suffisante, exprimée en quotas Azure Stack Hub, pour déployer l’ensemble de la solution. Comme nous l’avons recommandé dans la section précédente, vous avez tout intérêt à automatiser le déploiement de l’application en utilisant une infrastructure en tant que code et des pipelines de déploiement comme Azure Pipelines.

Pour plus d’informations sur les offres et les quotas Azure Stack Hub, consultez Vue d’ensemble des services, plans, offres et abonnements Azure Stack Hub.

Il est important d’enregistrer et de stocker de façon sécurisée la configuration du moteur AKS, y compris ses sorties. Ces fichiers contiennent des informations confidentielles utilisées pour accéder au cluster Kubernetes : ils doivent donc être protégés d’une exposition à des non-administrateurs.

Disponibilité de l’application

L’application ne doit pas s’appuyer sur les sauvegardes d’une instance déployée. À titre de pratique standard, redéployez complètement l’application en suivant les modèles d’infrastructure en tant que code. Par exemple, redéployez en utilisant Azure Pipelines. La procédure BCDR doit impliquer le redéploiement de l’application sur le même cluster Kubernetes ou sur un autre.

Données d'application

Les données d’application forment le composant critique de BCDR. Les sections précédentes décrivent les techniques de réplication et de synchronisation des données entre deux instances ou plus d’une application. Selon l’infrastructure de base de données (comme MySQL, MongoDB ou SQL Server) utilisée pour stocker les données, différentes techniques de sauvegarde et de disponibilité de base de données sont disponibles.

Pour atteindre l’intégrité, nous vous recommandons d’utiliser l’une des solutions suivantes :

• Une solution de sauvegarde native pour la base de données spécifique.
• Une solution de sauvegarde qui prend en charge la sauvegarde et la récupération du type de base de données utilisé par votre application.

Disponibilité

Kubernetes sur Azure Stack Hub, déployé par le biais du moteur AKS, n’est pas un service managé. Il s’agit d’un déploiement et d’une configuration automatisés d’un cluster Kubernetes qui utilise Azure IaaS (Infrastructure-as-a-Service). Ainsi, il offre la même disponibilité que l’infrastructure sous-jacente.

L’infrastructure Azure Stack Hub est déjà résiliente aux défaillances et elle fournit des fonctionnalités comme des groupes à haute disponibilité pour distribuer des composants sur plusieurs domaines d’erreur et de mise à jour. La technologie sous-jacente (clustering de basculement) implique néanmoins toujours un temps d’arrêt pour les machines virtuelles qui se trouvent sur un serveur physique affecté, en cas de défaillance matérielle.

C’est une bonne pratique que de déployer votre cluster Kubernetes de production, ainsi que la charge de travail, sur deux clusters ou plus. Ces clusters doivent être hébergés à des emplacements ou dans des centres de données différents, et utiliser des technologies comme Traffic Manager pour router les utilisateurs en fonction du temps de réponse du cluster ou de la zone géographique.

Les clients qui ont un seul cluster Kubernetes se connectent généralement à l’adresse IP du service ou au nom DNS d’une application donnée. Dans un déploiement impliquant plusieurs clusters, les clients doivent se connecter à un nom DNS de Traffic Manager qui pointe vers les services/entrées sur chaque cluster Kubernetes.

Le cluster Kubernetes lui-même, déployé par le biais du moteur AKS, doit comprendre au moins trois nœuds de plan de contrôle et deux nœuds Worker.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

La sécurité et l’identité s’avèrent particulièrement importantes quand la solution s’étend sur des instances Azure Stack Hub indépendantes. Kubernetes et Azure, Azure Stack Hub compris, ont des mécanismes distincts pour le contrôle d’accès en fonction du rôle (RBAC) :

• RBAC Azure contrôle l’accès à Azure et Azure Stack Hub, y compris la possibilité de créer des ressources Azure. Ces autorisations peuvent être assignées aux utilisateurs, groupes ou principaux de service. (Un principal de service est une identité de sécurité utilisée par les applications.)
• Kubernetes RBAC contrôle les autorisations sur l’API Kubernetes. Par exemple, la création de pods et le listage de pods sont des actions qui peuvent être accordées ou refusées à un utilisateur par le biais du RBAC. Pour affecter des autorisations Kubernetes à des utilisateurs, vous créez des rôles et des liaisons de rôle.

Identité Azure Stack Hub et RBAC

Azure Stack Hub offre deux choix de fournisseur d’identité. Le fournisseur que vous utilisez dépend de l’environnement et de l’exécution dans un environnement connecté ou déconnecté :

• Microsoft Entra ID peut uniquement être utilisé dans un environnement connecté.
• Les services de fédération Active Directory (AD FS) vers une forêt Active Directory traditionnelle peuvent être utilisés dans un environnement connecté ou déconnecté.

Le fournisseur d’identité gère les utilisateurs et les groupes, y compris l’authentification et l’autorisation pour accéder aux ressources. L’accès peut être accordé à des ressources Azure Stack Hub, comme des abonnements, des groupes de ressources et des ressources individuelles, par exemple des machines virtuelles et des équilibreurs de charge. Par souci de cohérence, envisagez d’utiliser les mêmes groupes, directs ou imbriqués, pour toutes les instances Azure Stack Hub. Voici un exemple de configuration :

Cet exemple contient un groupe dédié (qui utilise Microsoft Entra ID ou AD FS) dans un but spécifique, par exemple, pour fournir des autorisations de contributeur au groupe de ressources qui contient l’infrastructure du cluster Kubernetes sur une instance Azure Stack Hub spécifique (ici, « Contributeur de cluster Seattle K8s »). Ces groupes sont ensuite imbriqués dans un groupe global qui contient les sous-groupes de chaque instance Azure Stack Hub.

L’utilisateur donné en exemple dispose maintenant des autorisations de contributeur sur les deux groupes de ressources qui contiennent l’ensemble des ressources de l’infrastructure Kubernetes. L’utilisateur a accès aux ressources sur les deux instances Azure Stack Hub, car les instances partagent le même fournisseur d’identité.

Identité Kubernetes et RBAC

Par défaut, un cluster Kubernetes n’utilise pas le même fournisseur d’identité que l’instance Azure Stack Hub sous-jacente. Les machines virtuelles qui hébergent le cluster Kubernetes, le plan de contrôle et les nœuds Worker utilisent la clé SSH spécifiée lors du déploiement du cluster. Cette clé SSH est nécessaire pour la connexion à ces nœuds par le biais de SSH.

L’API Kubernetes (accessible, par exemple, par le biais de kubectl) est également protégée par les comptes de service, y compris un compte de service administrateur de cluster par défaut. Les informations d’identification de ce compte de service sont initialement stockées dans le fichier .kube/config sur vos nœuds de plan de contrôle Kubernetes.

Gestion des secrets et informations d’identification d’application

Plusieurs possibilités s’offrent à vous pour stocker des secrets comme des chaînes de connexion et des informations d’identification de base de données, à savoir :

• Azure Key Vault
• Secrets Kubernetes
• Solutions tierces, comme HashiCorp Vault (qui s’exécute sur Kubernetes)

Ne stockez pas les secrets ou les informations d’identification en texte clair dans vos fichiers de configuration, dans votre code d’application ou dans des scripts. Ne les stockez pas non plus dans un système de gestion de version. Au lieu de cela, l’automatisation du déploiement doit récupérer les secrets en fonction des besoins.

Mise à jour corrective et mise à niveau

Le processus de mise à jour corrective et de mise à niveau dans AKS est partiellement automatisé. Les mises à niveau des versions de Kubernetes sont déclenchées manuellement, tandis que les mises à jour de sécurité sont appliquées automatiquement. Ces mises à jour incluent des correctifs de sécurité ou des mises à jour du noyau du système d’exploitation. AKS ne redémarre pas automatiquement les nœuds Linux pour terminer le processus de mise à jour.

Le processus de mise à jour corrective et de mise à niveau d’un cluster Kubernetes déployé par le biais du moteur AKS sur Azure Stack Hub est non managé. Il incombe à l’opérateur du cluster.

Le moteur AKS facilite les deux tâches les plus importantes :

• Mettre à niveau vers une version plus récente de Kubernetes et de l’image du système d’exploitation de base
• Mettre à niveau l’image du système d’exploitation de base uniquement

Les images de système d’exploitation de base plus récentes contiennent les derniers correctifs de sécurité et les dernières mises à jour du noyau du système d’exploitation.

L’utilitaire de mise à niveau sans assistance installe automatiquement les mises à jour de sécurité publiées avant qu’une nouvelle version de l’image du système d’exploitation de base ne soit disponible sur la Place de marché Azure Stack Hub. La mise à niveau sans assistance est activée par défaut et installe automatiquement les mises à jour de sécurité, mais elle ne redémarre pas les nœuds du cluster Kubernetes. Vous pouvez automatiser le redémarrage du nœud à l’aide du démon de redémarrage Kubernetes (kured) open source. Le démon kured surveille les nœuds Linux qui nécessitent un redémarrage, puis gère automatiquement la replanification de l’exécution des pods et le processus de redémarrage des nœuds.

Déploiement (CI/CD)

Azure et Azure Stack Hub exposent les mêmes API REST Resource Manager. Vous traitez ces API comme vous le feriez sur n’importe quelle autre plateforme cloud Azure (Azure, Azure China 21Vianet, Azure Government). Les différentes plateformes cloud peuvent utiliser différentes versions d’API et Azure Stack Hub fournit uniquement un sous-ensemble de services. L’URI du point de terminaison de gestion diffère également pour chaque plateforme cloud et pour chaque instance Azure Stack Hub.

Hormis les subtiles différences mentionnées, les API REST Resource Manager offrent un moyen cohérent d’interagir avec Azure et Azure Stack Hub. Vous pouvez utiliser ici le même ensemble d’outils qu’avec n’importe quelle autre plateforme cloud Azure. Vous pouvez utiliser Azure DevOps, des outils comme Jenkins ou PowerShell pour déployer et orchestrer des services sur Azure Stack Hub.

Considérations

Une des différences majeures pour les déploiements d’Azure Stack Hub a trait à l’implémentation de l’accessibilité à Internet. L’accessibilité à Internet détermine s’il faut sélectionner un agent de build hébergé par Microsoft ou auto-hébergé pour vos travaux CI/CD.

Un agent auto-hébergé peut s’exécuter sur Azure Stack Hub (en tant que machine virtuelle IaaS) ou dans le sous-réseau d’un réseau qui peut accéder à Azure Stack Hub. Pour plus d’informations sur les différences, consultez Agents Azure Pipelines.

L’organigramme suivant peut vous aider à déterminer si vous avez besoin d’un agent de build auto-hébergé ou hébergé par Microsoft :

• Les points de terminaison de gestion Azure Stack Hub peuvent-ils être accessibles par Internet ?
  • Oui : Vous pouvez utiliser Azure Pipelines avec des agents hébergés par Microsoft pour vous connecter à Azure Stack Hub.
  • Non : Vous avez besoin d’agents auto-hébergés capables de se connecter aux points de terminaison de gestion Azure Stack Hub.
• Le cluster Kubernetes est-il accessible par Internet ?
  • Oui : Vous pouvez utiliser Azure Pipelines avec des agents hébergés par Microsoft pour interagir directement avec le point de terminaison de l’API Kubernetes.
  • Non : Vous avez besoin d’agents auto-hébergés capables de se connecter au point de terminaison de l’API du cluster Kubernetes.

Si les points de terminaison de gestion d’Azure Stack Hub et l’API Kubernetes sont accessibles par Internet, le déploiement peut utiliser un agent hébergé par Microsoft. Ce déploiement aboutit à l’architecture d’application suivante :

Si les points de terminaison Resource Manager, l’API Kubernetes ou les deux ne sont pas accessibles directement par Internet, vous pouvez utiliser un agent de build auto-hébergé pour exécuter les étapes du pipeline. Cette conception nécessite moins de connectivité. Elle peut être déployée avec une connectivité réseau locale uniquement aux points de terminaison Resource Manager et à l’API Kubernetes :

La solution peut utiliser un cluster Kubernetes, déployé et orchestrée avec le moteur AKS, sur chaque instance Azure Stack Hub. Elle inclut une application composée d’un front-end, d’un niveau intermédiaire, de services back-end (par exemple, MongoDB) et d’un contrôleur d’entrée basé sur NGINX. Au lieu d’utiliser une base de données hébergée sur le cluster Kubernetes, vous pouvez utiliser des magasins de données externes. Les options de base de données incluent MySQL, SQL Server ou tout type de base de données hébergé en dehors d’Azure Stack Hub ou dans IaaS. Ces configurations sortent du champ de cet article.

Solutions de partenaires

Vous pouvez utiliser des solutions de partenaires Microsoft pour étendre les fonctionnalités d’Azure Stack Hub. Ces solutions peuvent s’avérer utiles dans les déploiements d’applications qui s’exécutent sur des clusters Kubernetes.

Solutions de stockage et de données

Comme indiqué précédemment, contrairement à Azure, Azure Stack Hub ne dispose actuellement d’aucune solution native pour répliquer le stockage sur plusieurs instances. Dans Azure Stack Hub, chaque instance est son propre cloud distinct. Vous pouvez, néanmoins, obtenir des solutions auprès de partenaires Microsoft, qui permettent de répliquer le stockage sur des instances Azure Stack Hub et Azure :

• Scality fournit un stockage à l’échelle du web. Le stockage défini par logiciel Scality RING transforme des serveurs x86 en un pool de stockage illimité pour n’importe quel type de données à l’échelle du pétaoctet.
• Cloudian offre un stockage évolutif et sans limite qui regroupe des jeux de données massifs dans un seul environnement.

Étapes suivantes

• Vue d’ensemble d’Azure Stack Hub
• Vue d’ensemble d’Azure Repos
• Vue d’ensemble d’Azure Pipelines
• Vue d’ensemble d’Azure Monitor
• Mise à l’échelle multicloud dans Azure Stack Hub
• Modèles d’application géodistribuée dans Azure Stack Hub
• Formation : Azure Stack Hub

Ressources associées

• Architecture des microservices sur AKS (Azure Kubernetes Service)
• Guide de déploiement d’un cluster Kubernetes à haute disponibilité