Architecture réseau pour AKS sur Azure Stack HCI

Ce scénario montre comment concevoir et implémenter des concepts réseau pour le déploiement de nœuds Azure Kubernetes Service (AKS) sur des clusters AKS.

Cet article contient des recommandations pour la conception réseau pour les nœuds Kubernetes et les conteneurs Kubernetes. Il fait partie d’un ensemble de deux articles destinés à servir de guides pour une base de référence de l’architecture. Consultez les recommandations relatives à l’architecture de référence ici.

Architecture

L’image suivante montre l’architecture réseau pour Azure Kubernetes Service sur des clusters Azure Stack HCI ou Windows Server 2019/2022 Datacenter :

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

Le scénario est constitué des fonctionnalités et des composants suivants :

• Azure Stack HCI (22H2) est une solution de cluster d’infrastructure hyperconvergée qui héberge des charges de travail Windows et Linux virtualisées et leur stockage dans un environnement local hybride. Le cluster Azure Stack HCI est implémenté sous la forme d’un cluster de 2-4 nœuds.
• Un cluster de basculement de centre de données Windows Server 2019/2022 est un groupe d’ordinateurs indépendants qui travaillent conjointement pour accroître la disponibilité et la scalabilité des rôles en cluster.
• Azure Kubernetes Service sur Azure Stack HCI est une implémentation locale d’Azure Kubernetes Service (AKS) qui automatise l’exécution d’applications conteneurisées à grande échelle.
• Active Directory Domain Services est une structure hiérarchique stockant des informations sur les objets du réseau. Il fournit une solution d’identité et d’accès pour les identités associées aux utilisateurs, aux ordinateurs, aux applications ou à d’autres ressources incluses dans une limite de sécurité.
• Le cluster de gestion, également appelé hôte AKS, est responsable du déploiement et de la gestion de plusieurs clusters de charge de travail. Le cluster de gestion consomme 1 adresse IP du pool de nœuds, mais vous devez réserver 2 autres adresses IP pour les opérations de mise à jour. Le cluster de gestion consomme également une adresse IP du pool d’adresses IP virtuelles.
• Le cluster de charge de travail est un déploiement à haute disponibilité de Kubernetes utilisant des machines virtuelles Linux pour l’exécution des composants de plan de contrôle Kubernetes ainsi que des nœuds Worker Linux et/ou Windows.
  • Plan de contrôle. S’exécute sur une distribution Linux et contient des composants de serveur d’API pour l’interaction avec l’API Kubernetes et un magasin de clés-valeurs distribuées, etcd, pour stocker l’ensemble de la configuration et des données du cluster. Il consomme une adresse IP du pool de nœuds et une adresse IP du pool d’adresses IP virtuelles.
  • Équilibreur de charge. S’exécute sur une machine virtuelle Linux et fournit des services à charge équilibrée pour le cluster de charge de travail. Il consomme une adresse IP du pool de nœuds et une adresse IP du pool d’adresses IP virtuelles.
  • Nœuds Worker. S’exécutent sur un système d’exploitation Windows ou Linux qui héberge des applications conteneurisées. Ils consomment des adresses IP du pool de nœuds, mais vous devez planifier au moins 3 adresses IP supplémentaires pour les opérations de mise à jour.
  • Ressources Kubernetes. Les pods représentent une seule instance de votre application, et ont généralement un mappage de type 1:1 avec un conteneur. Certains pods peuvent cependant contenir plusieurs conteneurs. Les déploiements représentent un ou plusieurs pods identiques. Les pods et les déploiements sont regroupés logiquement dans un espace de noms qui contrôle l’accès à la gestion des ressources. Ils consomment 1 adresse IP par pod du pool d’adresses IP virtuelles.
• Azure Arc est un service basé sur le cloud qui étend le modèle de gestion basé sur Azure Resource Manager à des ressources non-Azure, notamment des machines virtuelles, des clusters Kubernetes et des bases de données conteneurisées.
• Azure Policy est un service basé sur le cloud qui évalue les ressources Azure et locales via l’intégration à Azure Arc en comparant les propriétés à des règles métier personnalisables.
• 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.
• Microsoft Defender pour le cloud est un système de gestion de la sécurité de l’infrastructure unifié qui renforce la posture de sécurité de vos centres de données et fournit une protection avancée contre les menaces pour vos charges de travail hybrides dans le cloud et locales.

