Partager via


Architecture de base de référence Azure Kubernetes Service (AKS) pour AKS sur Azure Local

Azure Kubernetes Service (AKS)
Azure Local
Azure Arc

Ce scénario montre comment concevoir et implémenter une architecture de base pour Microsoft Azure Kubernetes Service (AKS) qui s’exécute sur Azure Local.

Cet article présente des recommandations ayant trait au réseau, la sécurité, l’identité, la gestion et la supervision du cluster en fonction des besoins métier de l’organisation.

Important

Les informations de cet article s’appliquent à AKS sur Azure Local et AKS sur Windows Server. La version la plus récente d’AKS s’exécute sur le système d’exploitation Azure Stack HCI version 23H2. Pour plus d’informations sur la dernière version, consultez AKS sur Azure Local.

Architecture

Diagramme montrant une architecture de base pour Azure Kubernetes Service sur Azure Local.

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

Composants

  • Les composants suivants sont installés sur la périphérie ou localement :

    • Azure Local est une solution de cluster d’infrastructure hyperconvergée (HCI) qui héberge des charges de travail Linux et Windows virtualisées et leur stockage dans un environnement local hybride. Une instance locale Azure se compose d’un cluster pouvant aller de 1 à 16 nœuds.

    • Le pont de ressources Azure Arc est une machine virtuelle hautement disponible qui s’exécute sur Azure Local. Le pont de ressources est responsable du déploiement et de la gestion de plusieurs clusters AKS.

    • AKS sur Azure Local est une implémentation locale d’AKS qui automatise l’exécution d’applications conteneurisées à grande échelle. Un cluster AKS sur Azure Local inclut des nœuds de plan de contrôle hautement disponibles et des nœuds Worker. Les applications conteneurisées s’exécutent sur les nœuds Worker du cluster AKS. Pour obtenir l’isolation des applications, vous pouvez déployer jusqu’à 32 clusters AKS. Le cluster AKS se compose des composants suivants :

      • Le plan de contrôle s’exécute sur Azure Linux et inclut des composants de serveur d’API qui interagissent avec l’API Kubernetes. Il utilise également etcd, qui est un magasin de clé-valeur distribuée, pour stocker toutes les données et la configuration du cluster.

      • Les nœuds Worker s’exécutent sur le système d’exploitation Linux Azure ou sur le système d’exploitation Windows Server. Ils hébergent des applications conteneurisées dans des pods. Les pods représentent une seule instance de votre application et mappent généralement un-à-un avec un conteneur. Toutefois, certains pods incluent plusieurs conteneurs. Les déploiements se composent d’un ou plusieurs pods identiques. Les pods et les déploiements sont regroupés logiquement dans un espace de noms, qui définit l’accès à la gestion de ces ressources.

  • Les composants suivants sont installés sur Azure :

    • Azure Arc est un service cloud qui étend le modèle de gestion basé sur Azure Resource Manager aux ressources non-Azure, y compris les machines virtuelles non Azure, les clusters Kubernetes et les bases de données conteneurisées.

    • Azure Automation fournit un service d’automatisation et de configuration basé sur le cloud qui prend en charge la gestion cohérente dans vos environnements Azure et non Azure.

    • Azure Monitor est un service basé sur le cloud qui optimise la disponibilité et les performances de vos applications et services en fournissant une solution complète pour collecter, analyser et agir sur la télémétrie de vos environnements cloud et locaux.

    • Azure Policy est un service cloud qui permet d’appliquer des normes organisationnelles et d’évaluer la conformité à grande échelle en évaluant Azure, y compris les ressources activées par Azure Arc, aux propriétés de ces ressources aux règles d’entreprise. Ces normes incluent également Azure Policy pour Kubernetes, qui applique des stratégies aux charges de travail qui s’exécutent à l’intérieur du cluster.

    • Microsoft Defender pour Cloud est un système unifié de gestion de la sécurité de l’infrastructure qui renforce la posture de sécurité de vos centres de données et fournit une protection avancée contre les menaces sur vos charges de travail hybrides dans le cloud et localement.

Détails du scénario

Cas d’usage potentiels

  • Implémentez des charges de travail basées sur des conteneurs hautement disponibles dans une implémentation Kubernetes locale d’AKS.

  • Automatisez l’exécution d’applications conteneurisées à grande échelle.

  • Réduire le coût total de possession (TCO) à l’aide de solutions certifiées par Microsoft, d’automatisation basée sur le cloud, de gestion centralisée et de supervision centralisée.

