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

Azure Arc

Azure Kubernetes Service (AKS)

Azure Monitor

Azure Policy

Contrôle d’accès en fonction du rôle Azure

Cette architecture de référence décrit 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

Ce diagramme d’architecture montre différents services Azure et leurs fonctionnalités. Deux icônes représentant des clusters Kubernetes avec Azure Arc se trouvent dans une section étiquetée localement. Quatre icônes représentant Azure Monitor, Azure Policy et Azure Kubernetes Service (AKS) se trouvent dans une section intitulée Azure. L’icône AKS s’affiche deux fois. Les flèches indiquent une connexion entre la section Azure et les deux clusters Kubernetes avec Azure Arc dans la section locale. Les flèches indiquent également une connexion entre Azure Policy, les clusters dans les sections locales et Azure et Azure Monitor.

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

Workflow

Le workflow suivant correspond au diagramme précédent :

• Kubernetes avec Azure Arc : Attachez et configurez des clusters Kubernetes à l’intérieur ou à l’extérieur d’Azure à l’aide de 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 (AKS) : Héberger des clusters Kubernetes dans Azure pour réduire la complexité et la surcharge opérationnelle de la gestion des clusters Kubernetes.

• Cluster Kubernetes local : Attachez des clusters Kubernetes certifiés CLOUD Native Computing Foundation (CNCF) hébergés dans des environnements cloud locaux ou non-Microsoft.

• Azure Policy : Déployez et gérez des stratégies pour les clusters Kubernetes avec Azure Arc.

• Azure Monitor : Observez et surveillez les clusters Kubernetes avec Azure Arc.

Composants

• Azure Arc étend la plateforme Azure, ce qui permet de créer 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.

• AKS est un service managé pour le déploiement et la mise à l’échelle de 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 et les clusters hébergés par AKS.

Cas d’usage potentiels

Utilisations courantes de cette architecture :

• Gestion de l’inventaire, du regroupement et du balisage pour les clusters Kubernetes locaux et les clusters hébergés par AKS.

• Utilisation d’Azure Monitor pour superviser les clusters Kubernetes dans des environnements hybrides.

• Utilisation d’Azure Policy pour faciliter le déploiement et l’application de stratégies pour les clusters Kubernetes dans les environnements hybrides.

• Utilisation d’Azure Policy pour faciliter le déploiement et l’application de GitOps.

• Optimisation de l’investissement de votre unité de traitement graphique locale (GPU) en formant et en déployant des flux de travail Azure Machine Learning.

• Utilisation du service managé Azure Monitor pour Prometheus et Managed Grafana pour surveiller et visualiser les charges de travail Kubernetes.

Recommandations

Vous pouvez appliquer les recommandations suivantes à la plupart des scénarios. Suivez ces recommandations, sauf si vous avez un besoin spécifique qui vous oblige à les ignorer.

Inscription du cluster

Vous pouvez inscrire n’importe quel cluster Kubernetes CNCF actif. Vous avez besoin d’un kubeconfig fichier pour accéder au cluster et à un rôle d’administrateur de cluster sur le cluster pour déployer des agents Kubernetes avec Azure Arc. Utilisez Azure CLI pour effectuer des tâches d’inscription de cluster. L’utilisateur ou le principal de service que vous utilisez pour les az login commandes nécessite az connectedk8s connect des autorisations en lecture-écriture sur le Microsoft.Kubernetes/connectedClusters type de ressource. 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 intégrer le cluster qui utilise l’extension connectedk8s . Azure CLI version 2.3 ou ultérieure est nécessaire pour installer les extensions d’interface DE ligne de commande Kubernetes avec Azure Arc.

Agents Azure Arc pour Kubernetes

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

• Le deployment.apps/config-agent cluster connecté surveille les ressources de configuration du contrôle de code source appliquées au cluster et met à jour l’état de conformité.

• Il deployment.apps/controller-manager s’agit d’un opérateur d’opérateurs qui orchestre les interactions entre les composants Azure Arc.