Composants

• Azure Stack HCI (20H2)
• Cluster de basculement Windows Server 2019/2022 Datacenter
• Azure Kubernetes Service (AKS)
• Windows Admin Center
• Un abonnement Azure
• Azure Arc
• Contrôle d’accès en fonction du rôle Azure (RBAC)
• Azure Monitor
• Microsoft Defender pour le cloud

Détails du scénario

Les cas d’usage pour ce scénario sont décrits dans le premier article de la série, Architecture de référence.

Réseau des nœuds Kubernetes

La principale considération dans la conception réseau pour AKS sur Azure Stack HCI est le choix d’un modèle réseau qui fournit suffisamment d’adresses IP. AKS sur Azure Stack HCI utilise la mise en réseau virtuelle pour allouer des adresses IP aux ressources de nœud Kubernetes. Vous pouvez utiliser deux modèles d’affectation d’adresses IP :

• La mise en réseau IP statique est plus prévisible, mais demande du travail en plus pour la configuration initiale.
• La mise en réseau DHCP (Dynamic Host Configuration Protocol) utilise l’allocation dynamique des adresses IP et moins de travail, mais vous devez veiller à ne pas épuiser le pool d’adresses IP disponibles. Vous devez également gérer les réservations et des plages d’exclusion pour les pools d’adresses IP virtuelles et certaines ressources à l’échelle du cluster, comme le service d’Agent cloud.

Les deux modèles d’affectation doivent planifier des adresses IP pour les pools suivants :

• Pool d’adresses IP virtuelles
• Pool d’adresses IP de machines virtuelles de nœud Kubernetes

Pool d’adresses IP virtuelles

Un pool d’adresses IP virtuelles est un ensemble d’adresses IP qui sont obligatoires pour tout déploiement d’AKS sur Azure Stack HCI. Planifiez le nombre d’adresses IP dans le pool d’adresses IP virtuelles en fonction du nombre de clusters de charge de travail et de services Kubernetes. Le pool d’adresses IP virtuelles fournit des adresses IP pour les types de ressources suivants :

• L’Agent cloud nécessite une adresse IP flottante du pool d’adresses IP virtuelles.

• Le composant serveur d’API qui s’exécute à l’intérieur de la machine virtuelle Kubernetes Virtual Appliance (KVA) (cluster de gestion) utilise une adresse IP du pool d’adresses IP virtuelles. Le serveur d’API est un composant du plan de contrôle Kubernetes qui expose l’API Kubernetes. Le serveur d’API est le front-end du plan de contrôle Kubernetes. L’appliance KVA est une machine virtuelle exécutant Mariner Linux et qui héberge un cluster Kubernetes. L’adresse IP est flottante et est également utilisée pour les autres machines virtuelles KVA que vous déployez dans AKS sur Azure Stack HCI. La machine virtuelle KVA héberge également un service d’équilibreur de charge d’adresses IP virtuelles Kubernetes.

• Planifiez l’adressage IP pour le nombre de machines virtuelles du plan de contrôle déployées sur les serveurs cibles, car elles consomment également davantage d’adresses IP du pool d’adresses IP virtuelles. La section suivante décrite des considérations à ce sujet.

• Le cluster cible contient une machine virtuelle d’équilibreur de charge, qui est HAProxy et détient le pool d’adresses IP virtuelles pour le cluster cible. Cette machine virtuelle expose tous les services Kubernetes via le pool d’adresses IP virtuelles.

• Les applications qui s’exécutent dans des pods Kubernetes utilisent des adresses IP du pool d’adresses IP virtuelles.

• L’équilibreur de charge HAProxy est déployé en tant que machine virtuelle spécialisée et peut être utilisé pour équilibrer la charge des demandes entrantes entre plusieurs points de terminaison. Ils consomment des adresses IP du pool d’adresses IP virtuelles, et vous devez planifier l’adressage IP pour chaque cluster de charge de travail.

