Gestion et déploiement d’Azure Arc hybride pour les clusters Kubernetes

Cette architecture de référence illustre comment Azure Arc étend la gestion et la configuration des clusters Kubernetes dans les centres de données clients, les emplacements de périphérie et plusieurs environnements cloud.

Architecture

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

Workflow

L’architecture repose sur les aspects suivants :

• Kubernetes avec Azure Arc. Attachez et configurez des clusters Kubernetes à l’intérieur ou à l’extérieur d’Azure en utilisant Kubernetes avec Azure Arc. Lorsqu’un cluster Kubernetes est attaché à Azure Arc, un ID Azure Resource Manager et une identité managée lui sont attribués.
• Azure Kubernetes Service . Hébergez des clusters Kubernetes dans Azure pour réduire la complexité et la charge opérationnelle de la gestion des clusters Kubernetes.
• Cluster Kubernetes local . Attachez des clusters Kubernetes certifiés CNCF (Cloud Native Computing Foundation) qui sont hébergés dans des environnements locaux ou cloud tiers.
• Azure Policy . Déployez et gérez des stratégies pour les clusters Kubernetes avec Arc.
• Azure Monitor. Observez et surveillez les clusters Kubernetes avec Arc.

Composants

• Azure Arc est un pont qui étend la plateforme Azure, ce qui permet de générer des applications et des services qui peuvent s’exécuter sur des centres de données, à la périphérie et dans des environnements multiclouds.
• Azure Kubernetes Service (AKS) est un service managé pour le déploiement et la mise à l’échelle des clusters Kubernetes.
• Azure Policy permet d’obtenir une conformité du cloud en temps réel à grande échelle avec une gouvernance cohérente des ressources.
• Azure Monitor fournit une observabilité de bout en bout pour vos applications, votre infrastructure et votre réseau.

Détails du scénario

Vous pouvez utiliser Azure Arc pour inscrire des clusters Kubernetes qui sont hébergés en dehors de Microsoft Azure. Vous pouvez ensuite utiliser des outils Azure pour gérer ces clusters ainsi que les clusters qui sont hébergés dans Azure Kubernetes Service (AKS).

Cas d’usage potentiels

Utilisations courantes de cette architecture :

• Gestion des clusters Kubernetes locaux et des clusters hébergés dans AKS pour l’inventaire, le regroupement et le balisage.
• Utilisation d’Azure Monitor pour superviser les clusters Kubernetes dans des environnements hybrides.
• Utilisation d’Azure Policy pour déployer et appliquer des stratégies pour les clusters Kubernetes dans des environnements hybrides.
• Utilisation d’Azure Policy pour déployer et appliquer GitOps.

Recommandations

Les sections suivantes fournissent des recommandations qui s’appliquent à la plupart des scénarios. Microsoft vous recommande de les suivre, sauf si vous avez une exigence qui vous oblige à les ignorer.

Inscription du cluster

Vous pouvez inscrire n’importe quel cluster Kubernetes CNCF actif. Vous avez besoin d’un fichier kubeconfig pour accéder au cluster et d’un rôle d’administrateur de cluster sur le cluster pour déployer des agents Kubernetes avec Arc. Vous utilisez l’interface de ligne de commande Azure (Azure CLI) pour effectuer les tâches d’inscription des clusters. L’utilisateur ou le principal du service que vous utilisez pour les commandes az login et az connectedk8s connect requiert des autorisations en lecture et en écriture sur le type de ressource Microsoft.Kubernetes/connectedClusters. Le rôle « Intégration d’Azure Arc pour cluster Kubernetes » dispose de ces autorisations et peut être utilisé pour les attributions de rôles sur l’utilisateur ou le principal du service. Helm 3 est requis pour l’intégration du cluster qui utilise l’extension connectedk8s. Azure CLI version 2.3 ou ultérieure est nécessaire pour installer les extensions de l’interface de ligne de commande Kubernetes avec Azure Arc.