Matériel certifié

Utilisez le matériel certifié local Azure, qui fournit des paramètres UEFI (Secure Boot, United Extensible Firmware Interface) et TPM (Trusted Platform Module) en dehors de la boîte de dialogue. Les exigences de calcul dépendent de l’application et du nombre total de nœuds de plan de contrôle et de nœuds Worker dans tous les clusters AKS qui s’exécutent sur Azure Local. Utilisez plusieurs nœuds physiques pour le déploiement d’Azure Local pour obtenir une haute disponibilité. Tous les serveurs doivent être du même fabricant et du même modèle et utiliser des processeurs intel nehalem de niveau 64 bits, AMD EPYC ou ultérieur compatibles qui prennent en charge la traduction d’adresses de deuxième niveau.

Configuration requise pour le réseau

Kubernetes fournit une couche d’abstraction à la mise en réseau en connectant les nœuds Kubernetes au réseau de superposition virtuel. Il fournit également une connectivité entrante et sortante pour les pods via le composant kube-proxy.

Cette architecture utilise un réseau de superposition virtuelle qui alloue des adresses IP à l’aide de la mise en réseau d’adresses IP statiques. Cette architecture utilise Calico comme fournisseur d’interface réseau de conteneur. La mise en réseau d’adresses IP statiques nécessite des pools d’adresses prédéfinis pour tous les objets du déploiement. Il ajoute des avantages supplémentaires et garantit que la charge de travail et l’application sont toujours accessibles. Un pool d’adresses IP distinct est utilisé pour allouer des adresses IP aux services Kubernetes.

Les spécifications réseau sont définies en tant que réseaux logiques dans Azure Local. Avant de créer les réseaux logiques dans Azure Local, consultez la configuration réseau requise et la planification des adresses IP.

Exigences de stockage

Pour chaque serveur du cluster, utilisez des lecteurs de même type, ayant la même taille et le même modèle. Azure Local fonctionne avec une pièce jointe de technologie avancée série directe, une petite interface système d’ordinateur attachée en série, un express de mémoire nonvolatile ou des lecteurs de mémoire persistants physiquement attachés à un serveur chacun. Pour les volumes de cluster, HCI utilise la technologie de stockage définie par logiciel comme les espaces de stockage direct pour combiner les lecteurs physiques dans le pool de stockage pour la tolérance de panne, l’extensibilité et les performances. Les applications qui s’exécutent dans AKS sur Azure Local s’attendent souvent à ce que les options de stockage suivantes soient disponibles :

  • Les volumes représentent un moyen de stocker, récupérer et conserver des données entre les pods et le cycle de vie de l’application.

  • Les volumes persistants sont une ressource de stockage que l’API Kubernetes crée et gère. Ils peuvent exister au-delà de la durée de vie d’un pod individuel.

Vous pouvez définir des classes de stockage pour différents niveaux et emplacements afin d’optimiser les coûts et les performances. Les classes de stockage prennent en charge le provisionnement dynamique des volumes persistants et définissent reclaimPolicy afin de spécifier l’action de la ressource de stockage sous-jacente pour gérer les volumes persistants lorsque le pod est supprimé.

Créer et gérer AKS sur Azure Local

Vous devez créer et gérer AKS sur Azure Local comme toute autre ressource Azure que vous gérez. Vous pouvez utiliser le portail Azure, Azure CLI, les modèles Azure Resource Manager (modèles ARM) ou Bicep.

Le service Kubernetes avec Azure Arc fournit une représentation Resource Manager d’AKS sur une instance locale Azure. Lorsque vous créez un cluster AKS sur un cluster local Azure, les agents Azure Arc sont automatiquement déployés dans un espace de noms Kubernetes pour collecter les journaux et les métriques et collecter les métadonnées de cluster, la version de Kubernetes et le nombre de nœuds.