Pool d’adresses IP de machines virtuelles de nœud Kubernetes

Les nœuds Kubernetes sont déployés en tant que machines virtuelles dans un déploiement d’AKS sur Azure Stack HCI. Veillez à planifier le nombre d’adresses IP en fonction du nombre total de nœuds Kubernetes et incluez au moins trois adresses IP supplémentaires qui sont utilisées pendant le processus de mise à niveau. Pour la configuration d’adresses IP statiques, vous devez spécifier la plage du pool d’adresses IP des machines virtuelles des nœuds Kubernetes, ce qui n’est pas nécessaire pour l’allocation DHCP. Planifiez des adresses IP supplémentaires pour :

• La machine virtuelle KVA utilise également plus d’adresse IP pour Kubernetes du pool d’adresses IP de machine virtuelle de nœud Kubernetes. Prévoyez d’ajouter des adresses IP pendant le processus de mise à jour, car la machine virtuelle KVA utilise la même adresse IP virtuelle pour le service d’API, mais nécessite une adresse IP distincte du pool d’adresses IP de machine virtuelle de nœud Kubernetes.
• Les machines virtuelles du plan de contrôle consomment une adresse IP du pool d’adresses IP de machine virtuelle de nœud Kubernetes pour le service de serveur d’API. Ces machines virtuelles hébergent également l’Agent Azure ARC qui se connecte au portail Azure à des fins de gestion.
• Les nœuds d’un pool de nœuds (Linux ou Windows) vont consommer des adresses IP du pool d’adresses IP alloué à la machine virtuelle de nœud Kubernetes.

Service cloud local Microsoft

Planifiez la plage d’adresses IP pour le cloud local Microsoft (MOC), qui active la pile de gestion afin que les machines virtuelles sur Azure Stack HCI soient gérées dans le cloud. L’allocation d’adresses IP dépend pour le service cloud Microsoft se fait sur le réseau physique sous-jacent, et les adresses IP configurées pour les nœuds de cluster Azure Stack HCI sont dans votre centre de données. Vous pouvez configurer des adresses IP pour les nœuds physiques de votre instance Azure Stack HCI dans un des emplacements suivants :

• Des nœuds de cluster Azure Stack HCI avec un modèle d’allocation d’adresses IP DHCP. Le service cloud Microsoft reçoit une adresse IP du service DHCP présenté sur le réseau physique.
• Des nœuds de cluster Azure Stack HCI avec un modèle d’allocation d’adresses IP statiques. L’adresse IP du service cloud Microsoft doit être spécifiée explicitement en tant que plage d’adresses IP au format CIDR (Classless Inter-Domain Routing) et doit se trouver dans le même sous-réseau que les adresses IP des nœuds de cluster Azure Stack HCI.

Équilibreur de charge dans AKS sur Azure Stack HCI

Pour un petit déploiement, vous pouvez utiliser l’équilibreur de charge intégré, déployé en tant que machine virtuelle Linux qui utilise HAProxy + KeepAlive pour envoyer le trafic aux services d’application déployés dans le cadre du cluster AKS. L’équilibreur de charge HAProxy configure les pods en tant que points de terminaison dans l’équilibreur de charge. Il équilibre la charge des demandes sur le serveur d’API Kubernetes et gère le trafic vers les services d’application.

Vous pouvez également utiliser un équilibreur de charge personnalisé pour gérer le trafic vers vos services. L’équilibreur de charge personnalisé offre une flexibilité supplémentaire au déploiement et garantit qu’AKS sur Azure Stack HCI fonctionne avec les déploiements existants, comme les déploiements SDN (Software Defined Network) qui utilisent des équilibreurs de charge. Pour les équilibreurs de charge personnalisés, kube-vip fournit aux clusters Kubernetes une adresse IP virtuelle et un équilibreur de charge pour le plan de contrôle et les services Kubernetes de type LoadBalancer. Le service kube-vip est déployé automatiquement sur chaque nœud Worker.

