Partager via


Architecture AKS sur Azure Stack HCI 23H2

S’applique à : Azure Stack HCI, version 23H2

Azure Kubernetes Service (AKS) sur Azure Stack HCI est une plateforme de conteneur Kubernetes de niveau entreprise. Il inclut Kubernetes principal pris en charge par Microsoft, un hôte de conteneur Windows spécialement conçu et un hôte de conteneur Linux pris en charge par Microsoft, avec un objectif d’avoir une expérience de déploiement et de gestion du cycle de vie simple.

Cet article présente les principaux composants de l’infrastructure Kubernetes, tels que le plan de contrôle, les nœuds et les pools de nœuds. Les ressources de charge de travail telles que les pods, les déploiements et les ensembles sont également présentées, ainsi que le regroupement de ressources dans des espaces de noms.

Architecture AKS sur Azure Stack HCI

Les clusters AKS sur Azure Stack HCI utilisent Arc Resource Bridge (également appelé appliance Arc) pour fournir le mécanisme d’orchestration et l’interface de base pour le déploiement et la gestion d’un ou plusieurs clusters AKS. Les applications conteneurisées sont déployées dans des clusters AKS.

Diagramme montrant l’architecture du cluster.

AKS Arc utilise une configuration prédéfinie pour déployer des clusters Kubernetes efficacement et avec la scalabilité à l’esprit. Une opération de déploiement crée plusieurs machines virtuelles Linux ou Windows et les joint pour créer un ou plusieurs clusters Kubernetes.

Notes

Pour améliorer la fiabilité du système, si vous exécutez plusieurs volumes partagés de cluster (CSV) dans votre cluster, par défaut, les données de machine virtuelle sont automatiquement réparties sur tous les volumes partagés de cluster disponibles dans le cluster. Cela garantit que les applications subsistent en cas de pannes de CSV.

Pont de ressources Arc

Arc Resource Bridge connecte un cloud privé (par exemple, Azure Stack HCI, VMWare/vSphere ou SCVMM) à Azure et active la gestion des ressources locales à partir d’Azure. Azure Arc Resource Bridge fournit la ligne de vue sur les clouds privés requis pour gérer des ressources telles que des clusters Kubernetes locaux via Azure. Arc Resource Bridge inclut les principaux composants AKS Arc suivants :

  • Extensions de cluster AKS Arc : une extension de cluster est l’équivalent local d’un fournisseur de ressources Azure Resource Manager. Tout comme le fournisseur de ressources Microsoft.ContainerService gère les clusters AKS dans Azure, l’extension de cluster AKS Arc, une fois ajoutée à votre pont de ressources Arc, permet de gérer les clusters Kubernetes via Azure.
  • Emplacement personnalisé : un emplacement personnalisé est l’équivalent local d’une région Azure et est une extension de la construction de l’emplacement Azure. Les emplacements personnalisés permettent aux administrateurs de locataire d’utiliser leur centre de données avec les extensions appropriées installées, en tant qu’emplacements cibles pour le déploiement d’instances de service Azure.

Clusters AKS

Les clusters AKS sont un déploiement à haute disponibilité de Kubernetes à l’aide de machines virtuelles Linux pour l’exécution des composants du plan de contrôle Kubernetes et des pools de nœuds Linux. Vous pouvez déployer des pools de nœuds Windows Server Core supplémentaires pour l’exécution de conteneurs Windows. Il peut y avoir un ou plusieurs clusters AKS gérés par Arc Resource Bridge.

Un cluster AKS a 2 composants principaux, comme décrit dans les sections suivantes.

Nœuds de plan de contrôle

Kubernetes utilise des nœuds de plan de contrôle pour garantir que chaque composant du cluster Kubernetes est conservé dans l’état souhaité. Le plan de contrôle gère et gère également les pools de nœuds Worker qui contiennent les applications conteneurisées. AKS activé par Arc déploie l’équilibreur de charge KubeVIP pour s’assurer que l’adresse IP du serveur d’API du plan de contrôle Kubernetes est disponible à tout moment. Microsoft ne vous facture pas pour les nœuds du plan de contrôle, car les nœuds du plan de contrôle n’hébergent pas les applications clientes.