Agents Azure Arc pour Kubernetes

Kubernetes avec Azure Arc se compose de quelques agents (également appelés opérateurs) qui s’exécutent dans le cluster qui est déployé sur l’espace de noms azure-arc :

• deployment.apps/config-agent. Surveille le cluster connecté pour les ressources de configuration du contrôle de code source qui sont appliquées au cluster, et met à jour l’état de conformité.
• deployment.apps/controller-manager. Opérateur d’opérateurs orchestrant les interactions entre les composants Azure Arc.
• deployment.apps/metrics-agent. Collecte les métriques d’autres agents Arc pour s’assurer que ces agents offrent des performances optimales.
• deployment.apps/cluster-metadata-operator. Collecte les métadonnées de cluster, la version du cluster, le nombre de nœuds et la version de l’agent Azure Arc.
• deployment.apps/resource-sync-agent. Synchronise les métadonnées de cluster précitées dans Azure.
• deployment.apps/clusteridentityoperator. Gère le certificat Managed Service Identity (MSI) qui est utilisé par d’autres agents pour communiquer avec Azure.
• deployment.apps/flux-logs-agent. Collecte des journaux auprès des opérateurs de flux qui sont déployés dans le cadre de la configuration du contrôle de code source.
• deployment.apps/extension-manager. Installe et gère le cycle de vie des graphiques Helm d’extension.
• deployment.apps/kube-azure-ad-proxy. Utilisé pour l’authentification des demandes qui sont envoyées au cluster à l’aide de la Connexion de cluster.
• deployment.apps/clusterconnect-agent. Agent proxy inverse qui permet à la fonctionnalité de connexion de cluster de donner accès au serveur d’API (apiserver) du cluster. Il s’agit d’une composant facultatif qui est déployé uniquement si la fonctionnalité de connexion de cluster est activée sur le cluster.
• deployment.apps/guard. Serveur webhook d’authentification et d’autorisation qui est utilisé pour le contrôle d’accès en fonction du rôle (RBAC) Microsoft Entra. Il s’agit d’une composant facultatif qui est déployé uniquement si la fonctionnalité azure-rbac est activée sur le cluster.

Pour plus d’informations, consultez Connecter un cluster Kubernetes activé par Azure Arc.

Superviser des clusters à l’aide d’Azure Monitor Container Insights

La surveillance de vos conteneurs est essentielle. Azure Monitor Container Insights offre une expérience de monitoring riche pour les clusters AKS et de moteur AKS. Vous pouvez également configurer Azure Monitor Container Insights afin de superviser les clusters Kubernetes avec Azure Arc qui sont hébergés en dehors d’Azure. Cette opération permet un monitoring complet de vos clusters Kubernetes dans les environnements Azure, locaux et cloud tiers.

Azure Monitor Container Insights peut vous offrir une visibilité des performances en collectant les métriques relatives à la mémoire et au processeur à partir des contrôleurs, des nœuds et des conteneurs, lesquelles sont disponibles dans Kubernetes par le biais de l’API (interface de programmation d’applications) Métriques. Les journaux d’activité de conteneur sont aussi collectés. Une fois que vous avez activé le monitoring des clusters Kubernetes, les métriques et les journaux sont automatiquement collectés par une version en conteneur de l’agent Log Analytics. Les métriques sont écrites dans le magasin des métriques, et les données de journaux sont écrites dans le magasin des journaux qui est associé à votre espace de travail Log Analytics. Pour plus d’informations sur Azure Monitor Container Insights, consultez Vue d’ensemble d’Azure Monitor Container Insights.

Vous pouvez activer Azure Monitor Container Insights pour un ou plusieurs déploiements de Kubernetes à l’aide d’un script PowerShell ou d’un script Bash.

Pour activer le monitoring des clusters Kubernetes avec Azure Arc, consultez Activer le monitoring d’un cluster Kubernetes avec Azure Arc