AKS sur Azure Stack HCI prend également en charge l’utilisation de MetalLB ou d’autres équilibreurs de charge basés sur OSS Kubernetes pour équilibrer le trafic destiné aux services dans un cluster de charge de travail. MetalLB est une implémentation d’équilibreur de charge pour les clusters Kubernetes nus, utilisant des protocoles de routage standard, comme le protocole BGP (Border Gateway Protocol). Il peut fonctionner avec des modules complémentaires réseau, Calico et Flannel, mais vous devez veiller à ce que la plage d’adresses IP virtuelle fournie lors de l’installation d’AKS sur Azure Stack HCI ne chevauche pas la plage d’adresses IP prévue pour l’équilibreur de charge personnalisé.

Déployer ce scénario

Déployer un contrôleur d’entrée

Envisagez d’implémenter un contrôleur d’entrée pour la terminaison TLS, le proxy réversible ou le routage de trafic configurable. Les contrôleurs d’entrée fonctionnent au niveau de la couche 7 et peuvent utiliser des règles intelligentes pour distribuer le trafic des applications. Des ressources d’entrée Kubernetes sont utilisées pour configurer les règles d’entrée et les itinéraires des services Kubernetes individuels. Quand vous définissez un contrôleur d’entrée, vous regroupez les règles de routage du trafic dans une même ressource qui s’exécute dans le cadre de votre cluster.

Utilisez le contrôleur d’entrée pour exposer des services via des URL accessibles de l’extérieur. L’entrée expose des routes HTTP et HTTPS depuis l’extérieur du cluster vers les services situés à l’intérieur du cluster. Le routage du trafic est contrôlé par des règles définies sur la ressource d’entrée. Les règles HTTP d’entrée contiennent les informations suivantes :

• Un hôte facultatif. Si vous ne fournissez pas d’informations sur l’hôte, la règle est appliquée à tout le trafic HTTP entrant.
• Une liste de chemins qui a un back-end associé défini avec un service.name et un service.port.name ou un service.port.number.
• Un back-end qui fournit une combinaison de noms de service et de port.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: test.example.com
     http:
       paths:
       - path: /hello-world
          pathType: Prefix
          backend:
            service:
              name: hello-world
              port:
                 number: 8080

Utilisez un contrôleur d’entrée pour équilibrer le trafic entre les différents back-ends de l’application. Le trafic est fractionné et envoyé à différents points de terminaison et déploiements de service, en fonction des informations de chemin.

Pour router le trafic HTTP vers plusieurs noms d’hôte sur la même adresse IP, vous pouvez utiliser une ressource d’entrée différente pour chaque hôte. Le trafic qui passe par l’adresse IP de l’équilibreur de charge est routé en fonction du nom d’hôte et du chemin fourni dans la règle d’entrée.

Concepts de mise en réseau de conteneurs dans Azure Kubernetes Service (AKS) sur Azure Stack HCI

Kubernetes fournit une couche d’abstraction à un réseau virtuel, afin que les applications basées sur des conteneurs puissent communiquer en interne ou en externe. Le composant kube-proxy s’exécute sur chaque nœud et peut fournir un accès direct au service, distribuer le trafic en utilisant des équilibreurs de charge ou utiliser des contrôleurs d’entrée pour le routage d’applications plus complexe. Kubernetes utilise des services pour regrouper logiquement un ensemble de pods et fournir une connectivité réseau. Les services Kubernetes suivants sont disponibles :

• Adresse IP du cluster : ce service crée une adresse IP interne pour les applications internes uniquement.
• NodePort : ce service crée un mappage de port sur le nœud sous-jacent, ce qui rend l’application directement accessible avec l’adresse IP et le port du nœud.
• LoadBalancer : vous pouvez exposer les services Kubernetes en externe en utilisant des règles d’équilibreur de charge ou un contrôleur d’entrée.
• ExternalName : Ce service utilise une entrée DNS spécifique pour l’application Kubernetes.

Réseaux Kubernetes

Dans AKS sur Azure Stack HCI, le cluster peut être déployé en utilisant un des modèles réseau suivants :

