Vue d’ensemble des configurations réseau pour l’approvisionnement automatique de nœuds (NAP) dans Azure Kubernetes Service (AKS)

Cet article fournit une vue d’ensemble des exigences de configuration réseau et des recommandations pour les clusters Azure Kubernetes Service (AKS) à l’aide du provisionnement automatique de nœuds (NAP). Il couvre les configurations prises en charge, le comportement du sous-réseau par défaut, la configuration du contrôle d’accès en fonction du rôle (RBAC) et les considérations relatives au routage inter-domaines sans classe (CIDR).

Pour obtenir une vue d’ensemble de l’approvisionnement automatique de nœuds dans AKS, consultez Vue d’ensemble de l’approvisionnement automatique de nœuds (NAP) dans Azure Kubernetes Service (AKS).

Configurations réseau prises en charge pour NAP

Lors de l’évaluation de la prise en charge de la mise en réseau pour NAP, tenez compte du mode de gestion des adresses IP (IPAM), du plug-in réseau, du plan de données réseau et de la stratégie réseau. Le tableau suivant décrit les options prises en charge par NAP :

Couche de configuration Option Prise en charge de NAP
IPAM Superposition Azure CNI Soutenu
IPAM Sous-réseau de nœud Azure CNI Soutenu
IPAM Sous-réseau Azure CNI pour les pods avec allocation IP dynamique Non pris en charge
module d’extension réseau Kubenet Non pris en charge
Plan de données Azure CNI optimisé par Cilium Compatible avec un mode IPAM Azure CNI pris en charge
Stratégie réseau Calico Non pris en charge

Utilisez Azure CNI Overlay avec le plan de données Azure CNI Powered by Cilium. Cilium offre des fonctionnalités de mise en réseau avancées et est optimisée pour les performances avec NAP.

Considérations relatives à la mise en réseau double pile IPv4/IPv6 pour NAP (Preview)

Note

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les versions préliminaires sont fournies « en l’état » et « selon leur disponibilité » et ne sont pas couvertes par les accords de niveau de service ni par la garantie limitée. Les versions préliminaires d’AKS sont partiellement couvertes par le support client, dans la limite du raisonnable. Par conséquent, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

IPv4/IPv6 Dualstack est une configuration au niveau du cluster non définie par NAP. L’approvisionnement automatique de nœud est pris en charge sur la mise en réseau de cluster double pile IPv4 et IPv6 lorsque vous remplissez les conditions préalables à la double pile. Si vous utilisez NAP sur un cluster à double pile, vérifiez que le plug-in réseau du cluster, le mode IPAM et le plan de données répondent aux prérequis AKS, puis vérifiez que les nœuds et pods approvisionnés ont les adresses attendues.

NAP utilise la configuration réseau du cluster. Les adresses IP publiques de nœud sur les nœuds approvisionnés par NAP ne sont pas prises en charge dans les clusters à double pile. Pour la configuration et la vérification d’AKS à double pile, consultez Utiliser la mise en réseau à double pile dans AKS. Pour connaître la configuration d’adresses IP publiques du nœud et ses limitations, consultez Utiliser les adresses IP publiques au niveau de l’instance dans AKS.

Configurations de sous-réseau pour NAP

Définissez le champ facultatif vnetSubnetID dans une AKSNodeClass ressource pour configurer le sous-réseau personnalisé que Karpenter utilise pour approvisionner des nœuds NAP. Si vous ne spécifiez vnetSubnetIDpas, Karpenter utilise le sous-réseau par défaut configuré pendant l’installation, qui est généralement le sous-réseau spécifié par le --vnet-subnet-id paramètre lorsque vous créez le cluster AKS.

NAP déploie, configure et gère automatiquement Karpenter sur votre cluster AKS et est basé sur les projets de fournisseur Karpenter et AKS Karpenter open source.

AKSNodeClass les ressources de votre cluster AKS peuvent chacune spécifier un autre vnetSubnetID, ce qui permet des configurations de sous-réseau mixtes sur des pools de nœuds. Les classes de nœuds qui ne spécifient pas vnetSubnetID utilisent la configuration de sous-réseau par défaut du cluster.

Comportement de dérive de sous-réseau