• Les deployment.apps/metrics-agent métriques collectées à partir d’autres agents Azure Arc permettent de s’assurer que ces agents fonctionnent de manière optimale.

• Le deployment.apps/cluster-metadata-operator cluster collecte les métadonnées, notamment la version du cluster, le nombre de nœuds et la version de l’agent Azure Arc.

• Le deployment.apps/resource-sync-agent cluster synchronise les métadonnées de cluster mentionnées précédemment sur Azure.

• Le deployment.apps/clusteridentityoperator certificat Managed Service Identity utilisé par d’autres agents pour communiquer avec Azure est conservé.

• Collecte deployment.apps/flux-logs-agent les journaux des opérateurs de flux déployés dans le cadre de la configuration du contrôle de code source.

• Les deployment.apps/extension-manager installations et gère le cycle de vie des graphiques Helm d’extension.

• Gère l’authentification deployment.apps/kube-aad-proxy pour les demandes envoyées au cluster via la fonctionnalité de connexion au cluster AKS.

• Il deployment.apps/clusterconnect-agent s’agit d’un agent proxy inverse qui permet à la fonctionnalité de connexion au cluster de fournir l’accès au serveur d’API 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.

• Il deployment.apps/guard s’agit d’un serveur webhook d’authentification et d’autorisation utilisé pour le contrôle d’accès en fonction du rôle (RBAC) Microsoft Entra. Il s’agit d’un composant facultatif déployé uniquement si Azure RBAC est activé sur le cluster.

• Collecte deployment.apps/extension-events-collector les journaux liés à la gestion du cycle de vie des extensions. Il agrège ces journaux d’activité en événements qui correspondent à chaque opération, telle que Créer, Mettre à niveau et Supprimer.  

• La deployment.apps/logcollector plateforme collecte les données de télémétrie pour garantir l’intégrité opérationnelle de la plateforme.

Pour plus d’informations, consultez Connecter un cluster Kubernetes existant à Azure Arc.

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

La surveillance de vos conteneurs est cruciale. Azure Monitor Container Insights fournit des fonctionnalités de supervision robustes pour les clusters de moteur AKS et AKS. Vous pouvez également configurer Azure Monitor Container Insights pour surveiller les clusters Kubernetes avec Azure Arc hébergés en dehors d’Azure. Cette configuration fournit une surveillance complète de vos clusters Kubernetes sur Azure, localement et dans des environnements cloud non-Microsoft.

Azure Monitor Container Insights offre une visibilité des performances en collectant des métriques de mémoire et de processeur à partir de contrôleurs, de nœuds et de conteneurs. Ces métriques sont disponibles dans Kubernetes via l’API Metrics. Les journaux d’activité de conteneur sont aussi collectés. Après avoir activé la surveillance à partir de clusters Kubernetes, une version conteneurisée de l’agent Log Analytics collecte automatiquement les métriques et les journaux. 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, consultez les fonctionnalités d’Azure Monitor pour la surveillance Kubernetes.

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 plus d’informations, consultez Activer la supervision pour les clusters Kubernetes.

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

Utilisez Azure Policy pour vous assurer que chaque ressource ou Microsoft.ContainerService/managedClusters ressource avec Microsoft.Kubernetes/connectedclusters GitOps a une application spécifiqueMicrosoft.KubernetesConfiguration/fluxConfigurations. 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, choisissez une définition dans les 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 pour le fluxConfiguration fichier créé. Lorsque l’affectation est créée, le moteur Azure Policy identifie toutes ou managedCluster ressources connectedCluster qui se trouvent dans l’étendue, puis applique la fluxConfiguration ressource à chaque ressource.

Si vous utilisez plusieurs référentiels sources pour chaque cluster, tels qu’un référentiel pour l’opérateur informatique central ou de cluster et d’autres référentiels pour les équipes d’applications, activez cette fonctionnalité à l’aide de plusieurs affectations de stratégie et configurez chaque affectation de stratégie pour utiliser un référentiel source différent.

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

