Concepts réseau pour le déploiement de nœuds AKS

Article
02/17/2024

S’applique à : AKS sur Azure Stack HCI 22H2, AKS sur Windows Server

Vous pouvez choisir entre deux modèles d’attribution d’adresses IP pour votre architecture réseau pour AKS activé par Azure Arc. AKS prend en charge plusieurs options de déploiement pour Azure Kubernetes Service (AKS).

Réseau IP statique : le réseau virtuel alloue des adresses IP statiques au serveur d’API de cluster Kubernetes, aux nœuds Kubernetes, aux machines virtuelles sous-jacentes, aux équilibreurs de charge et aux services Kubernetes qui s’exécutent sur le cluster.
Réseau DHCP : le réseau virtuel alloue des adresses IP dynamiques aux nœuds Kubernetes, aux machines virtuelles sous-jacentes et aux équilibreurs de charge à l’aide d’un serveur DHCP. Des adresses IP statiques sont toujours allouées au serveur d’API de cluster Kubernetes et à tous les services Kubernetes que vous exécutez sur votre cluster.

Notes

L’architecture de mise en réseau virtuelle définie ici pour AKS Arc peut être différente de l’architecture réseau physique sous-jacente dans un centre de données.

Pool d’adresses IP virtuelles

Un pool d’adresses IP virtuelles (VIP) est un ensemble d’adresses IP obligatoires pour tout déploiement dans AKS Arc. Le pool d’adresses IP virtuelles est une plage d’adresses IP réservées utilisées pour allouer des adresses IP au serveur d’API de cluster Kubernetes. Il garantit l’accessibilité à tout moment de vos applications sur les services Kubernetes. Sachez que quels que soient le modèle réseau virtuel et le modèle d’attribution d’adresses que vous choisissez, vous devez fournir un pool VIP pour le déploiement de votre hôte AKS.

Le nombre d’adresses IP comprises dans le pool d’adresses IP virtuelles dépend du nombre de clusters de charge de travail et de services Kubernetes planifiés pour votre déploiement.

Selon votre modèle de mise en réseau, la définition du pool d’adresses IP virtuelles diffère des manières suivantes :

Adresse IP statique : si vous utilisez une adresse IP statique, assurez-vous que vos adresses IP virtuelles proviennent du même sous-réseau fourni.
DHCP : si votre réseau est configuré avec DHCP, collaborez avec votre administrateur réseau pour exclure la plage d’adresses IP du pool VIP de l’étendue DHCP utilisée pour le déploiement AKS sur Azure Stack HCI.

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

Les nœuds Kubernetes sont déployés en tant que machines virtuelles spécialisées dans AKS Arc. AKS alloue des adresses IP à ces machines virtuelles pour permettre la communication entre les nœuds Kubernetes.

Adresse IP statique : vous devez spécifier une plage de pool d’adresses IP de machines virtuelles de nœuds Kubernetes. Le nombre d’adresses IP de cette plage dépend du nombre total de nœuds Kubernetes que vous prévoyez d’utiliser pour le déploiement sur l’hôte AKS et les clusters Kubernetes de charges de travail. N’oubliez pas que les mises à jour consomment une à trois adresses IP supplémentaires pendant la mise à jour.
DHCP : vous n’avez pas besoin de spécifier un pool de machines virtuelles de nœuds Kubernetes, car les adresses IP des nœuds Kubernetes sont allouées dynamiquement par le serveur DHCP sur votre réseau.

Réseau virtuel avec réseau d’adresses IP statiques (recommandé)

Ce modèle de mise en réseau crée un réseau virtuel qui alloue à tous les objets de votre déploiement des adresses IP statiques à partir d’un pool d’adresses défini de manière statique. L’autre avantage que présente l’utilisation d’un réseau IP statique est que les déploiements et les charges de travail d’application de longue durée restent toujours accessibles.

Lorsque vous définissez un réseau virtuel avec des configurations d’adresses IP statiques, spécifiez les paramètres suivants :

Important

Cette version d’AKS n’autorise aucune modification de la configuration réseau une fois l’hôte AKS ou le cluster de charge de travail déployé. Pour modifier les paramètres de mise en réseau, vous devez commencer à nouveau en supprimant le ou les cluster(s) de charge de travail et en désinstallant AKS.