• Réseau du projet Calico. C’est un modèle de réseau par défaut pour AKS sur Azure Stack HCI basé sur un réseau open source qui assure la sécurité réseau pour les conteneurs, les machines virtuelles et les charges de travail natives basées sur un hôte. La stratégie réseau Calico peut être appliquée à n’importe quel type de point de terminaison, comme des pods, des conteneurs, des machines virtuelles ou des interfaces hôtes. Chaque stratégie se compose de règles qui contrôlent le trafic d’entrée et de sortie en utilisant des actions qui peuvent autoriser, refuser, journaliser ou transmettre le trafic entre les points de terminaison source et de destination. Calico peut utiliser le filtre de paquets Berkeley étendu Linux (eBPF) ou le pipeline réseau du noyau Linux pour la distribution du trafic. Calico est également pris en charge sur Windows avec le service HNS (Host Networking Service) pour la création d’espaces de noms réseau par point de terminaison de conteneur. Dans le modèle réseau Kubernetes, chaque pod reçoit sa propre adresse IP qui est partagée entre les conteneurs au sein de ce pod. Les pods communiquent sur le réseau en utilisant les adresses IP des pods et l’isolation est définie en utilisant des stratégies réseau. Calico utilise des plug-ins CNI (Container Network Interface) pour ajouter ou supprimer des pods dans le réseau de pods Kubernetes, et des plug-ins IPAM (IP Address Management) CNI pour l’allocation et la libération des adresses IP.
• Réseau de superposition Flannel. Flannel crée une couche réseau virtuelle qui se superpose au réseau hôte. Le réseau de superposition utilise l’encapsulation des paquets réseau sur le réseau physique existant. Flannel simplifie la gestion des adresses IP (IPAM), prend en charge la réutilisation des adresses IP entre différentes applications et espaces de noms, et fournit une séparation logique des réseaux de conteneurs du réseau sous-jacent utilisé par les nœuds Kubernetes. L’isolation réseau est obtenue avec VXLAN (Virtual eXtensible Local Area Network), un protocole d’encapsulation qui fournit une connectivité au centre de données en utilisant le tunneling pour étendre les connexions de la couche 2 sur un réseau de la couche 3 sous-jacent. Flannel est pris en charge à la fois par les conteneurs Linux en utilisant DaemonSet et par les conteneurs Windows en utilisant le plug-in Flannel CNI.

Conception du réseau pour Azure Stack HCI

La conception globale du réseau comprend des activités de planification pour Azure Stack HCI.

Commencez par planifier le matériel et l’installation d’Azure Stack HCI. Vous pouvez acheter des systèmes intégrés auprès d’un partenaire Microsoft vendant du matériel avec le système d’exploitation Azure Stack HCI préinstallé, ou bien acheter des nœuds validés et installer le système d’exploitation vous-même. Azure Stack HCI est conçu comme un hôte de virtualisation : les rôles de serveur Kubernetes doivent donc s’exécuter dans les machines virtuelles.

Exigences liées aux réseaux physiques pour Azure Stack HCI

Microsoft ne certifie pas les commutateurs réseau, mais il a certaines exigences que le fournisseur de l’équipement doit satisfaire :

• Standard : IEEE 802.1Q qui définit un réseau local virtuel (VLAN).
• Standard : IEEE 802.1Qbb qui définit le contrôle des flux prioritaires (PFC, Priority Flow Control).
• Standard : IEEE 802.1Qaz qui définit la sélection de transmission améliorée (ETS, Enhanced Transmission Selection).
• Standard : IEEE 802.1AB qui définit le protocole LLTD (Link Layer Topology Discovery).

Exigences liées aux réseaux d’hôtes pour Azure Stack HCI

Envisagez d’utiliser une carte réseau qui a obtenu la certification Windows Server Software-Defined Data Center (SDDC) avec la qualification supplémentaire (AQ) Standard ou Premium.

Vérifiez que la carte réseau prend en charge les éléments suivants :

• Dynamic VMMQ ou d.VMMQ (Dynamic Virtual Machine Multi-Queue) est une technologie intelligente côté réception pour l’optimisation automatique du traitement du trafic réseau sur les cœurs de processeur.
• RDMA (Remote Direct Memory Access) est un déchargement de pile réseau sur la carte réseau. Cela permet au trafic de stockage SMB de contourner le système d’exploitation pour traitement.
• La fonctionnalité RDMA invité permet aux charges de travail SMB pour machines virtuelles de bénéficier des avantages offerts par la technologie RDMA sur les hôtes.
• SET (Switch Embedded Teaming) est une technologie de mise en équipe par voie logicielle.