Les recommandations suivantes s’appliquent à la plupart des scénarios. Suivez les recommandations, sauf si vous avez un besoin spécifique qui vous oblige à ne pas les suivre. Les services Azure suivants doivent être déployés dans la même région Azure que le cluster AKS :

  • Utilisez l’extension MetalLB pour déployer un équilibreur de charge MetalLB sur le cluster AKS pour l’équilibrage de charge L2.

  • Activez Azure Monitor Container Insights pour surveiller les performances des charges de travail de conteneur qui s’exécutent sur des pools de nœuds Linux et Windows. Il collecte les métriques de mémoire et de processeur à partir de contrôleurs, de nœuds et de conteneurs via l’API de métrique. À l’aide de Container Insights, vous pouvez identifier l’utilisation de la mémoire et du processeur, détecter les performances globales du cluster Kubernetes, comprendre le comportement du cluster et configurer des alertes pour la surveillance proactive.

  • Utilisez les fonctionnalités Automation disponibles pour la gestion de bout en bout. AKS fournit un large éventail de fonctionnalités d’automatisation, notamment les mises à jour du système d’exploitation et les mises à jour complètes telles que les microprogrammes et les pilotes provenant de fournisseurs locaux Azure et de partenaires. Vous pouvez exécuter Windows PowerShell localement à partir de l’une des machines locales Azure ou à distance à partir d’un ordinateur de gestion. L’intégration à Azure Automation et Azure Arc prend en charge divers scénarios d’automatisation pour les charges de travail virtualisées et conteneurisées .

  • Appliquez la gouvernance avec Azure Policy pour appliquer des contrôles de ressources à grande échelle. Azure Policy étend Gatekeeper v3, qui est un webhook de contrôleur d’admission pour Open Policy Agent, afin d’appliquer de manière centralisée des protections sur les composants AKS tels que les pods, les conteneurs et les espaces de noms.

  • Déployez des applications de manière cohérente à l’aide de configurations Flux v2 et d’Azure Policy pour Kubernetes pour obtenir des déploiements évolutifs pilotés par des stratégies. Vous pouvez sélectionner une définition de stratégie intégrée et créer des affectations de stratégie qui ont des paramètres spécifiques pour la configuration de Flux. Pour prendre en charge la séparation des préoccupations, créez plusieurs affectations qui ont différentes configurations flux qui pointent vers des sources distinctes, telles qu’un référentiel Git pour les administrateurs de cluster et un autre référentiel pour les équipes d’applications.

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 Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

  • Implémentez trois à cinq nœuds de plan de contrôle et plusieurs nœuds Worker dans le cluster Kubernetes pour répondre aux exigences de disponibilité minimale pour les applications.

  • Passez en revue les conditions requises pour le clustering de basculement. Les déploiements AKS utilisent le clustering de basculement et la migration dynamique pour assurer la haute disponibilité et la tolérance de panne. La migration dynamique est une fonctionnalité Hyper-V qui vous permet de déplacer en toute transparence des machines virtuelles en cours d’exécution d’un hôte Hyper-V vers un autre hôte sans temps d’arrêt perçu.

  • Configurez les déploiements pour utiliser des fonctionnalités Kubernetes, telles que les déploiements, le mappage d’affinités et les ReplicaSets, pour vous assurer que les pods sont résilients dans les scénarios d’interruption.

  • Limitez l’utilisation des images conteneur publiques et tirez uniquement des registres de conteneurs pour lesquels vous avez le contrôle sur le contrat de niveau de service, tel qu’Azure Container Registry.

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 en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

Concentrez-vous sur l’ensemble de la pile en sécurisant à la fois l’hôte et ses conteneurs.

Infrastructure de sécurité

  • Utilisez le matériel certifié Local Azure qui fournit des paramètres de démarrage sécurisé, UEFI et TPM hors de la boîte de dialogue. Ces technologies, combinées à la sécurité basée sur la virtualisation, aident à protéger les charges de travail sensibles à la sécurité. Pour plus d’informations sur les solutions validées, consultez solutions locales Azure.

  • Utilisez le démarrage sécurisé pour vous assurer que le serveur démarre uniquement les logiciels qu’un fabricant d’équipement d’origine approuve.

  • Utilisez UEFI pour contrôler le processus de démarrage du serveur.

  • Utilisez le module de plateforme sécurisée (TPM) pour stocker les clés de chiffrement et isoler toutes les fonctions matérielles liées à la sécurité.

  • Utilisez le chiffrement de lecteur BitLocker pour chiffrer les volumes directs d’espaces de stockage au repos.

  • Utilisez Defender pour cloud pour gérer les paramètres de sécurité des serveurs et des clusters. Il fournit une protection contre les menaces pour vos clusters Kubernetes avec Azure Arc. L’extension Defender for Cloud collecte des données à partir de nœuds du cluster et les envoie au back-end Azure Defender pour Kubernetes dans le cloud pour une analyse plus approfondie.

  • Utilisez le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour les attributions de rôles et pour gérer l’accès au cluster AKS.

  • Utilisez l’identité de charge de travail pour sécuriser et gérer les identités pour accéder aux ressources Azure à partir de pods de charge de travail.

  • AKS est fourni avec le chiffrement des secrets etcd à l’aide d’un plug-in KMS (Key Management Service). Tous les clusters AKS ont un plug-in KMS intégré activé par défaut. Ce plug-in génère la clé de chiffrement et le fait pivoter automatiquement toutes les 30 jours.