Nom : nom de votre réseau virtuel.
Préfixe d’adresse : préfixe d’adresse IP à utiliser pour votre sous-réseau.
Passerelle : adresse IP de la passerelle par défaut du sous-réseau.
Serveur DNS : tableau d’adresses IP pointant vers les serveurs DNS à utiliser pour le sous-réseau. Vous pouvez spécifier entre un et trois serveurs.
Pool de machines virtuelles de nœud Kubernetes : plage continue d’adresses IP à utiliser pour les machines virtuelles de votre nœud Kubernetes.
Pool d’adresses IP virtuelles : plage continue d’adresses IP à utiliser pour le serveur d’API de cluster Kubernetes et pour les services Kubernetes.

Remarque

Le pool d’adresses IP virtuelles doit faire partie du même sous-réseau que le pool de machines virtuelles du nœud Kubernetes.
ID vLAN : ID vLAN du réseau virtuel. En cas d’omission, le réseau virtuel n’est pas balisé.

Réseau virtuel DHCP

Ce modèle de mise en réseau crée un réseau virtuel qui alloue des adresses IP à tous les objets du déploiement.

Vous devez spécifier les paramètres suivants lorsque vous définissez un réseau virtuel avec des configurations IP statique :

Important

Dans cette version d’AKS, il n’est pas possible de modifier la configuration réseau une fois l’hôte AKS ou le cluster de charge de travail déployé. La seule façon de modifier les paramètres de mise en réseau consiste à commencer à nouveau en supprimant le ou les cluster(s) de charge de travail et en désinstallant AKS.

Nom : nom de votre réseau virtuel.
Pool d’adresses IP virtuelles : plage continue d’adresses IP à utiliser pour votre serveur d’API de cluster Kubernetes et pour les services Kubernetes.

Remarque

Les adresses du pool d’adresses IP virtuelles doivent se trouver dans le même sous-réseau que l’étendue DHCP, et doivent être exclues de l’étendue DHCP afin d’éviter les conflits d’adresse.
ID vLAN : ID vLAN du réseau virtuel. En cas d’omission, le réseau virtuel n’est pas balisé.

Service Microsoft On-Premises Cloud

Le cloud local Microsoft (MOC) est la pile de gestion qui permet de gérer dans le cloud les machines virtuelles sur Azure Stack HCI et le centre de données défini par logiciel (SDDC) basé sur Windows Server. Le service MOC est constitué des éléments suivants :

Une instance unique d’un service cloud agent hautement disponible déployée dans le cluster. Cet agent s’exécute sur n’importe quel nœud du cluster Azure Stack HCI ou Windows Server et est configuré pour basculer vers un autre nœud.
Un node agent s’exécutant sur chaque nœud physique d’Azure Stack HCI.

Pour activer la communication avec MOC, vous devez fournir l’adresse IP CIDR à utiliser pour le service. -cloudserviceCIDR est un paramètre de la commande Set-AksHciConfig qui est utilisé pour attribuer l’adresse IP au service d’agent cloud et permettre une haute disponibilité de celui-ci.

Le choix d’une adresse IP pour le service MOC dépend du modèle réseau sous-jacent utilisé par votre déploiement de cluster sur Azure Stack HCI ou Windows Server.

Remarque

L’allocation d’adresse IP pour le service MOC est indépendante de votre modèle de réseau virtuel Kubernetes. L’allocation d’adresses IP dépend du réseau physique sous-jacent et des adresses IP configurées pour les nœuds de cluster Azure Stack HCI ou Windows Server de votre centre de données.

Nœuds de cluster Azure Stack HCI et Windows Server avec un mode d’allocation d’adresses IP DHCP : si vos nœuds Azure Stack HCI se voient attribuer une adresse IP à partir d’un serveur DHCP présent sur le réseau physique, vous n’avez pas besoin de fournir explicitement une adresse IP au service MOC, car le service MOC reçoit également une adresse IP du serveur DHCP.
Nœuds de cluster Azure Stack HCI et Windows Server avec modèle d’allocation d’adresse IP statique : si vos nœuds de cluster se voient attribuer des adresses IP statiques, vous devez fournir explicitement une adresse IP pour le service cloud MOC. L’adresse IP du service MOC doit se trouver dans le même sous-réseau que les adresses IP des nœuds de cluster Azure Stack HCI et Windows Server. Pour attribuer explicitement une adresse IP au service MOC, utilisez le paramètre -cloudserviceCIDR dans la commande Set-AksHciConfig. Veillez à entrer une adresse IP au format CIDR, par exemple, « 10.11.23.45/16 ».

Comparer des modèles de réseaux

