Déployer un cluster Kubernetes sur un réseau virtuel personnalisé sur Azure Stack Hub

Article
10/30/2024

Vous pouvez déployer un cluster Kubernetes à l’aide du moteur Azure Kubernetes Service (AKS) sur un réseau virtuel personnalisé. Cet article s’intéresse aux informations dont vous avez besoin dans votre réseau virtuel. Vous allez découvrir les étapes à suivre pour calculer les adresses IP utilisées par votre cluster, définir les valeurs dans le modèle d’API et définir la table de routage et le groupe de sécurité réseau.

Le cluster Kubernetes dans Azure Stack Hub à l’aide du moteur AKS utilise le plug-in réseau kubenet. Le moteur AKS sur Azure Stack Hub prend également en charge le plug-in réseau Azure CNI.

Pour plus d’informations sur le plug-in de mise en réseau kubenet dans Azure, consultez Utiliser la mise en réseau kubenet avec vos propres plages d’adresses IP dans Azure Kubernetes Service (AKS).
Pour plus d’informations sur le plug-in de mise en réseau Azure CNI dans Azure, consultez Configurer la mise en réseau Azure CNI dans Azure Kubernetes Service (AKS).

Contraintes lors de la création d’un réseau virtuel personnalisé

Le réseau virtuel personnalisé doit se trouver dans le même abonnement que tous les autres composants du cluster Kubernetes.
Le pool de nœuds du plan de contrôle et le pool de nœuds d’agent doivent se trouver dans le même réseau virtuel. Vous pouvez déployer vos nœuds dans différents sous-réseaux au sein du même réseau virtuel.
Le sous-réseau de cluster Kubernetes doit utiliser une plage d’adresses IP dans l’espace de la plage d’adresses IP du réseau virtuel personnalisé, consultez Obtenir le bloc d’adresses IP.
Tenez compte du fait que la taille recommandée pour le ou les sous-réseaux de nœuds dépend du type de plug-in réseau utilisé. En règle générale, Azure CNI nécessite un plus grand nombre d’adresses IP pour le sous-réseau prenant en charge les pools de nœuds d’agent que kubenet. Consultez les exemples kubenet et Azure CNI ci-dessous.
L’espace d’adressage 169.254.0.0/16 ne peut pas être utilisé avec des réseaux virtuels personnalisés pour les clusters Kubernetes.

Créer un réseau virtuel personnalisé

Vous devez avoir un réseau virtuel personnalisé dans votre instance Azure Stack Hub. Pour plus d’informations, consultez Démarrage rapide : Créer un réseau virtuel avec le portail Azure.

Créez un sous-réseau dans votre réseau virtuel. Vous devez obtenir l’ID de ressource de sous-réseau et la plage d’adresses IP. Vous allez utiliser l’ID de ressource et la plage dans votre modèle d’API quand vous déploierez votre cluster.

Ouvrez le portail utilisateur Azure Stack Hub dans votre instance Azure Stack Hub.
Sélectionnez Toutes les ressources.
Entrez le nom de votre réseau virtuel dans la zone de recherche.
Sélectionnez Sous-réseaux>+ Sous-réseaux pour ajouter un sous-réseau.
Ajoutez un nom et une plage d’adresses en utilisant la notation CIDR. Cliquez sur OK.
Sélectionnez Propriétés dans le panneau Réseaux virtuels. Copiez l’ID de ressource, puis ajoutez /subnets/<nameofyoursubnect>. Vous allez utiliser cette valeur pour la clé vnetSubnetId dans le modèle d’API de votre cluster. L’ID de ressource du sous-réseau utilise le format suivant :
/subscriptions/SUB_ID/resourceGroups/RG_NAME/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME
Sélectionnez Sous-réseaux dans le panneau Réseaux virtuels. Sélectionnez le nom du sous-réseau, par exemple control-plane-sn.

N’associez pas le sous-réseau à un groupe de sécurité réseau (NSG).
Dans le panneau du sous-réseau, notez la plage d’adresses (bloc CIDR) de chaque sous-réseau.

Considérations relatives à la sélection d’un espace d’adressage

Lorsque vous créez un réseau virtuel personnalisé, vous spécifiez l’espace d’adressage IP de votre réseau et une plage d’adresses IP pour chaque sous-réseau. Tenez compte des facteurs suivants lorsque vous choisissez les espaces d’adressage et les plages d’adresses à utiliser dans votre cluster Kubernetes :

