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

Arc
Kubernetes Service
Monitor
Stratégie
Contrôle d’accès en fonction du rôle Azure

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

Diagramme de topologie Azure Arc pour Kubernetes.

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) Azure Active Directory (Azure AD). 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 appliquer une configuration de cluster

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/sourceControlConfigurations 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 configuration sourceControlConfiguration qui est créée. Lorsque l’attribution est créée, le moteur de stratégie identifie toutes les ressources connectedCluster ou managedCluster qui se trouvent dans l’étendue, puis applique la configuration sourceControlConfiguration à chacune d’entre elles.

Si vous utilisez plusieurs dépôts GitHub pour chaque cluster (par exemple, un dépôt pour l’opérateur IT/de cluster 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 dépôt Git distinct.

Pour plus d’informations, consultez Utiliser Azure Policy pour appliquer des configurations de cluster à grande échelle.

Déploiement et application de GitOps à l’aide d’Azure Policy

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 Git. 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. Azure Policy et Flux fonctionnent ensemble pour proposer GitOps sur les clusters Kubernetes avec Azure Arc.

La connexion entre votre cluster et un ou plusieurs référentiels Git est suivie dans Azure Resource Manager en tant que ressource d’extension sourceControlConfiguration. Les propriétés de la ressource sourceControlConfiguration indiquent où et comment les ressources Kubernetes doivent circuler de Git vers votre cluster. Les données sourceControlConfiguration sont stockées et chiffrées au repos dans une base de données Azure Cosmos DB pour garantir leur confidentialité.

Le config-agent qui s’exécute dans votre cluster est chargé de surveiller les ressources d’extension sourceControlConfiguration nouvelles ou mises à jour sur la ressource Kubernetes avec Azure Arc, de déployer un opérateur de flux pour surveiller le dépôt Git et de propager toutes les mises à jour qui sont apportées au sourceControlConfiguration. Il est même possible de créer plusieurs ressources sourceControlConfiguration en utilisant une étendue namespace sur le même cluster Kubernetes avec Azure Arc afin d’obtenir une architecture multilocataire. Dans ce cas, chaque opérateur peut déployer des configurations uniquement dans son espace de noms respectif.

Le référentiel Git peut contenir toutes sortes de 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 Git 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 monitoring, 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. Azure Policy peut automatiser la création d’un sourceControlConfiguration avec un ensemble spécifique de paramètres sur toutes les ressources Kubernetes avec Azure Arc dans une étendue (abonnement ou groupe de ressources).

Pour plus d’informations, consultez Déployer des configurations à l’aide de GitOps sur un cluster Kubernetes avec Arc.

Topologie, réseau et routage

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

Point de terminaison (DNS) Description
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é à un point de terminaison Git que vous spécifiez.
https://login.microsoftonline.com:443 Requis pour extraire et mettre à jour des jetons Azure Resource Manager.
https://azurearcfork8s.azurecr.io:443 Requis pour extraire des images conteneurs pour les agents 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 à Kubernetes avec Azure Arc dans des environnements Azure et locaux qui utilisent des identités Azure Active Directory (Azure AD). 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.

Contributeurs

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

Auteur principal :

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

Étapes suivantes

Conseils associés sur l’architecture hybride :

Architectures connexes :