Envisagez d’utiliser Network ATC, qui fournit un contrôle basé sur l’intention pour simplifier la configuration réseau de l’hôte.

AKS sur Azure Stack HCI nécessite une connexion réseau fiable à bande passante élevée et à faible latence entre chaque nœud serveur. Vérifiez qu’au moins une carte réseau est disponible et dédiée à la gestion du cluster. Vérifiez aussi que les commutateurs physiques de votre réseau sont configurés pour autoriser le trafic sur tous les réseaux locaux virtuels que vous allez utiliser.

Commutateur virtuel

Azure Stack HCI simplifie la conception du réseau en configurant un commutateur virtuel qui peut être utilisé pour la classification réseau. La carte d’interface réseau virtuelle (vNIC) peut être placée dans différents réseaux locaux virtuels pour les hôtes afin de fournir un flux de trafic différent pour les réseaux suivants :

• Réseau de gestion. Le réseau de gestion fait partie du réseau Nord-Sud et est utilisé pour la communication de l’hôte.
• Réseau de calcul. Le réseau de calcul fait partie du réseau Nord-Sud et est utilisé pour le trafic des machines virtuelles. Utilisez QoS (Qualité de service), SR-IOV (Single-Root I/O Virtualization) et vRDMA (Accès direct à la mémoire virtuelle virtuel) pour optimiser les performances réseau en fonction de la demande.
• Réseau de stockage. Le réseau de stockage fait partie du réseau est-ouest et nécessite RDMA avec un débit recommandé de plus de 10 Go. Il est utilisé pour la migration dynamique des machines virtuelles.
• Réseau d’invité de machine virtuelle.

Avantage du trafic Est-Ouest du trafic RDMA

Le trafic réseau Est-Ouest représente la communication entre les hôtes et n’expose aucun accès externe. Le trafic reste dans le commutateur ToR (Top of Rack) et la limite de la couche 2. Il inclut les types de trafic suivants :

• Pulsations de cluster et communication entre nœuds
• [SMB] Cache au niveau du bus de stockage
• [SMB] Volume partagé de cluster
• [SMB] Reconstruction du stockage

Trafic Nord-Sud

Le trafic Nord-Sud est le trafic externe qui atteint le cluster AKS sur Azure Stack HCI. Vous pouvez planifier le trafic pour la gamme de services Azure qui permettent la supervision, la facturation et la gestion de la sécurité via l’intégration d’Azure ARC. Le trafic Nord-Sud a les caractéristiques suivantes :

• Le trafic va d’un commutateur ToR vers la branche centrale ou inversement.
• Le trafic quitte le rack physique ou franchit une limite de la couche 3 (IP).
• Le trafic comprend le trafic de gestion (PowerShell, Windows Admin Center), le trafic de calcul (machine virtuelle) et le trafic de cluster étendu intersite.
• Il utilise un commutateur Ethernet pour la connectivité au réseau physique.

AKS sur Azure Stack HCI peut utiliser plusieurs options de déploiement réseau de cluster :

• Réseau convergé combinant plusieurs intentions réseau (MGMT, Calcul, Stockage). C’est le déploiement recommandé pour plus de trois nœuds physiques et il nécessite que toutes les cartes réseau physiques soient connectées aux mêmes commutateurs ToR. ROCEv2 est fortement recommandé.
• Le déploiement sans commutateur utilise la communication Nord-Sud en tant qu’équipe réseau en combinant des réseaux de calcul et de gestion.
• Déploiement hybride en tant que combinaison des deux déploiements.

Recommandations

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.

Recommandations pour le réseau

La principale préoccupation dans la conception réseau pour AKS sur Azure Stack HCI est le choix d’un modèle réseau qui fournit suffisamment d’adresses IP pour votre cluster Kubernetes, et pour ses services et applications.

• Envisagez d’implémenter des adresses IP statiques pour permettre à AKS sur Azure Stack HCI de contrôler l’attribution des adresses IP.