Le chevauchement des espaces d’adressage peut entraîner des erreurs de communication ou des conflits d’adresses IP. Pour réduire le risque de chevauchement des adresses IP, choisissez un espace d’adressage unique pour votre nouveau réseau virtuel.
Les espaces d’adressage dans les plages 10/8, 172.16/12 et 192.168/16 sont souvent utilisés pour les réseaux privés et peuvent être utilisés par votre infrastructure de centre de données existante. Si vos applications Kubernetes utilisent des ressources dans votre centre de données, réduisez les risques de conflit en choisissant un espace d’adressage pour votre réseau virtuel personnalisé qui soit différent de l’espace d’adressage de votre centre de données.
Nous vous recommandons d’utiliser un sous-réseau dédié pour votre cluster Kubernetes.
Avec plusieurs réseaux virtuels existants, vous pouvez utiliser des espaces d’adressage différents sur chaque réseau si vous comptez utiliser l’homologation de réseaux virtuels. Des espaces d’adressage qui se chevauchent peuvent empêcher l’homologation.

Obtenir les blocs d’adresses IP

Le moteur AKS prend en charge le déploiement sur un réseau virtuel existant. Lorsqu’il est déployé sur un réseau virtuel existant, votre cluster utilise des blocs d’adresses consécutives pour les nœuds d’agent, les nœuds du plan de contrôle, les services de cluster et les conteneurs (pods). Chaque bloc d’adresses peut être traduit en un sous-réseau au sein du réseau virtuel. Tous les blocs d’adresses du déploiement du cluster doivent faire partie de l’espace d’adressage global du réseau virtuel. Le choix des blocs d’adresses en dehors de l’espace d’adressage du réseau virtuel peut entraîner des problèmes de connectivité.

Un minimum de trois blocs d’adresses sont requis lors de la configuration d’un cluster Kubernetes :

Bloc d’adresses des nœuds : il s’agit du bloc d’adresses utilisé pour assigner des adresses aux nœuds de cluster. Cela peut être un bloc d’adresses unique pour tous les nœuds de cluster, ou des blocs distincts (sous-réseaux) pour les pools d’agent et les pools de plan de contrôle. Tenez compte du nombre de nœuds dans votre cluster lors de la sélection de la plage d’adresses pour ce bloc. Pour que les conteneurs et les nœuds Azure CNI obtiennent leurs adresses du même bloc d’adresses, tenez compte du nombre de conteneurs que vous souhaitez déployer sur votre cluster lors du choix de la plage d’adresses lorsque vous utilisez Azure CNI.
Bloc d’adresses des services : il s’agit du bloc d’adresses à partir duquel les services déployés sur le cluster Kubernetes obtiennent leur adresse de cluster. Tenez compte du nombre maximal de services que vous souhaitez exécuter dans votre cluster lors de la sélection de la plage d’adresses pour ce bloc.
Bloc d’adresses du cluster : il s’agit du bloc d’adresses à partir duquel les pods obtiendront leur adresse de cluster. Tenez compte du nombre maximal de pods que vous souhaitez exécuter dans votre cluster lors de la sélection de la plage d’adresses pour ce bloc. Comme mentionné précédemment, pour Azure CNI, les blocs d’adresses de cluster et de nœuds sont identiques.

En plus des blocs d’adresses, pour les nœuds de plan de contrôle, vous devez définir deux valeurs supplémentaires. Vous devez connaître le nombre d’adresses IP à réserver pour votre cluster et la première adresse IP statique consécutive au sein de l’espace IP du sous-réseau. Le moteur AKS nécessite une plage allant jusqu’à 16 adresses IP inutilisées lorsque vous utilisez plusieurs nœuds de plan de contrôle. Le cluster utilisera une adresse IP pour chaque plan de contrôle, avec un maximum de cinq nœuds de plan de contrôle. Le moteur AKS nécessite également la prochaine adresse IP 10 après le dernier nœud du plan de contrôle pour la réservation d’adresses IP de salle principale. Enfin, une autre adresse IP sera utilisée par l’équilibreur de charge après les nœuds du plan de contrôle et la réservation de salle de contrôle, pour un total de 16. Quand vous placez votre bloc d’adresses IP, le sous-réseau exige les allocations suivantes des adresses IP existantes :

Les quatre premières adresses IP et la dernière adresse IP sont réservées et ne peuvent pas être utilisées dans un sous-réseau Azure.
Un tampon de 16 adresses IP doit être laissé ouvert.
La valeur de la première adresse IP de votre cluster doit être vers la fin de l’espace d’adressage pour éviter les conflits d’adresses IP. Si possible, affectez la firstConsecutiveStaticIP propriété à une adresse IP près de la fin de l’espace d’adressage IP disponible dans le sous-réseau.

