Partager via

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

NAP prend en charge les configurations réseau suivantes :

Nous vous recommandons d’utiliser Azure CNI avec Cilium. Cilium offre des fonctionnalités de mise en réseau avancées et est optimisée pour les performances avec NAP.

Configurations réseau non prises en charge pour NAP

NAP ne prend pas en charge les configurations réseau suivantes :

  • Stratégie réseau Calico
  • Allocation d’adresses IP dynamiques

Configurations de sous-réseau pour NAP

NAP déploie, configure et gère automatiquement Karpenter sur vos clusters AKS et est basé sur les projets de fournisseur Karpenter et AKS Karpenter open source. Vous pouvez utiliser AKSNodeClass des ressources pour spécifier des configurations de sous-réseau personnalisées pour les nœuds NAP dans vos pools de nœuds en définissant le champ facultatif vnetSubnetID , et Karpenter utilise le sous-réseau que vous spécifiez pour l’approvisionnement de nœuds. Si vous ne spécifiez pas de sous-réseau, Karpenter utilise le sous-réseau par défaut configuré lors de l’installation de Karpenter. Ce sous-réseau par défaut est généralement le même sous-réseau spécifié lors de la création du cluster AKS avec le --vnet-subnet-id paramètre dans la az aks create commande.

Cette approche vous permet d’avoir un mélange de classes de nœuds, avec certains utilisant des sous-réseaux personnalisés pour des charges de travail spécifiques, et d’autres utilisant 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.

La modification d’un vnetSubnetID sous-réseau valide vers un autre sous-réseau valide n’est pas une opération prise en charge. Si vous changez le vnetSubnetID pour pointer vers un autre sous-réseau valide, Karpenter détecte cela comme une dérive de sous-réseau et empêche l'approvisionnement des nœuds jusqu'à ce que le problème soit résolu en rétablissant le vnetSubnetID au sous-réseau d'origine. Ce comportement garantit que les nœuds sont provisionnés uniquement dans les sous-réseaux prévus, en conservant l’intégrité du réseau et la sécurité. Toutefois, il existe des exceptions à cette règle. Vous pouvez uniquement modifier le vnetSubnetID dans les scénarios suivants :

  • Correction d’un ID de sous-réseau incorrect qui empêche l’approvisionnement de nœuds.
  • Correction d’une référence de sous-réseau non valide qui provoque des erreurs de configuration.
  • Mise à jour d’un identificateur de sous-réseau qui pointe vers un sous-réseau inexistant ou inaccessible.

Comprendre les plages de routage des Inter-Domain sans cluster AKS (CIDR)

Lors de la configuration de la mise en réseau personnalisée avec vnetSubnetID, vous êtes responsable de la compréhension et de la gestion des plages CIDR de votre cluster pour éviter les conflits réseau. Contrairement aux pools de nœuds AKS traditionnels créés via des modèles 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 sur le CIDR pour la configuration de sous-réseaux personnalisés

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 :

# 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.

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

Examinez le rôle « Contributeur réseau » avant d’appliquer cette approche à votre cluster de production.

Avantages et considérations

Le tableau suivant présente les avantages et considérations liés à l’attribution d’autorisations de réseau virtuel étendu :

Avantages Considérations
• 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 cluster's managed identity
CLUSTER_IDENTITY=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query identity.principalId -o tsv)

# 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 $CLUSTER_IDENTITY \
  --role "Network Contributor" \
  --scope $VNET_ID

Pour obtenir un exemple complet de configuration de mise en réseau personnalisée et d’affectation d’autorisations de réseau virtuel étendues, consultez l’exemple de script RBAC 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 :

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: custom-networking
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$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/$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/$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), en suivant la même stratégie de prise en charge que AKS. Cela signifie que lors de l’utilisation d’une instance CNI personnalisée, la résolution des problèmes liés à la mise en réseau est hors de portée des 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 :

  • Last updated on