• Dimensionnez correctement les plages d’adresses IP afin d’avoir suffisamment d’adresses IP libres pour un pool de nœuds Kubernetes et pour un pool d’adresses IP virtuelles. Vérifiez que votre pool d’adresses IP virtuelles est suffisamment grand pour que, chaque fois que vous effectuez une mise à niveau, vous puissiez utiliser des mises à niveau propagées, qui nécessitent davantage d’adresses IP. Vous pouvez planifier les opérations suivantes :

  • Adressage/noms d’hôte pour les paramètres de proxy
  • Adresses IP pour le plan de contrôle du cluster cible
  • Adresses IP pour Azure ARC
  • Adresses IP pour la mise à l’échelle horizontale des nœuds Worker et du plan de contrôle dans les clusters cibles

• Votre pool d’adresses IP virtuelles doit être suffisamment grand pour prendre en charge le déploiement des services d’application qui nécessitent une connectivité au routeur externe.

• Implémentez Calico CNI pour fournir une stratégie réseau améliorée pour contrôler la communication des pods et des applications.

• Vérifiez que les nœuds de cluster physiques (HCI ou Windows Server) se trouvent dans le même rack et sont connectés aux mêmes commutateurs ToR.

• Désactivez IPv6 sur toutes les cartes réseau.

• Vérifiez que le commutateur virtuel existant et son nom sont identiques sur tous les nœuds de cluster.

• Vérifiez que tous les sous-réseaux que vous définissez pour le cluster sont routables entre eux et vers Internet.

• Vérifiez qu’il existe une connectivité réseau entre les hôtes Azure Stack HCI et les machines virtuelles du locataire.

• Activez les mises à jour DNS dynamiques dans votre environnement DNS pour autoriser AKS sur Azure Stack HCI à inscrire le nom de cluster générique de l’Agent cloud dans le système DNS pour la découverte.

• Envisagez d’implémenter la classification du trafic réseau selon sa direction :

  • Le trafic Nord-Sud est le trafic provenant d’Azure Stack HCI et du reste du réseau,
    • Gestion
    • Compute
    • Trafic de cluster étendu intersite
  • Trafic Est-Ouest au sein d’Azure Stack HCI :
    • Trafic de stockage, y compris la migration dynamique entre les nœuds du même cluster.
    • Commutateur Ethernet ou connexion directe.

Modèles de trafic de stockage

• Utilisez plusieurs sous-réseaux et réseaux VLAN pour séparer le trafic de stockage dans Azure Stack HCI.
• Envisagez d’implémenter l’allocation de bande passante du trafic de différents types de trafic.

Considérations

Le Microsoft Azure Well-Architected Framework est un ensemble de principes directeurs qui sont suivis dans ce scénario. Les considérations suivantes s’inscrivent dans le contexte de ces principes.

Fiabilité

• Résilience intégrée, inhérente au calcul défini par logiciel Microsoft (cluster de basculement des nœuds Hyper-V), au stockage (résilience imbriquée des espaces de stockage direct) et au réseau (Software-Defined Networking).
• Envisagez de sélectionner le commutateur réseau qui prend en charge les standards du secteur et garantit des communications fiables entre les nœuds. Les standards suivants incluent :
  • Standard : IEEE 802.1Q
  • Standard : IEEE 802.1Qbb
  • Standard : IEEE 802.1 Qas
  • Standard : IEEE 802.1 AB
• Envisagez d’implémenter plusieurs hôtes dans le cluster de gestion et dans le cluster Kubernetes pour satisfaire au niveau minimal de disponibilité pour les charges de travail.
• AKS sur Azure Stack HCI utilise 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, sans temps d’arrêt perçu.
• Vous devez vous assurer que les services référencés dans la section Architecture sont pris en charge dans la région où vous déployez Azure Arc.

Sécurité

• Sécurisez le trafic entre pods en utilisant des stratégies réseau dans AKS sur Azure Stack HCI.
• Le serveur d’API dans AKS sur Azure Stack HCI contient l’autorité de certification qui signe les certificats pour la communication du serveur d’API Kubernetes vers kubelet.
• Utilisez l’authentification unique Microsoft Entra pour créer une connexion sécurisée au serveur d’API Kubernetes.
• 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.