Déployer des applications à l’aide de GitOps

GitOps est la pratique de la définition de l’état souhaité des configurations Kubernetes, telles que les déploiements et les espaces de noms, dans un référentiel source. Ce référentiel peut être un dépôt Git ou Helm, des compartiments ou un stockage Blob Azure. Ce processus est suivi d’un déploiement basé sur l’interrogation et l’extraction 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 fluxConfiguration propriétés de ressource représentent où et comment les ressources Kubernetes doivent passer du référentiel source à votre cluster. Les fluxConfiguration données sont stockées chiffrées au repos dans une base de données Azure Cosmos DB pour garantir la confidentialité des données.

L’agent flux-config qui s’exécute dans votre cluster surveille les ressources d’extension nouvelles ou mises à jour fluxConfiguration sur la ressource Kubernetes avec Azure Arc, déploie des applications à partir du référentiel source et propage toutes les mises à jour apportées à l’instance fluxConfiguration. Vous pouvez créer plusieurs fluxConfiguration ressources à l’aide de l’étendue namespace sur le même cluster Kubernetes avec Azure Arc pour obtenir une architecture mutualisée.

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 de référentiel source courants incluent la définition d’une configuration de base de référence pour votre organisation qui peut inclure des rôles et liaisons RBAC 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 référentiel qui définit la configuration de base de référence pour votre organisation, puis appliquer cette configuration à 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.

Exécuter Machine Learning

Dans Machine Learning, vous pouvez choisir un cluster AKS (ou Kubernetes avec Azure Arc) en tant que cible de calcul pour vos processus Machine Learning. Cette fonctionnalité vous permet d’entraîner ou de déployer des modèles Machine Learning dans votre propre infrastructure auto-hébergée (ou multicloud). Cette approche vous permet de combiner vos investissements locaux sur les GPU avec la facilité de gestion que Fournit Machine Learning dans le cloud.

Surveiller les charges de travail Kubernetes avec Prometheus et Grafana managés

Azure Monitor fournit un service managé pour les déploiements Prometheus et Grafana, afin que vous puissiez tirer parti de ces outils de supervision Kubernetes populaires. Ce service managé vous permet d’utiliser ces outils sans avoir à gérer et à mettre à jour les déploiements vous-même. Pour analyser les métriques de Prometheus, utilisez l’Explorateur de métriques avec PromQL.

Topologie, réseau et routage

Les agents Azure Arc nécessitent les protocoles, ports et URL sortantes suivants pour fonctionner.

Point de terminaison (DNS)	Descriptif
https://management.azure.com:443	Requis pour que l’agent se connecte à Azure et inscrive le cluster.
https://[region].dp.kubernetesconfiguration.azure.com:443	Point de terminaison du plan de données permettant à l’agent d’envoyer (push) l’état et de récupérer (fetch) les informations de configuration, où [region] représente la région Azure qui héberge l’instance AKS.
https://docker.io:443	Requis pour extraire des images conteneurs.
https://github.com:443, git://github.com:9418	Des exemples de dépôts GitOps sont hébergés sur GitHub. L’agent de configuration nécessite une connectivité au point de terminaison Git que vous spécifiez.
https://login.microsoftonline.com:443, , https://<region>.login.microsoft.comlogin.windows.net	Requis pour extraire et mettre à jour des jetons Azure Resource Manager.
https://mcr.microsoft.com:443 https://*.data.mcr.microsoft.com:443	Requis pour extraire des images conteneurs pour les agents Azure Arc.

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, un ensemble de principes directeurs que vous pouvez utiliser pour 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 peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez liste de vérification de la révision de conception pour lede fiabilité.