Par exemple, pour un cluster comportant trois nœuds de plan de contrôle. Si vous utilisez un sous-réseau avec 256 adresses (par exemple, 10.100.0.0/24), vous devez définir votre première adresse IP statique consécutive avant 239. Le tableau suivant indique les adresses et considérations :

Plage pour le sous-réseau /24	Nombre	Remarque
172.100.0.0 - 172.100.0.3	4	Réservé dans le sous-réseau Azure.
172.100.0.224-172.100.0.238	14	Nombre d’adresses IP pour un cluster défini par le moteur AKS. 3 adresses IP pour 3 nœuds de plan de contrôle 10 adresses IP pour la marge 1 adresse IP pour l’équilibreur de charge
172.100.0.238 - 172.100.0.254	16	Tampon de 16 adresses IP.
172.100.0.255	1	Réservé dans le sous-réseau Azure.

Dans cet exemple, la propriété firstConsecutiveStaticIP a la valeur 172.100.0.224.

Pour les sous-réseaux plus larges, par exemple /16 avec plus de 60 000 adresses, il peut s’avérer difficile de définir vos affectations d’adresses IP statiques à la fin de l’espace réseau. Définissez la plage d’adresses IP statiques de votre cluster en dehors des 24 premières adresses de votre espace IP afin que le cluster soit résilient lors de la revendication d’adresses.

Exemple de blocs d’adresses Kubenet

Dans l’exemple suivant, vous pouvez voir comment ces différentes considérations remplissent l’espace d’adressage du réseau virtuel. Ici, un cluster utilise un plug-in réseau kubenet avec des sous-réseaux dédiés pour les pools de nœuds de plan de contrôle et d’agent, et avec trois nœuds par pool.

Espace d’adressage du réseau virtuel : 10.100.0.0/16.

Bloc d’adresses (sous-réseau)	CIDR	Plage d’adresses IP	Nombre d’adresses IP (disponibles)
Bloc de nœuds de plan de contrôle	10.100.0.0/24	10.100.0.0 - 10.100.0.255	255 - 4 réservés = 251
Bloc de nœuds d’agent	10.100.1.0/24	10.100.1.0 - 10.100.1.255	255 - 4 réservés = 251
Bloc de services	10.100.16.0/20	10.100.16.0 - 10.100.31.255	4 096 - 5 réservés = 4 091
Bloc de cluster	10.100.128.0/17	10.100.128.0 - 10.100.255.255	32 768 - 5 réservés = 32 763

Dans cet exemple, la propriété firstConsecutiveStaticIP a la valeur 10.100.0.239.

Exemple de blocs d’adresses Azure CNI

Dans l’exemple suivant, vous pouvez voir comment ces différentes considérations remplissent l’espace d’adressage du réseau virtuel. Ici, un cluster utilise un plug-in réseau Azure CNI avec des sous-réseaux dédiés pour les pools de nœuds de plan de contrôle et d’agent, et avec trois nœuds par pool.

Espace d’adressage du réseau virtuel : 172.24.0.0/16.

Remarque

Si, dans votre environnement, la plage d’adresses IP publiques se trouve dans CIDR10.0.0.0/8, utilisez kubenet comme plug-in réseau.

Bloc d’adresses (sous-réseau)	CIDR	Plage d’adresses IP	Nombre d’adresses IP (disponibles)
Bloc de nœuds de plan de contrôle	172.24.0.0/24	172.24.0.0 - 172.24.0.255	255 - 4 réservés = 251
Nœuds d’agent et bloc de cluster	172.24.128.0/17	172.24.128.0 - 172.24.255.255	32 768 - 5 réservés = 32 763
Bloc de services	172.24.16.0/20	172.24.16.0 - 172.24.31.255	4 096 - 5 réservés = 4 091

Dans cet exemple, la propriété firstConsecutiveStaticIP a la valeur 172.24.0.239.

Mettre à jour le modèle d’API

Mettez à jour le modèle d’API utilisé pour déployer le cluster à partir du moteur AKS sur votre réseau virtuel personnalisé.

Dans masterProfile, définissez les valeurs suivantes :

Champ	Exemple	Description
vnetSubnetId	`/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn`	Spécifiez l’ID de chemin Azure Resource Manager du sous-réseau. Cette valeur est mappée au bloc d’adresses des nœuds de plan de contrôle ci-dessus.
firstConsecutiveStaticIP	10.100.0.239	Affectez à la propriété de configuration `firstConsecutiveStaticIP` une adresse IP proche de la fin de l’espace d’adressage IP disponible dans le sous-réseau souhaité. `firstConsecutiveStaticIP` s’applique uniquement au pool de nœuds de plan de contrôle.