Karpenter surveille les modifications de configuration des sous-réseaux et détecte un écart lorsqu’un vnetSubnetID dans un AKSNodeClass est modifié. Comprendre ce comportement est essentiel lors de la gestion des configurations réseau personnalisées.

Pour les clusters qui utilisent un réseau virtuel personnalisé, le fait de faire passer vnetSubnetID d’un sous-réseau valide à un autre entraîne une dérive des nœuds existants associés à AKSNodeClass. Karpenter crée des nœuds de remplacement dans le nouveau sous-réseau et interrompt correctement les nœuds dérivés en fonction des NodePool budgets d’interruption.

Avant de changer vnetSubnetID, vérifiez que l’identité du cluster dispose des autorisations requises sur le nouveau sous-réseau et que le sous-réseau a suffisamment d’adresses IP disponibles pour les nœuds de remplacement. Les budgets de perturbation de pod et les annotations karpenter.sh/do-not-disrupt peuvent retarder le remplacement volontaire lié à la dérive.

Important

Les réseaux virtuels gérés par AKS ne prennent pas en charge les sous-réseaux personnalisés. Utilisez vnetSubnetID uniquement avec un réseau virtuel personnalisé que vous gérez.

Plages CIDR du cluster AKS pour NAP

Lorsque vous configurez la mise en réseau personnalisée avec vnetSubnetID, vous devez comprendre et gérer les plages CIDR de votre cluster pour éviter les conflits réseau. Contrairement aux pools de nœuds AKS traditionnels que vous créez via des modèles Azure Resource Manager (ARM), Karpenter applique des définitions de ressources personnalisées (CRD) qui provisionnent instantanément des nœuds sans la validation étendue que ARM fournit.

Considérations relatives au CIDR pour les configurations de sous-réseaux personnalisées de NAP

Lors de la configuration vnetSubnetID, vous devez :

  • Vérifiez la compatibilité CIDR : vérifiez que les sous-réseaux personnalisés ne sont pas en conflit avec les plages CIDR existantes.
  • Planifier la capacité IP : calculez les adresses IP requises pour la mise à l’échelle attendue.
  • Valider la connectivité : testez les itinéraires réseau et les règles de groupe de sécurité.
  • Surveiller l’utilisation : effectuez le suivi de l’utilisation du sous-réseau et planifiez la croissance.
  • Configuration du document : conservez les enregistrements des décisions de conception réseau.

Conflits CIDR courants

Tenez compte des scénarios de conflit CIDR courants suivants lors de l’utilisation de sous-réseaux personnalisés avec NAP :

Les exemples suivants montrent des plages CIDR de sous-réseau qui entrent en conflit avec le pod de cluster et les CIDR de service, ainsi qu’une configuration qui évite ces conflits. Utilisez ces modèles pour valider vos plages de sous-réseaux avant de configurer vnetSubnetID.

# Example conflict scenarios:
# Cluster Pod CIDR: 10.244.0.0/16  
# Custom Subnet:   10.244.1.0/24  ❌ CONFLICT

# Service CIDR:    10.0.0.0/16
# Custom Subnet:   10.0.10.0/24   ❌ CONFLICT

# Safe configuration:
# Cluster Pod CIDR: 10.244.0.0/16
# Service CIDR:     10.0.0.0/16  
# Custom Subnet:    10.1.0.0/24   ✅ NO CONFLICT

Configuration RBAC pour les configurations de sous-réseau personnalisées

Lorsque vous utilisez des configurations de sous-réseau personnalisées avec NAP, vous devez vous assurer que Karpenter dispose des autorisations nécessaires pour lire les informations de sous-réseau et joindre des nœuds aux sous-réseaux spécifiés. Cela nécessite la configuration des autorisations RBAC appropriées pour l’identité managée du cluster.

La personne qui exécute les commandes suivantes doit avoir l’autorisation de créer la définition de rôle requise et les attributions de rôle requises, par exemple le rôle Administrateur du contrôle d’accès en fonction du rôle. N’accordez pas d’autorisations d’écriture d’attribution de rôle à l’identité de cluster, sauf s’il doit créer des attributions de rôle pour un autre scénario.