• Dans la plupart des scénarios, l’emplacement que vous choisissez lorsque vous créez le script d’installation doit être la région Azure la plus proche géographiquement 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. Ce détail peut affecter votre choix de région si vous avez des exigences de 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. Si vous avez plusieurs emplacements qui fournissent un service géographiquement redondant, connectez les machines de chaque emplacement à une autre région Azure. Cette pratique améliore la résilience si une panne régionale se produit. Pour plus d’informations, consultez Régions prises en charge pour Kubernetes avec Azure Arc.

• Vous devez vous assurer que les services de votre solution sont pris en charge dans la région où Azure Arc est déployé.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification de la révision de conception pour security.

• 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 disposant de privilèges limités pour intégrer des clusters Kubernetes à Azure Arc. Cette pratique est utile dans les pipelines d’intégration continue et de livraison continue tels qu’Azure Pipelines et GitHub Actions. Pour plus d’informations, consultez Créer un principal de service d’intégration 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. Les clusters existants, qui incluent Azure et les clusters locaux, ne peuvent pas être migrés vers des identités managées. Pour plus d’informations, consultez Utiliser une identité managée dans AKS.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’optimisation des coûts.

Pour connaître les considérations générales relatives aux coûts, consultez les principes de conception de l’optimisation des coûts.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’excellence opérationnelle.

• Avant de configurer vos clusters Kubernetes avec Azure Arc, passez en revue les limites d’abonnement Azure Resource Manager et les limites de groupe de ressources à planifier pour le nombre de clusters.

• Utilisez Helm, qui est un outil d’empaquetage open source, pour installer et gérer les cycles de vie des applications Kubernetes. Comme pour les gestionnaires de packages Linux tels que APT et Yum, utilisez Helm pour gérer des graphiques Kubernetes, qui sont des packages de ressources Kubernetes préconfigurées.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

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 AKS
• Documentation Azure Policy
• Documentation Azure Monitor
• Connectez un cluster Kubernetes existant à Azure Arc

Ressources associées

Conseils associés sur l’architecture hybride :

• Conception d’une architecture hybride
• Options hybrides Azure

Architectures connexes :

• architecture de base de référence pour AKS sur Azure Local
• Optimiser l’administration des instances SQL dans les environnements locaux et multiclouds avec Azure Arc

Cette architecture de référence décrit 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

Ce diagramme d’architecture montre différents services Azure et leurs fonctionnalités. Deux icônes représentant des clusters Kubernetes avec Azure Arc se trouvent dans une section étiquetée localement. Quatre icônes représentant Azure Monitor, Azure Policy et Azure Kubernetes Service (AKS) se trouvent dans une section intitulée Azure. L’icône AKS s’affiche deux fois. Les flèches indiquent une connexion entre la section Azure et les deux clusters Kubernetes avec Azure Arc dans la section locale. Les flèches indiquent également une connexion entre Azure Policy, les clusters dans les sections locales et Azure et Azure Monitor.

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

Workflow

Le workflow suivant correspond au diagramme précédent :

• Kubernetes avec Azure Arc : Attachez et configurez des clusters Kubernetes à l’intérieur ou à l’extérieur d’Azure à l’aide de 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 (AKS) : Héberger des clusters Kubernetes dans Azure pour réduire la complexité et la surcharge opérationnelle de la gestion des clusters Kubernetes.

• Cluster Kubernetes local : Attachez des clusters Kubernetes certifiés CLOUD Native Computing Foundation (CNCF) hébergés dans des environnements cloud locaux ou non-Microsoft.

• Azure Policy : Déployez et gérez des stratégies pour les clusters Kubernetes avec Azure Arc.

• Azure Monitor : Observez et surveillez les clusters Kubernetes avec Azure Arc.

Composants

• Azure Arc étend la plateforme Azure, ce qui permet de créer 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.

• AKS est un service managé pour le déploiement et la mise à l’échelle de 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 et les clusters hébergés par AKS.

Cas d’usage potentiels

Utilisations courantes de cette architecture :

• Gestion de l’inventaire, du regroupement et du balisage pour les clusters Kubernetes locaux et les clusters hébergés par AKS.