Dhcp et IP statique fournissent une connectivité réseau sur votre déploiement AKS sur Azure Stack HCI et Windows Server. Chacun présente toutefois des avantages et des inconvénients. À un niveau élevé, les considérations suivantes s’appliquent :

DHCP : ne garantit pas les adresses IP de longue durée pour certains types de ressources dans un déploiement AKS. - Prend en charge l’extension des adresses IP DHCP réservées si votre déploiement est plus volumineux que prévu.

Adresse IP statique : garantit des adresses IP à longue durée de vie pour toutes les ressources d’un déploiement AKS. - Étant donné que l’extension automatique de pool d’adresses IP virtuelles de nœud Kubernetes n’est pas prise en charge, il se peut que vous ne puissiez pas créer d’autre cluster si vous avez épuisé le pool d’adresses IP du nœud Kubernetes.

Le tableau suivant compare l’allocation d’adresses IP aux ressources qui est utilisée par le modèle de réseau DHCP à celle qui est utilisée par le modèle de réseau IP statique :

Fonctionnalité	Adresse IP statique	DHCP
Serveur d’API de cluster Kubernetes	Attribué de manière statique à l’aide d’un pool d’adresses IP virtuelles.	Attribué de manière statique à l’aide d’un pool d’adresses IP virtuelles.
Nœuds Kubernetes (sur les machines virtuelles)	Attribué à l’aide d’un pool d’adresses IP de nœuds Kubernetes.	Attribué dynamiquement.
Services Kubernetes	Attribué de manière statique à l’aide d’un pool d’adresses IP virtuelles.	Attribué de manière statique à l’aide d’un pool d’adresses IP virtuelles.
VM de l’équilibreur de charge HAProxy	Attribué à l’aide d’un pool d’adresses IP de nœuds Kubernetes.	Attribué dynamiquement.
Service cloud local Microsoft	Dépend de la configuration de la mise en réseau physique pour les nœuds de cluster Azure Stack HCI et Windows Server.	Dépend de la configuration de la mise en réseau physique pour les nœuds de cluster Azure Stack HCI et Windows Server.
Pool VIP	Obligatoire	Obligatoire
Pool d’adresses IP de machines virtuelles de nœud Kubernetes	Obligatoire	Non pris en charge

Réservations d’adresses IP minimales pour un déploiement AKS

Quel que soit votre modèle de déploiement, le nombre d’adresses IP réservées reste le même. Cette section décrit le nombre d’adresses IP que vous devez réserver en fonction de votre modèle de déploiement AKS Arc.

Réservation d’adresse IP minimale

Au minimum, vous devez réserver le nombre suivant d’adresses IP pour votre déploiement :

Type de cluster	Nœud Plan de contrôle	Nœud Worker	Pour les opérations de mise à jour	Équilibrage de charge
Hôte AKS	Une adresse IP	N/D	Deux adresses IP	N/D
Cluster de charge de travail	Une adresse IP par nœud	Une adresse IP par nœud	5 IP	Une adresse IP

En outre, vous devez réserver le nombre suivant d’adresses IP pour votre pool d’adresses IP virtuelles :

Type de ressource	Nombre d’adresses IP
Serveur d’API de cluster	1 par cluster
Services Kubernetes	1 par service
Services d’application	1 par service planifié

Comme vous pouvez le voir, le nombre d’adresses IP requises varie en fonction de l’architecture de votre déploiement AKS et du nombre de services que vous exécutez sur votre cluster Kubernetes. Nous vous recommandons de réserver au minimum 256 adresses IP (sous-réseau /24) pour votre déploiement.

Exemple de déploiement

Jane est une administrateur informatique qui commence avec AKS activé par Azure Arc. Elle souhaite déployer deux clusters Kubernetes : le cluster Kubernetes A et le cluster Kubernetes B sur son cluster Azure Stack HCI. Elle souhaite également exécuter une application de vote sur son cluster. Cette application comprend trois instances de l’interface utilisateur frontale s’exécutant sur les deux clusters, et une instance de la base de données principale.

Le cluster Kubernetes A a 3 nœuds de plan de contrôle et 5 nœuds Worker.
Le cluster Kubernetes B a 1 nœud de plan de contrôle et 3 nœuds Worker.
3 instances de l’interface utilisateur frontale (port 443).
1 instance de la base de données back-end (port 80).

Selon le tableau précédent, elle doit réserver :