Utiliser Azure Policy pour activer un déploiement d’applications basées sur GitOps

Utilisez Azure Policy pour faire en sorte que chaque ressource Microsoft.Kubernetes/connectedclusters ou ressource Microsoft.ContainerService/managedClusters compatible avec Git-Ops soit dotée d’une configuration Microsoft.KubernetesConfiguration/fluxConfigurations spécifique. Par exemple, vous pouvez appliquer une configuration de ligne de base à un ou plusieurs clusters ou déployer des applications spécifiques sur plusieurs clusters. Pour utiliser Azure Policy, sélectionnez une définition dans Définitions intégrées Azure Policy pour Kubernetes avec Azure Arc, puis créez une attribution de stratégie.

Lorsque vous créez l’attribution de stratégie, définissez l’étendue sur un groupe de ressources ou un abonnement Azure. Définissez également les paramètres de la ressource fluxConfiguration créée. Une fois l’attribution créée, le moteur de stratégie identifie toutes les ressources connectedCluster ou managedCluster qui se trouvent dans l’étendue, puis applique la ressource fluxConfiguration à chacune d’entre elles.

Si vous utilisez plusieurs référentiels sources pour chaque cluster (par exemple, un dépôt pour l’opérateur de cluster/informatique central et d’autres dépôts pour les équipes d’application), activez cela en utilisant plusieurs attributions de stratégies et configurez chacune d’elle pour utiliser un référentiel source distinct.

Pour plus d’informations, consultez Déployez des applications de manière cohérente à l’échelle à l’aide de configurations Flux v2 et Azure Policy.

Déployer des applications en utilisant GitOps

GitOps est la pratique qui consiste à déclarer l’état souhaité de la configuration Kubernetes (déploiements, espaces de noms, etc.) dans un référentiel source, tel qu’un dépôt Git ou Helm, des compartiments ou Stockage Blob Azure. Cette étape est suivie d’une interrogation et d’un déploiement basé sur l’extraction (pull) de ces configurations sur le cluster à l’aide d’un opérateur.

La connexion entre votre cluster et un ou plusieurs référentiels sources est activée en déployant l’extension microsoft.flux sur votre cluster. Les propriétés de la ressource fluxConfiguration indiquent où et comment les ressources Kubernetes doivent circuler du référentiel source vers votre cluster. Les données de fluxConfiguration sont stockées et chiffrées au repos dans une base de données Azure Cosmos DB pour garantir leur confidentialité.

L’agent flux-config qui s’exécute dans votre cluster est chargé de surveiller les ressources d’extension fluxConfiguration nouvelles ou mises à jour sur la ressource Kubernetes avec Azure Arc, de déployer des applications à partir d’un référentiel source et de propager toutes les mises à jour qui sont apportées à fluxConfiguration. Vous pouvez même créer plusieurs ressources fluxConfiguration en utilisant l’étendue namespace sur le même cluster Kubernetes avec Azure Arc afin d’obtenir une architecture multilocataire.

Le référentiel source peut contenir toutes les ressources Kubernetes valides, notamment Namespaces, ConfigMaps, Deployments et DaemonSets. Il peut également contenir des graphiques Helm pour le déploiement d’applications. Les scénarios courants de dépôt source incluent la définition d’une configuration de référence pour votre organisation qui peut inclure des rôles de contrôle d’accès en fonction du rôle (RBAC) et des liaisons courants, des agents de surveillance, des agents de journalisation et des services à l’échelle du cluster.

Vous pouvez également gérer une plus grande collection de clusters qui sont déployés dans des environnements hétérogènes. Par exemple, vous pouvez avoir un dépôt qui définit la configuration de référence pour votre organisation, puis l’appliquer à plusieurs clusters Kubernetes simultanément. Vous pouvez également déployer des applications vers un cluster à partir de plusieurs référentiels sources.