• Utilisation d’Azure Monitor pour superviser les clusters Kubernetes dans des environnements hybrides.

• Utilisation d’Azure Policy pour faciliter le déploiement et l’application de stratégies pour les clusters Kubernetes dans les environnements hybrides.

• Utilisation d’Azure Policy pour faciliter le déploiement et l’application de GitOps.

• Optimisation de l’investissement de votre unité de traitement graphique locale (GPU) en formant et en déployant des flux de travail Azure Machine Learning.

• Utilisation du service managé Azure Monitor pour Prometheus et Managed Grafana pour surveiller et visualiser les charges de travail Kubernetes.

Recommandations

Vous pouvez appliquer les recommandations suivantes à la plupart des scénarios. Suivez ces recommandations, sauf si vous avez un besoin spécifique qui vous oblige à les ignorer.

Inscription du cluster

Vous pouvez inscrire n’importe quel cluster Kubernetes CNCF actif. Vous avez besoin d’un kubeconfig fichier pour accéder au cluster et à un rôle d’administrateur de cluster sur le cluster pour déployer des agents Kubernetes avec Azure Arc. Utilisez Azure CLI pour effectuer des tâches d’inscription de cluster. L’utilisateur ou le principal de service que vous utilisez pour les az login commandes nécessite az connectedk8s connect des autorisations en lecture-écriture sur le Microsoft.Kubernetes/connectedClusters type de ressource. 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 intégrer le cluster qui utilise l’extension connectedk8s . Azure CLI version 2.3 ou ultérieure est nécessaire pour installer les extensions d’interface DE ligne de commande Kubernetes avec Azure Arc.

Agents Azure Arc pour Kubernetes

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

• Le deployment.apps/config-agent cluster connecté surveille les ressources de configuration du contrôle de code source appliquées au cluster et met à jour l’état de conformité.

• Il deployment.apps/controller-manager s’agit d’un opérateur d’opérateurs qui orchestre les interactions entre les composants Azure Arc.

• Les deployment.apps/metrics-agent métriques collectées à partir d’autres agents Azure Arc permettent de s’assurer que ces agents fonctionnent de manière optimale.

• Le deployment.apps/cluster-metadata-operator cluster collecte les métadonnées, notamment la version du cluster, le nombre de nœuds et la version de l’agent Azure Arc.

• Le deployment.apps/resource-sync-agent cluster synchronise les métadonnées de cluster mentionnées précédemment sur Azure.

• Le deployment.apps/clusteridentityoperator certificat Managed Service Identity utilisé par d’autres agents pour communiquer avec Azure est conservé.

• Collecte deployment.apps/flux-logs-agent les journaux des opérateurs de flux déployés dans le cadre de la configuration du contrôle de code source.

• Les deployment.apps/extension-manager installations et gère le cycle de vie des graphiques Helm d’extension.

• Gère l’authentification deployment.apps/kube-aad-proxy pour les demandes envoyées au cluster via la fonctionnalité de connexion au cluster AKS.

• Il deployment.apps/clusterconnect-agent s’agit d’un agent proxy inverse qui permet à la fonctionnalité de connexion au cluster de fournir l’accès au serveur d’API 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.

• Il deployment.apps/guard s’agit d’un serveur webhook d’authentification et d’autorisation utilisé pour le contrôle d’accès en fonction du rôle (RBAC) Microsoft Entra. Il s’agit d’un composant facultatif déployé uniquement si Azure RBAC est activé sur le cluster.

• Collecte deployment.apps/extension-events-collector les journaux liés à la gestion du cycle de vie des extensions. Il agrège ces journaux d’activité en événements qui correspondent à chaque opération, telle que Créer, Mettre à niveau et Supprimer.  

• La deployment.apps/logcollector plateforme collecte les données de télémétrie pour garantir l’intégrité opérationnelle de la plateforme.

Pour plus d’informations, consultez Connecter un cluster Kubernetes existant à Azure Arc.

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