Dans agentPoolProfiles, définissez les valeurs suivantes :

Champ	Exemple	Description
vnetSubnetId	`/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/agents-sn`	Spécifiez l’ID de chemin Azure Resource Manager du sous-réseau. Cette valeur est mappée au bloc d’adresses des nœuds d’agent ci-dessus.

Dans orchestratorProfile, recherchez kubernetesConfig et définissez la valeur suivante :

Champ	Exemple	Description
clusterSubnet	`10.100.128.0/17`	Sous-réseau IP utilisé pour l’allocation d’adresses IP pour les interfaces réseau de pod. Cette valeur correspond au bloc d’adresses de cluster ci-dessus. Le sous-réseau doit se trouver dans l’espace d’adressage VNET. Si Azure CNI est activé, la valeur par défaut est 10.240.0.0/12. Sans Azure CNI, la valeur par défaut est 10.244.0.0/16. Utilisez le sous-réseau /16 à la place de /24. Si vous utilisez /24, ce sous-réseau sera attribué à un seul nœud. Aucun réseau POD n’est attribué à un autre nœud, car vous ne disposez pas de l’espace IP nécessaire pour qu’ils soient prêts dans le cluster.
serviceCidr	`10.100.16.0/20`	Sous-réseau IP utilisé pour l’allocation d’adresses IP pour les services déployés dans le cluster. Cette valeur est mappée au bloc de services de cluster ci-dessus.
dnsServiceIP	`10.100.16.10`	Adresse IP à attribuer au service DNS du cluster. L’adresse doit provenir du sous-réseau serviceCidr. Cette valeur doit être définie lors de la spécification de serviceCidr. La valeur par défaut est l’adresse .10 du sous-réseau serviceCidr.

Par exemple, si vous utilisez kubenet :
Avec un espace d’adressage réseau 10.100.0.0/16 où le sous-réseau pour control-plane-sn est 10.100.0.0/24, et où agents-sn est 10.100.1.0/24

"masterProfile": {
  ...
  "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn",
  "firstConsecutiveStaticIP": "10.100.0.239",
  ...
},
...
"agentPoolProfiles": [
  {
    ...
    "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/agents-sn",
    ...
  },
    ...
"kubernetesConfig": [
  {
    ...
    "clusterSubnet": "10.100.128.0/17",
    "serviceCidr": "10.100.16.0/20",
    "dnsServiceIP" : "10.100.16.10",

    ...
  },

Par exemple, si vous utilisez Azure CNI :
Avec un espace d’adressage réseau 172.24.0.0/16 où le sous-réseau pour control-plane-sn est 172.24.0.0/24, et où k8s-sn est 172.24.128.0/17

"masterProfile": {
  ...
  "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn",
  "firstConsecutiveStaticIP": "172.24.0.239",
  ...
},
...
"agentPoolProfiles": [
  {
    ...
    "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/k8s-sn",
    ...
  },
    ...
"kubernetesConfig": [
  {
    ...
    "clusterSubnet": "172.24.128.0/17",
    "serviceCidr": "172.24.16.0/20",
    "dnsServiceIP" : "172.24.16.10",
    ...
  },

Déployer votre cluster

Après avoir ajouté les valeurs à votre modèle d’API, vous pouvez déployer votre cluster à partir de votre ordinateur client à l’aide de la commande dans le deploy moteur AKS. Pour obtenir des instructions, consultez Déployer un cluster Kubernetes.

Définir la table de route

Si vous utilisez kubenet, par exemple networkPlugin : kubenet dans l’objet de configuration du modèle d’API kubernetesConfig. Après avoir déployé votre cluster, revenez à votre réseau virtuel dans le portail utilisateur Azure Stack. Définissez la table de routage et le groupe de sécurité réseau (NSG) dans le panneau du sous-réseau. Une fois que vous avez correctement déployé un cluster sur votre réseau virtuel personnalisé, obtenez l’ID de la ressource Table de routage à partir du panneau Réseau dans le groupe de ressources de votre cluster.

Ouvrez le portail utilisateur Azure Stack Hub dans votre instance Azure Stack Hub.
Sélectionnez Toutes les ressources.
Entrez le nom de votre réseau virtuel dans la zone de recherche.
Sélectionnez Sous-réseaux, puis le nom du sous-réseau qui contient votre cluster.
Sélectionnez Table de routage, puis la table de routage de votre cluster.
Vérifiez que cela est effectué pour chaque sous-réseau spécifié dans le modèle d’API, y compris le masterProfile sous-réseau.