Optimisation des coûts

• Utilisez la calculatrice de prix Azure pour estimer les coûts des services utilisés dans l’architecture. D’autres bonnes pratiques sont décrites dans la section Optimisation des coûts de Microsoft Azure Well-Architected Framework.
• Envisagez d’implémenter l’Hyper-Threading sur votre ordinateur physique pour optimiser le coût, car l’unité de facturation d’AKS sur Azure Stack HCI est un cœur virtuel.
• La fonctionnalité de plan de contrôle Azure Arc est fournie sans frais supplémentaires. Ceci inclut la prise en charge de l’organisation des ressources via des groupes d’administration et des étiquettes Azure ainsi que le contrôle d’accès via le contrôle d’accès via Azure RBAC. Les services Azure utilisés conjointement à des serveurs avec Azure Arc entraînent des coûts en fonction de leur utilisation.
• Pour des raisons de rentabilité, l’utilisation de deux nœuds de cluster avec seulement quatre disques et 64 Go de mémoire par nœud est suffisante. Pour réduire davantage les coûts, vous pouvez utiliser des interconnexions sans commutateur entre les nœuds, éliminant ainsi le besoin de périphériques de commutation redondants.

Excellence opérationnelle

• Gestion simplifiée en utilisant Windows Admin Center. Windows Admin Center est l’interface utilisateur permettant de créer et gérer AKS sur Azure Stack HCI. Il peut être installé sur une machine virtuelle Windows 10/11 ou Windows Server qui doit être inscrite dans Azure et qui se trouve dans le même domaine que le cluster Azure Stack HCI ou Windows Server Datacenter.
• Intégration à Azure Arc ou à une gamme de services Azure qui fournissent davantage de fonctionnalités de gestion, de maintenance et de résilience (Azure Monitor, Sauvegarde Azure).
• Si votre cluster Kubernetes est attaché à Azure Arc, vous pouvez gérer votre cluster Kubernetes à l’aide de GitOps. Pour passer en revue les bonnes pratiques pour la connexion d’un cluster Kubernetes hybride à Azure Arc, consultez le scénario Gestion et déploiement d’Azure Arc hybride pour les clusters Kubernetes.
• La plateforme Azure Stack HCI permet également de simplifier la mise en réseau virtuelle pour les clusters AKS sur Azure Stack HCI en fournissant le réseau « sous-jacent » avec une haute disponibilité.

Efficacité des performances

• Utilisez du matériel certifié Azure Stack HCI pour améliorer la durée de bon fonctionnement et les performances des applications, simplifier la gestion et l’exploitation, et réduire le coût total de possession.
• Stockage : Espaces de stockage direct
  • Configuration de volume (miroir bidirectionnel imbriqué par rapport à la parité imbriquée accélérée par miroir)
  • Configuration du disque (mise en cache, niveaux)
• Vérifiez que les nœuds de cluster physiques se trouvent physiquement dans le même rack et sont connectés aux mêmes commutateurs ToR.
• Planifiez des réservations d’adresses IP pour configurer des hôtes AKS, des clusters de charge de travail, des serveurs d’API de cluster, des services Kubernetes et des services d’application. Microsoft recommande de réserver un minimum de 256 adresses IP pour le déploiement d’AKS sur Azure Stack HCI.
• Envisagez d’implémenter un contrôleur d’entrée qui fonctionne au niveau de la couche 7 et utilise des règles plus intelligentes pour distribuer le trafic d’application.
• Utilisez l’accélération GPU pour les charges de travail étendues.

Contributeurs

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

Principaux auteurs :

• Lisa DenBeste | Project Management Program Manager
• Kenny Harder | Project Manager
• Mike Kostersitz | Principal Program Manager Lead
• Meg Olsen | Principal
• Nate Waters | Product Marketing Manager

Autres contributeurs :

• Walter Oliver | Senior Program Manager

Étapes suivantes

• Vue d’ensemble d’AKS

Ressources associées

• Architecture de référence pour AKS sur Azure Stack HCI