La surveillance de vos conteneurs est cruciale. Azure Monitor Container Insights fournit des fonctionnalités de supervision robustes pour les clusters de moteur AKS et AKS. Vous pouvez également configurer Azure Monitor Container Insights pour surveiller les clusters Kubernetes avec Azure Arc hébergés en dehors d’Azure. Cette configuration fournit une surveillance complète de vos clusters Kubernetes sur Azure, localement et dans des environnements cloud non-Microsoft.

Azure Monitor Container Insights offre une visibilité des performances en collectant des métriques de mémoire et de processeur à partir de contrôleurs, de nœuds et de conteneurs. Ces métriques sont disponibles dans Kubernetes via l’API Metrics. Les journaux d’activité de conteneur sont aussi collectés. Après avoir activé la surveillance à partir de clusters Kubernetes, une version conteneurisée de l’agent Log Analytics collecte automatiquement les métriques et les journaux. 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, consultez les fonctionnalités d’Azure Monitor pour la surveillance Kubernetes.

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 plus d’informations, consultez Activer la supervision pour les clusters Kubernetes.

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

Utilisez Azure Policy pour vous assurer que chaque ressource ou Microsoft.ContainerService/managedClusters ressource avec Microsoft.Kubernetes/connectedclusters GitOps a une application spécifiqueMicrosoft.KubernetesConfiguration/fluxConfigurations. 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, choisissez une définition dans les 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 pour le fluxConfiguration fichier créé. Lorsque l’affectation est créée, le moteur Azure Policy identifie toutes ou managedCluster ressources connectedCluster qui se trouvent dans l’étendue, puis applique la fluxConfiguration ressource à chaque ressource.

Si vous utilisez plusieurs référentiels sources pour chaque cluster, tels qu’un référentiel pour l’opérateur informatique central ou de cluster et d’autres référentiels pour les équipes d’applications, activez cette fonctionnalité à l’aide de plusieurs affectations de stratégie et configurez chaque affectation de stratégie pour utiliser un référentiel source différent.

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

Déployer des applications à l’aide de GitOps

GitOps est la pratique de la définition de l’état souhaité des configurations Kubernetes, telles que les déploiements et les espaces de noms, dans un référentiel source. Ce référentiel peut être un dépôt Git ou Helm, des compartiments ou un stockage Blob Azure. Ce processus est suivi d’un déploiement basé sur l’interrogation et l’extraction 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 fluxConfiguration propriétés de ressource représentent où et comment les ressources Kubernetes doivent passer du référentiel source à votre cluster. Les fluxConfiguration données sont stockées chiffrées au repos dans une base de données Azure Cosmos DB pour garantir la confidentialité des données.

L’agent flux-config qui s’exécute dans votre cluster surveille les ressources d’extension nouvelles ou mises à jour fluxConfiguration sur la ressource Kubernetes avec Azure Arc, déploie des applications à partir du référentiel source et propage toutes les mises à jour apportées à l’instance fluxConfiguration. Vous pouvez créer plusieurs fluxConfiguration ressources à l’aide de l’étendue namespace sur le même cluster Kubernetes avec Azure Arc pour obtenir une architecture mutualisée.

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 de référentiel source courants incluent la définition d’une configuration de base de référence pour votre organisation qui peut inclure des rôles et liaisons RBAC 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 référentiel qui définit la configuration de base de référence pour votre organisation, puis appliquer cette configuration à 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.

Exécuter Machine Learning

Dans Machine Learning, vous pouvez choisir un cluster AKS (ou Kubernetes avec Azure Arc) en tant que cible de calcul pour vos processus Machine Learning. Cette fonctionnalité vous permet d’entraîner ou de déployer des modèles Machine Learning dans votre propre infrastructure auto-hébergée (ou multicloud). Cette approche vous permet de combiner vos investissements locaux sur les GPU avec la facilité de gestion que Fournit Machine Learning dans le cloud.

Surveiller les charges de travail Kubernetes avec Prometheus et Grafana managés