Obtenez l’identifiant principal de l’identité managée du cluster. Utilisez la commande qui correspond au type d’identité du cluster :

CLUSTER_IDENTITY=$(az aks show \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --query identity.principalId \
  --output tsv)

Il existe deux approches principales pour configurer ces autorisations : attribuer des autorisations de réseau virtuel étendu ouattribuer des autorisations de sous-réseau étendu.

Cette approche est la plus permissive et accorde aux autorisations d’identité de cluster pour lire et joindre n’importe quel sous-réseau au sein du réseau virtuel principal et fournit un accès contributeur au réseau.

Important

Le rôle de contributeur réseau accorde Microsoft.Network/*, ce qui permet à l’identité du cluster de créer, modifier et supprimer des ressources réseau dans le périmètre du VNet attribué. Passez en revue cet accès avant d’utiliser le rôle en production, car NAP nécessite uniquement des autorisations de lecture et de jointure de sous-réseau pour ce scénario.

Avantages et considérations

Le tableau suivant décrit les compromis liés à l’attribution du rôle Contributeur réseau au niveau de l’étendue du réseau virtuel.

Avantages des autorisations de réseau virtuel étendues Considérations relatives aux autorisations de réseau virtuel étendues
• Simplifie la gestion des autorisations.
• Élimine la nécessité de mettre à jour les autorisations lors de l’ajout de nouveaux sous-réseaux.
• Fonctionne bien pour les environnements monolocataires.
• Fonctions lorsqu’un abonnement atteint le nombre maximal de rôles personnalisés.		 • Fournit des autorisations plus larges que strictement nécessaires.
• Risque de ne pas répondre à des exigences de sécurité strictes.

Autorisations requises

Pour attribuer des autorisations de réseau virtuel étendues, accordez à l’identité managée du cluster les autorisations suivantes sur le réseau virtuel :

# Get your VNet resource ID
VNET_ID="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME"

# Assign Network Contributor role for subnet read/join operations
az role assignment create \
  --assignee-object-id $CLUSTER_IDENTITY \
  --assignee-principal-type ServicePrincipal \
  --role "Network Contributor" \
  --scope $VNET_ID

Pour obtenir un exemple complet de configuration de la mise en réseau personnalisée et de l’attribution d’autorisations de réseau virtuel étendu, consultez l’exemple de script RBAC personnalisé le plus permissif.

Exemples de configurations de sous-réseau personnalisées

L’exemple suivant montre comment configurer un sous-réseau personnalisé pour les nœuds NAP à l’aide du vnetSubnetID champ d’une AKSNodeClass ressource :

Définissez le champ spec.vnetSubnetID sur l’ID de ressource Azure complet du sous-réseau cible en utilisant le format /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Network/virtualNetworks/{vnetName}/subnets/{subnetName}.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: custom-networking
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

L’exemple suivant montre comment utiliser plusieurs classes de nœud avec différentes configurations de sous-réseau :

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: frontend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$FRONTEND_SUBNET_NAME"
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: backend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$BACKEND_SUBNET_NAME"

Apportez votre propre stratégie de support CNI (BYO CNI)

Karpenter pour Azure permet d’apporter vos propres configurations BYO CNI (Container Network Interface), et suit la même stratégie de prise en charge que AKS. BYO CNI n’effectue pas de configuration que NAP répertorie comme non prise en charge, comme kubenet ou Calico, pris en charge. Lorsque vous utilisez une instance CNI personnalisée, la résolution des problèmes liés à la mise en réseau n’est pas étendue à tous les contrats ou garanties de niveau de service.

Détails de l’étendue du support

Les éléments suivants décrivent ce qui est et ne sont pas pris en charge lors de l’utilisation de BYO CNI avec Karpenter :

  • Pris en charge : fonctionnalités spécifiques à Karpenter et problèmes d’intégration lors de l’utilisation de configurations CNI BYO (bring-your-own).
  • Non pris en charge : problèmes réseau spécifiques à CNI, problèmes de configuration ou résolution des problèmes lors de l’utilisation de plug-ins CNI tiers.

Étapes suivantes

Pour plus d’informations sur le provisionnement automatique de nœuds dans AKS, consultez les articles suivants :

  • Dernière mise à jour :