3 adresses IP pour l’hôte AKS (une adresse IP pour le nœud du plan de contrôle et deux adresses IP pour l’exécution des opérations de mise à jour).
3 adresses IP pour les nœuds du plan de contrôle dans le cluster A (une adresse IP par nœud de plan de contrôle).
5 adresses IP pour les nœuds Worker du cluster A (une adresse IP par nœud Worker).
6 adresses IP supplémentaires pour le cluster A (cinq adresses IP pour l’exécution des opérations de mise à jour et 1 adresse IP pour l’équilibreur de charge).
1 adresses IP pour les nœuds du plan de contrôle dans le cluster B (une adresse IP par nœud de plan de contrôle).
3 adresses IP pour les nœuds Worker du cluster B (une adresse IP par nœud Worker).
6 adresses IP supplémentaires pour le cluster B (cinq adresses IP pour l’exécution des opérations de mise à jour et 1 adresse IP pour l’équilibreur de charge).
2 adresses IP pour les serveurs d’API de cluster Kubernetes (une adresse IP par cluster Kubernetes).
3 adresses IP pour le service Kubernetes (une adresse IP par instance de l’interface utilisateur frontale, car elles utilisent toutes le même port. La base de données back-end peut utiliser l’une des trois adresses IP à condition qu’elle utilise un port différent).

Comme expliqué précédemment, Jane nécessite un total de 32 adresses IP pour déployer le cluster. Jane doit donc réserver un sous-réseau /26 pour son réseau virtuel.

Répartir les adresses IP réservées en fonction d’un modèle de réseau IP statique

Même si le nombre total d’adresses IP réservées reste le même, le modèle de déploiement détermine la répartition de ces adresses IP entre les groupes d’adresses IP. Le modèle de réseau d’adresses IP statiques comprend deux pools d’adresses IP :

Pool d’adresses IP de machines virtuelles de nœud Kubernetes : pour les machines virtuelles de nœud Kubernetes et la machine virtuelle de l’équilibreur de charge. Ce pool d’adresses IP comprend également l’adresse IP requise pour l’exécution des opérations de mises à jour.
Pool d’adresses IP virtuelles : pour le serveur d’API Kubernetes et les services Kubernetes.

Avec cet exemple, Jane doit diviser davantage ces adresses IP entre les pools d’adresses IP virtuelles et les pools d’adresses IP de nœuds Kubernetes :

5 (deux pour le serveur d’API de cluster Kubernetes et trois pour les services Kubernetes) des 32 adresses IP de son pool d’adresses IP.
27 (toutes les adresses IP ses nœuds Kubernetes et les machines virtuelles sous-jacentes, les machines virtuelles d’équilibreur de charge et les opérations de mise à jour) pour son pool d’adresses IP de nœud Kubernetes.

Répartir des adresses IP réservées en fonction d’un modèle de réseau DHCP

Même si le nombre total d’adresses IP réservées reste le même, le modèle de déploiement détermine la répartition de ces adresses IP entre les groupes IP. Comme nous l’avons vu dans la section précédente, le modèle de réseau DHCP comprend une étendue d’adresses IP :

Pool d’adresses IP virtuelles : pour le serveur d’API Kubernetes et les services Kubernetes

Utilisation de l’exemple précédent :

Jane doit réserver un total de 32 adresses IP ou un sous-réseau /26 sur son serveur DHCP.
Elle doit exclure 5 adresses IP (deux pour le serveur d’API de cluster Kubernetes et trois pour les services Kubernetes) de l’étendue DHPS de 32 adresses IP pour son pool d’adresses IP.

Contrôleurs d’entrée

Lors du déploiement d’un cluster cible, une ressource d’équilibreur de charge basée sur HAProxy est créée. L’équilibreur de charge est configuré pour distribuer le trafic vers les pods dans votre service sur un port donné. L’équilibreur de charge fonctionne uniquement au niveau de la couche 4, ce qui indique que le service n’est pas au courant de l’application réelle ; C’est-à-dire qu’il ne peut pas prendre en compte d’autres considérations relatives au routage.

Les contrôleurs d’entrée fonctionnent au niveau de la couche 7, et peuvent utiliser des règles plus intelligentes pour distribuer le trafic des applications. Une utilisation courante d’un contrôleur d’entrée consiste à acheminer le trafic HTTP vers différentes applications en fonction de l’URL entrante.

Étapes suivantes

Cet article décrit certains concepts de mise en réseau pour le déploiement de nœuds AKS sur Azure Stack HCI. Pour plus d’informations, consultez les articles suivants :