Azure Monitor fournit un service managé pour les déploiements Prometheus et Grafana, afin que vous puissiez tirer parti de ces outils de supervision Kubernetes populaires. Ce service managé vous permet d’utiliser ces outils sans avoir à gérer et à mettre à jour les déploiements vous-même. Pour analyser les métriques de Prometheus, utilisez l’Explorateur de métriques avec PromQL.

Topologie, réseau et routage

Les agents Azure Arc nécessitent les protocoles, ports et URL sortantes suivants pour fonctionner.

Point de terminaison (DNS)	Descriptif
https://management.azure.com:443	Requis pour que l’agent se connecte à Azure et inscrive le cluster.
https://[region].dp.kubernetesconfiguration.azure.com:443	Point de terminaison du plan de données permettant à l’agent d’envoyer (push) l’état et de récupérer (fetch) les informations de configuration, où [region] représente la région Azure qui héberge l’instance AKS.
https://docker.io:443	Requis pour extraire des images conteneurs.
https://github.com:443, git://github.com:9418	Des exemples de dépôts GitOps sont hébergés sur GitHub. L’agent de configuration nécessite une connectivité au point de terminaison Git que vous spécifiez.
https://login.microsoftonline.com:443, , https://<region>.login.microsoft.comlogin.windows.net	Requis pour extraire et mettre à jour des jetons Azure Resource Manager.
https://mcr.microsoft.com:443 https://*.data.mcr.microsoft.com:443	Requis pour extraire des images conteneurs pour les agents Azure Arc.

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, un ensemble de principes directeurs que vous pouvez utiliser pour 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 peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez liste de vérification de la révision de conception pour lede fiabilité.

• Dans la plupart des scénarios, l’emplacement que vous choisissez lorsque vous créez le script d’installation doit être la région Azure la plus proche géographiquement 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. Ce détail peut affecter votre choix de région si vous avez des exigences de 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. Si vous avez plusieurs emplacements qui fournissent un service géographiquement redondant, connectez les machines de chaque emplacement à une autre région Azure. Cette pratique améliore la résilience si une panne régionale se produit. Pour plus d’informations, consultez Régions prises en charge pour Kubernetes avec Azure Arc.

• Vous devez vous assurer que les services de votre solution sont pris en charge dans la région où Azure Arc est déployé.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification de la révision de conception pour security.

• 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 disposant de privilèges limités pour intégrer des clusters Kubernetes à Azure Arc. Cette pratique est utile dans les pipelines d’intégration continue et de livraison continue tels qu’Azure Pipelines et GitHub Actions. Pour plus d’informations, consultez Créer un principal de service d’intégration 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. Les clusters existants, qui incluent Azure et les clusters locaux, ne peuvent pas être migrés vers des identités managées. Pour plus d’informations, consultez Utiliser une identité managée dans AKS.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’optimisation des coûts.

Pour connaître les considérations générales relatives aux coûts, consultez les principes de conception de l’optimisation des coûts.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’excellence opérationnelle.

• Avant de configurer vos clusters Kubernetes avec Azure Arc, passez en revue les limites d’abonnement Azure Resource Manager et les limites de groupe de ressources à planifier pour le nombre de clusters.

• Utilisez Helm, qui est un outil d’empaquetage open source, pour installer et gérer les cycles de vie des applications Kubernetes. Comme pour les gestionnaires de packages Linux tels que APT et Yum, utilisez Helm pour gérer des graphiques Kubernetes, qui sont des packages de ressources Kubernetes préconfigurées.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

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 AKS
• Documentation Azure Policy
• Documentation Azure Monitor
• Connectez un cluster Kubernetes existant à Azure Arc

Ressources associées

Conseils associés sur l’architecture hybride :

• Conception d’une architecture hybride
• Options hybrides Azure

Architectures connexes :

• architecture de base de référence pour AKS sur Azure Local
• Optimiser l’administration des instances SQL dans les environnements locaux et multiclouds avec Azure Arc