Sécurité des applications

  • Utilisez l’extension du fournisseur secrets Azure Key Vault sur votre instance AKS sur Azure Local pour protéger davantage vos secrets que les différentes applications utilisent en les stockant dans Key Vault.

  • Utilisez Azure Policy pour Kubernetes pour appliquer des stratégies de sécurité de cluster telles qu’aucun pod privilégié.

  • Utilisez une instance container Registry qui contient l’analyse des vulnérabilités dans son dépôt de conteneurs.

Sécurité du conteneur

  • Renforcez l’environnement hôte et démon en supprimant les services inutiles.

  • Ne conservez pas les secrets dans les images et montez-les uniquement via le moteur d’orchestration de conteneur.

  • Sécurisez les images dans une instance container Registry qui prend en charge l’analyse des vulnérabilités et Azure RBAC.

  • Utilisez l’isolation des conteneurs et évitez d’exécuter des conteneurs en mode privilégié pour empêcher les attaquants d’augmenter les privilèges si un conteneur est compromis.

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 contrôle de la révision de la conception pour l'optimisation des coûts.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.

  • Infrastructure en tant que code : Utilisez des modèles ARM, Bicep ou Terraform pour automatiser le déploiement de cluster à grande échelle. Utilisez le portail Azure pour explorer les options disponibles et prises en charge pour la création du cluster et exporter vos sélections en tant que modèle. Passez en revue les modules vérifiés Azure pour une option de déploiement scalable. Pour plus d’informations, consultez le module de service de conteneur hybride sur GitHub.

  • Azure Arc : Intégrez à Azure Arc ou aux services Azure, tels qu’Azure Monitor et Log Analytics, qui fournissent des fonctionnalités de gestion, de maintenance et de résilience supplémentaires.

  • GitOps : Au lieu de configurer manuellement des composants Kubernetes, utilisez des outils automatisés pour appliquer des configurations à un cluster Kubernetes, car ces configurations sont vérifiées dans un référentiel source. Ce processus est souvent appelé GitOps. Les solutions GitOps courantes pour Kubernetes incluent Flux et Argo CD. Dans cette architecture, nous vous recommandons d’utiliser l’extension GitOps fournie par Microsoft, basée sur Flux.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

  • Utilisez du matériel certifié local Azure pour améliorer la durée de fonctionnement et les performances des applications, la gestion simplifiée et les opérations, ainsi que le coût de base inférieur.

  • Comprendre les limites d’AKS sur Azure Local. Microsoft prend en charge AKS sur les déploiements locaux Azure qui ont un maximum de 16 serveurs physiques par cluster, 32 clusters Kubernetes et 200 machines virtuelles.

  • Déterminez AKS sur les exigences locales Azure en fonction du nombre de nœuds de plan de contrôle, de nœuds Worker et de clusters AKS. Pour dimensionner correctement le matériel, prévoyez le nombre de pods, de conteneurs et de nœuds Worker requis pour chaque cluster AKS. Réservez au moins 15% de capacité locale Azure pour prendre en charge les défaillances planifiées et non planifiées.

    Pour améliorer l’efficacité des performances, utilisez des ressources informatiques d’une manière qui répond aux exigences du système tout en conservant cette efficacité à mesure que les changements de demande et les technologies évoluent. En règle générale, si un nœud est hors connexion, qu’il soit en raison d’une maintenance ou d’une défaillance inattendue, les nœuds restants doivent disposer d’une capacité suffisante pour gérer la charge accrue.

  • Passez en revue la logique de placement des nœuds AKS. AKS sur Azure Local distribue les nœuds Worker pour chaque pool de nœuds dans un cluster AKS à l’aide d’une logique de placement local Azure via des groupes à haute disponibilité.

  • Planifiez les réservations d’adresses IP pour configurer des clusters AKS et des services Kubernetes.

  • Implémentez l’optimisation des performances réseau pour l’allocation de bande passante au trafic.

  • Utilisez l’accélération de l’unité de traitement graphique pour les charges de travail étendues.

Contributeurs

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

Principaux auteurs :

Autre contributeur :

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

Étape suivante