Les nœuds du plan de contrôle exécutent les composants principaux suivants (liste non exhaustive) :

  • Serveur d’API : active l’interaction avec l’API Kubernetes. Ce composant fournit l’interaction pour les outils de gestion, tels qu’Azure CLI, le portail Azure ou kubectl.
  • Etcd : magasin de clé-valeur distribué qui stocke les données requises pour la gestion du cycle de vie du cluster. Il stocke l’état du plan de contrôle.

Pools de nœuds Linux/Windows

Dans Kubernetes, un pool de nœuds est un groupe de nœuds au sein d’un cluster qui partagent la même configuration. Les pools de nœuds vous permettent de créer et de gérer des ensembles de nœuds qui ont des rôles, des fonctionnalités ou des configurations matérielles spécifiques, ce qui permet un contrôle plus granulaire de l’infrastructure de votre cluster AKS. Vous pouvez déployer des pools de nœuds Linux ou Windows dans votre cluster AKS. Toutefois, vous devez disposer d’au moins 1 pool de nœuds Linux pour héberger les agents Arc afin de maintenir la connectivité avec Azure.

Déploiements de système d’exploitation mixte

Si un cluster de charge de travail donné se compose de nœuds Worker Linux et Windows, il doit être planifié sur un système d’exploitation qui peut prendre en charge l’approvisionnement de la charge de travail. Kubernetes offre deux mécanismes pour garantir le fonctionnement des charges de travail sur les nœuds avec un système d’exploitation cible :

  • Le sélecteur de nœud est un champ simple dans la spécification des pods qui limite les pods à être planifiés uniquement sur des nœuds sains correspondant au système d’exploitation.
  • Les teintes et les tolérances fonctionnent ensemble pour garantir que les pods ne sont pas planifiés sur les nœuds involontairement. Un nœud peut être « teinté » afin de ne pas accepter les pods qui ne tolèrent pas explicitement sa teinte par le biais d’une « tolérance » dans la spécification du pod.

Pour plus d’informations, consultez les sélecteurs de nœud et les teintes et tolérances.

Gestion du cycle de vie

Azure Arc est automatiquement activé sur tous vos clusters Kubernetes créés à l’aide d’AKS Arc. Vous pouvez utiliser votre ID Microsoft Entra pour vous connecter à vos clusters en tout lieu. Azure Arc vous permet d’utiliser des outils familiers comme le portail Azure, Azure CLI et les modèles Azure Resource Manager pour créer et gérer vos clusters Kubernetes.

Mises à jour cloud pour les composants d’infrastructure

Azure Stack HCI 23H2 regroupe toutes les mises à jour pertinentes pour le système d’exploitation, les agents logiciels, l’infrastructure Azure Arc et les pilotes et microprogrammes OEM dans un package de mise à jour mensuelle unifié. Ce package de mise à jour complet est identifié et appliqué à partir du cloud via l’outil Azure Update Manager.

AKS fait désormais partie d’Azure Stack HCI à partir de la version 23H2. La gestion du cycle de vie d’AKS activée par l’infrastructure Azure Arc suit la même approche que tous les autres composants sur Azure Stack HCI 23H2. Cette approche fournit une base flexible pour intégrer et gérer différents aspects de la solution Azure Stack HCI en un seul endroit, notamment la gestion du système d’exploitation, des agents et services principaux et l’extension de la solution. AKS activé par les composants d’infrastructure Arc, dans le cadre des extensions de solution, sont mis à jour par le package de mise à jour d’Azure Stack HCI 23H2.

Pour plus d’informations, consultez La vue d’ensemble des mises à jour pour Azure Stack HCI, version 23H2.

Étapes suivantes