Pour plus d’informations, consultez Déployer des applications à l’aide de GitOps avec Flux v2.

Topologie, réseau et routage

Les agents Azure Arc nécessitent les protocoles/ports/URL sortantes suivants pour fonctionner :

Pour obtenir la liste complète des URL des services Azure Arc, consultez Configuration réseau requise pour Azure Arc.

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.

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

• Dans la plupart des cas, l’emplacement que vous sélectionnez quand vous créez le script d’installation doit être la région Azure qui est géographiquement la plus proche de vos ressources locales. Le reste des données est stocké dans la zone géographique Azure qui contient la région que vous spécifiez, et ce fait peut influencer votre choix de région si vous avez des exigences relatives à la résidence des données. Si la région Azure à laquelle votre machine est connecté subit une panne, la machine connectée n’est pas affectée, mais les opérations de gestion qui utilisent Azure risquent de ne pas aboutir. Pour bénéficier d’une résilience en cas de panne régionale, si vous avez plusieurs emplacements qui assurent un service géographiquement redondant, il est préférable de connecter les machines de chaque emplacement à une autre région Azure. Pour connaître les régions disponibles, consultez Régions prises en charge pour les clusters Kubernetes avec Azure Arc.
• Vous devez vous assurer que les services qui sont référencés dans la section Architecture sont pris en charge dans la région où Azure Arc est déployé.

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

• Vous pouvez utiliser RBAC Azure pour gérer l’accès aux clusters Kubernetes avec Azure Arc dans les environnements Azure et locaux en utilisant des identités Microsoft Entra. Pour plus d’informations, consultez Utiliser Azure RBAC pour l’autorisation Kubernetes.
• Microsoft vous recommande d’utiliser un principal de service qui dispose de privilèges limités pour intégrer des clusters Kubernetes à Azure Arc. Cette pratique est utile dans les pipelines CI/CD tels qu’Azure Pipelines et GitHub Actions. Pour plus d’informations, consultez Créer un principal de service d’intégration compatible avec Azure Arc.
• Pour simplifier la gestion des principaux de service, vous pouvez utiliser des identités managées dans AKS. Toutefois, les clusters doivent être créés à l’aide de l’identité managée, et les clusters existants (notamment les clusters Azure et locaux) ne peuvent pas être migrés vers des identités managées. Pour plus d’informations, voir Utiliser les identités managées dans Azure Kubernetes Service.

Optimisation des coûts

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

Les considérations générales relatives aux coûts sont décrites dans la section Principes d’optimisation des coûts de Microsoft Azure Well-Architected Framework.

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.

• Avant de configurer vos clusters Kubernetes avec Azure Arc, examinez les limites d’abonnement et les limites de groupe de ressources d’Azure Resource Manager pour planifier le nombre de clusters.
• Utilisez Helm, l’outil d’empaquetage open source, pour installer et gérer les cycles de vie des applications Kubernetes. À l’instar des gestionnaires de package Linux tels qu’APT et Yum, vous utilisez Helm pour gérer les charts Kubernetes, qui sont des packages de ressources Kubernetes préconfigurées.

Contributeurs

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

Auteur principal :

• Pieter de Bruin | Responsable de programme senior

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

Étapes suivantes

• Documentation Azure Arc
• Documentation de Kubernetes avec Azure Arc
• Documentation sur Azure Kubernetes Service
• Documentation Azure Policy
• Documentation Azure Monitor
• Connecter un cluster Kubernetes avec Azure Arc

Ressources associées

Conseils associés sur l’architecture hybride :

• Conception d’une architecture hybride
• Options hybrides Azure
• Considérations sur la conception d’applications hybrides

Architectures connexes :

• Architecture de référence pour AKS sur Azure Stack HCI
• Architecture réseau pour AKS sur Azure Stack HCI
• Optimiser l’administration des instances SQL dans les environnements locaux et multiclouds avec Azure Arc
• Surveillance d’entreprise avec Azure Monitor