Architecture et charges de travail de cluster Kubernetes pour AKS activées par Azure Arc
S’applique à : AKS sur Azure Stack HCI 22H2, AKS sur Windows Server
Azure Kubernetes Service (AKS) sur Azure Local et Windows Server est une plateforme de conteneur Kubernetes de niveau entreprise optimisée par Azure Local. Elle inclut la plateforme Kubernetes de base prise 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 afin d’offrir une expérience simple de déploiement et de gestion du cycle de vie.
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 d’un cluster Kubernetes
Kubernetes est le composant principal d’AKS activé par Azure Arc. AKS utilise un ensemble de configurations prédéfinies pour déployer efficacement des clusters Kubernetes et avec une scalabilité à l’esprit.
L’opération de déploiement crée plusieurs machines virtuelles Linux ou Windows et les joint pour créer des clusters Kubernetes.
Remarque
Pour améliorer la fiabilité du système, si vous exécutez plusieurs volumes partagés de cluster (CSV) dans votre cluster, les données de machine virtuelle par défaut sont réparties automatiquement sur tous les CSV disponibles dans le cluster. Cela garantit que les applications subsistent en cas de pannes de CSV. Cela s’applique uniquement aux nouvelles installations (pas aux mises à niveau).
Le système déployé est prêt à recevoir des charges de travail Kubernetes standard, mettre à l’échelle ces charges de travail, voire mettre à l’échelle le nombre de machines virtuelles, ainsi qu’augmenter et réduire le nombre de clusters en fonction des besoins.
Un cluster Azure Kubernetes Service comprend les composants suivants :
- Le cluster de gestion (également appelé hôte AKS) fournit le mécanisme d’orchestration et l’interface de base pour le déploiement et la gestion d’un ou plusieurs clusters de charge de travail.
- Les clusters de charge de travail (également appelés clusters cibles) sont les emplacements où les applications conteneurisées sont déployées.
Gérer AKS activé par Arc
Vous pouvez gérer AKS à l’aide des options de gestion suivantes :
- Windows Admin Center offre une interface utilisateur intuitive pour l’opérateur Kubernetes afin de gérer le cycle de vie des clusters.
- Un module PowerShell facilite le téléchargement, la configuration et le déploiement d’AKS. Le module PowerShell prend également en charge le déploiement et la configuration d’autres clusters de charge de travail, ainsi que la reconfiguration de clusters de charge de travail existants.
Le cluster de gestion
Lorsque vous créez un cluster Kubernetes, un cluster de gestion est automatiquement créé et configuré. Ce cluster de gestion est chargé du provisionnement et de la gestion des clusters de charge de travail sur lesquels les charges de travail s’exécutent. Un cluster de gestion inclut les composants Kubernetes principaux suivants :
- Serveur d’API : le serveur d’API est la façon dont les API Kubernetes sous-jacentes sont exposées. Ce composant fournit l’interaction des outils de gestion, tels que Windows Admin Center, les modules PowerShell ou
kubectl. - Équilibreur de charge : l’équilibreur de charge est une machine virtuelle Linux dédiée unique avec une règle d’équilibrage de charge pour le serveur d’API du cluster de gestion.
Le cluster de charge de travail
Le cluster de charge de travail est un déploiement à haute disponibilité de Kubernetes utilisant des machines virtuelles Linux pour l’exécution des composants de plan de contrôle Kubernetes, ainsi que des nœuds Worker Linux. Les machines virtuelles Windows Server Core sont utilisées pour établir des nœuds Worker Windows. Un ou plusieurs clusters de charge de travail peuvent être gérés par un même cluster de gestion.
Composants du cluster de charge de travail
Le cluster de charge de travail inclut de nombreux composants, qui sont décrits dans les sections suivantes.
Plan de contrôle
- Serveur d’API : le serveur d’API autorise l’interaction avec l’API Kubernetes. Ce composant fournit l’interaction des outils de gestion, tels que Windows Admin Center, les modules PowerShell ou
kubectl. - Etcd : Etcd est un magasin de clés-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.
Équilibreur de charge
L’équilibreur de charge est une machine virtuelle exécutant Linux et HAProxy + KeepAlive pour fournir des services à charge équilibrée pour les clusters de charge de travail déployés par le cluster de gestion. Pour chaque cluster de charge de travail, AKS ajoute au moins une machine virtuelle d’équilibreur de charge. Tout service Kubernetes de type LoadBalancer créé sur le cluster de charge de travail crée finalement une règle d’équilibrage de charge dans la machine virtuelle.
Nœuds worker
Pour exécuter vos applications et les services de prise en charge, vous avez besoin d’un nœud Kubernetes. Un cluster de charge de travail AKS a un ou plusieurs nœuds Worker. Les nœuds Worker agissent en tant que machines virtuelles qui exécutent les composants de nœud Kubernetes et hébergent les pods et les services qui composent la charge de travail de l’application.
Il existe des composants de charge de travail Kubernetes de base qui peuvent être déployés sur des clusters de charge de travail AKS, tels que des pods et des déploiements.
Pods
Kubernetes Utilise des pods pour exécuter une instance de votre application. Un pod représente une instance unique de votre application. En règle générale, les pods ont un mappage 1:1 avec un conteneur, bien qu’il existe des scénarios avancés dans lesquels un pod peut contenir plusieurs conteneurs. Ces pods multiconteneurs sont planifiés ensemble sur le même nœud et permettent aux conteneurs de partager des ressources connexes. Pour plus d’informations, consultez Kubernetes pods (Pods Kubernetes) et Kubernetes pod lifecycle (cycle de vie des pods Kubernetes).
Déploiements
Un déploiement représente un ou plusieurs pods identiques, gérés par le contrôleur de déploiement Kubernetes. Un déploiement définit le nombre de réplicas (pods ) à créer et le planificateur Kubernetes garantit que si des pods ou des nœuds rencontrent des problèmes, des pods supplémentaires sont planifiés sur des nœuds sains. Pour plus d’informations, consultez la section Déploiements Kubernetes.
Ressources StatefulSet et ressources DaemonSet
Le contrôleur de déploiement utilise le planificateur Kubernetes pour exécuter un nombre donné de réplicas sur n’importe quel nœud disponible avec des ressources disponibles. Cette approche de l’utilisation de déploiements peut être suffisante pour les applications sans état, mais pas pour les applications qui nécessitent une convention de nommage persistante ou un stockage. Pour les applications qui nécessitent qu’un réplica existe sur chaque nœud (ou certains nœuds) au sein d’un cluster, le contrôleur de déploiement ne considère pas la façon dont les réplicas sont répartis entre les nœuds.
- StatefulSets : un StatefulSet est similaire à un déploiement dans lequel un ou plusieurs pods identiques sont créés et gérés. Les réplicas d’une ressource StatefulSet suivent une approche séquentielle et sans perte de données du déploiement, de la mise à l’échelle, des mises à niveau et des arrêts. Avec une ressource StatefulSet (quand les réplicas sont replanifiés), la convention d’affectation de noms, les noms de réseau et le stockage persistent. Les réplicas d’un StatefulSet sont planifiés et exécutés sur n’importe quel nœud disponible dans un cluster Kubernetes. Si vous devez vous assurer qu’au moins un pod de votre jeu s’exécute sur un nœud, vous pouvez plutôt utiliser un DaemonSet. Pour plus d’informations, consultez la section Kubernetes StatefulSets.
- DaemonSets : pour des besoins spécifiques de collecte de journaux ou de surveillance, vous devrez peut-être exécuter un pod donné sur tous les nœuds, ou sélectionnés. Un DaemonSet est à nouveau utilisé pour déployer un ou plusieurs pods identiques, mais le contrôleur DaemonSet garantit que chaque nœud spécifié exécute une instance du pod. Pour plus d’informations, consultez la section Kubernetes DaemonSets.
Espaces de noms
Les ressources Kubernetes, telles que les pods et les déploiements, sont regroupées logiquement dans un espace de noms. Ces regroupements permettent de diviser logiquement les clusters de charge de travail et de restreindre l’accès à la création, à l’affichage ou à la gestion des ressources. Par exemple, vous pouvez créer des espaces de noms pour séparer les groupes métier. Les utilisateurs ne peuvent interagir qu’avec les ressources appartenant aux espaces de noms qui leur sont attribués. Pour plus d’informations, consultez la section Espace de noms Kubernetes.
Lorsque vous créez un cluster Azure Kubernetes Service sur AKS activé par Arc, les espaces de noms suivants sont disponibles :
- par défaut : espace de noms où les pods et les déploiements sont créés par défaut lorsqu’aucun n’est fourni. Dans les environnements plus petits, vous pouvez déployer les applications directement dans l’espace de noms par défaut sans provoquer la création de séparations logiques supplémentaires. Quand vous interagissez avec l’API Kubernetes, comme avec
kubectl get pods, l’espace de noms par défaut est utilisé si aucun n’est spécifié. - kube-system : espace de noms où existent les ressources principales, telles que les fonctionnalités réseau telles que DNS et proxy, ou le tableau de bord Kubernetes. En règle générale, vous ne déployez pas vos propres applications dans cet espace de noms.
- kube-public : un espace de noms généralement non utilisé, mais peut être utilisé pour que les ressources soient visibles sur l’ensemble du cluster et peuvent être affichées par n’importe quel utilisateur.
Secrets
Les secrets Kubernetes vous permettent de stocker et de gérer des informations sensibles, telles que des mots de passe, des jetons OAuth et des clés SSH (Secure Shell). Par défaut, Kubernetes stocke les secrets sous forme de chaînes codées en base64 non chiffrées, et ils peuvent être récupérés sous forme de texte brut par toute personne disposant d’un accès à l’API. Pour plus d’informations, consultez la section Secrets Kubernetes.
Volumes persistants
Un volume persistant est une ressource de stockage dans un cluster Kubernetes qui a été configurée par l’administrateur ou configurée dynamiquement à l’aide de classes de stockage. Pour utiliser des volumes persistants, les pods demandent l’accès à l’aide d’un PersistentVolumeClaim. Pour plus d’informations, consultez Volumes persistants.
Déploiements de système d’exploitation mixte
Si un cluster de charge de travail donné est constitué de nœuds Worker Linux et Windows, il doit être planifié sur un système d’exploitation capable de prendre en charge le provisionnement 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œuds est un champ simple dans la spécification de pod qui limite les pods à être planifiés uniquement sur des nœuds sains correspondant au système d’exploitation.
- Les teintes et tolérances fonctionnent ensemble pour s’assurer que les pods ne sont pas planifiés sur les nœuds de manière involontaire. Un nœud peut être « teinte » de sorte qu’il n’accepte pas 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.
Étapes suivantes
Dans cet article, vous avez découvert l’architecture de cluster d’AKS activée par Azure Arc et les composants du cluster de charge de travail. Pour plus d’informations sur ces concepts, consultez les articles suivants :