Freigeben über

Übersicht über Netzwerkkonfigurationen für die automatische Bereitstellung von Knoten (Node Auto-Provisioning, NAP) in Azure Kubernetes Service (AKS)

Dieser Artikel enthält eine Übersicht über netzwerkkonfigurationsanforderungen und Empfehlungen für Azure Kubernetes Service (AKS)-Cluster mithilfe der automatischen Bereitstellung von Knoten (Node Auto-Provisioning, NAP). Es behandelt unterstützte Konfigurationen, standardmäßiges Subnetzverhalten, Rollenbasierte Zugriffssteuerungseinrichtung (RBAC) und Überlegungen zum klassenlosen domänenübergreifenden Routing (CIDR).

Eine Übersicht über die automatische Bereitstellung von Knoten in AKS finden Sie unter Übersicht über die automatische Bereitstellung von Knoten (Node Auto-Provisioning, NAP) in Azure Kubernetes Service (AKS).

Unterstützte Netzwerkkonfigurationen für NAP

NAP unterstützt die folgenden Netzwerkkonfigurationen:

Wir empfehlen die Verwendung von Azure CNI mit Cilium. Cilium bietet erweiterte Netzwerkfunktionen und ist für die Leistung mit NAP optimiert.

Nicht unterstützte Netzwerkkonfigurationen für NAP

NAP unterstützt nicht die folgenden Netzwerkkonfigurationen:

  • Calico-Netzwerkrichtlinie
  • Dynamische IP-Zuordnung

Subnetzkonfigurationen für NAP

NAP stellt Karpenter automatisch bereit, konfiguriert und verwaltet Karpenter auf Ihren AKS-Clustern und basiert auf den Open-Source-Karpenter - und AKS-Karpenter-Anbieterprojekten . Sie können AKSNodeClass Ressourcen verwenden, um benutzerdefinierte Subnetzkonfigurationen für NAP-Knoten in Ihren Knotenpools anzugeben, indem Sie das optionale vnetSubnetID Feld festlegen. Karpenter verwendet das von Ihnen angegebene Subnetz für die Knotenbereitstellung. Wenn Sie kein Subnetz angeben, verwendet Karpenter das während der Karpenter-Installation konfigurierte Standardsubnetz. Dieses Standardsubnetz ist in der Regel dasselbe Subnetz, das während der Erstellung des AKS-Clusters mit dem --vnet-subnet-id Parameter im az aks create Befehl angegeben ist.

Mit diesem Ansatz können Sie über eine Mischung aus Knotenklassen verfügen, bei denen einige benutzerdefinierte Subnetze für bestimmte Arbeitslasten und andere Benutzer die Standardsubnetzkonfiguration des Clusters verwenden.

Subnetzdriftverhalten

Karpenter überwacht Subnetzkonfigurationsänderungen und erkennt Abweichungen, wenn das Element vnetSubnetID in einem AKSNodeClass geändert wird. Das Verständnis dieses Verhaltens ist beim Verwalten von benutzerdefinierten Netzwerkkonfigurationen von entscheidender Bedeutung.

Das Ändern vnetSubnetID von einem gültigen Subnetz in ein anderes gültiges Subnetz ist kein unterstützter Vorgang. Wenn Sie vnetSubnetID so ändern, dass auf ein anderes gültiges Subnetz verwiesen wird, erkennt Karpenter dies als Subnetzdrift und verhindert die Bereitstellung von Knoten, bis das Problem durch das Zurücksetzen von vnetSubnetID auf das ursprüngliche Subnetz behoben ist. Dieses Verhalten stellt sicher, dass Knoten nur in den vorgesehenen Subnetzen bereitgestellt werden, wobei die Netzwerkintegrität und -sicherheit beibehalten werden. Es gibt jedoch Ausnahmen von dieser Regel. Sie können vnetSubnetID nur in den folgenden Szenarien ändern:

  • Korrigieren einer falsch formatierten Subnetz-ID, die die Bereitstellung von Knoten verhindert.
  • Behebung eines ungültigen Subnetzverweises, der Konfigurationsfehler verursacht.
  • Aktualisieren eines Subnetzbezeichners, der auf ein nicht vorhandenes oder nicht zugängliches Subnetz verweist.

Grundlegendes zu CIDR-Bereichen (Classless Inter-Domain Routing) von AKS-Clustern

Beim Konfigurieren von benutzerdefinierten Netzwerken mit vnetSubnetIDsind Sie dafür verantwortlich, die CIDR-Bereiche Ihres Clusters zu verstehen und zu verwalten, um Netzwerkkonflikte zu vermeiden. Im Gegensatz zu herkömmlichen AKS-Knotenpools, die über ARM-Vorlagen erstellt wurden, wendet Karpenter benutzerdefinierte Ressourcendefinitionen (CRDs) an, die Knoten sofort bereitstellen, ohne die erweiterte Überprüfung, die ARM bereitstellt.

CIDR-Überlegungen für benutzerdefinierte Subnetzkonfigurationen

Beim Konfigurieren vnetSubnetIDmüssen Sie:

  • Überprüfen sie die CIDR-Kompatibilität: Stellen Sie sicher, dass benutzerdefinierte Subnetze nicht mit vorhandenen CIDR-Bereichen in Konflikt geraten.
  • Planen der IP-Kapazität: Berechnen der erforderlichen IP-Adressen für die erwartete Skalierung.
  • Überprüfen der Konnektivität: Testen von Netzwerkrouten und Sicherheitsgruppenregeln.
  • Überwachen der Nutzung: Nachverfolgen der Subnetznutzung und Planen des Wachstums.
  • Dokumentkonfiguration: Verwalten von Datensätzen von Netzwerkentwurfsentscheidungen.

Allgemeine CIDR-Konflikte

Beachten Sie die folgenden allgemeinen CIDR-Konfliktszenarien bei verwendung von benutzerdefinierten Subnetzen mit 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

RBAC-Setup für benutzerdefinierte Subnetzkonfigurationen

Wenn Sie benutzerdefinierte Subnetzkonfigurationen mit NAP verwenden, müssen Sie sicherstellen, dass Karpenter über die erforderlichen Berechtigungen verfügt, um Subnetzinformationen zu lesen und Knoten mit den angegebenen Subnetzen zu verbinden. Dies erfordert das Einrichten geeigneter RBAC-Berechtigungen für die verwaltete Identität des Clusters.

Es gibt zwei Hauptansätze zum Einrichten dieser Berechtigungen: Zuweisen umfassender VNet-Berechtigungen (Virtual Network) oder Zuweisen von bezogenen Subnetzberechtigungen.

Dieser Ansatz ist am wenigsten eingeschränkt und gewährt die Berechtigungen der Clusteridentität, um ein beliebiges Subnetz innerhalb des Haupt-VNet zu lesen und ihm beizutreten, und bietet Zugriff als Netzwerkmitwirkender.

Von Bedeutung

Untersuchen Sie die Rolle "Netzwerkmitwirkender", bevor Sie diesen Ansatz auf Ihren Produktionscluster anwenden.

Vorteile und Überlegungen

In der folgenden Tabelle werden die Vorteile und Überlegungen zum Zuweisen allgemeiner VNet-Berechtigungen beschrieben:

Vorteile Überlegungen
• Vereinfacht die Berechtigungsverwaltung.
• Beseitigt die Notwendigkeit, Berechtigungen beim Hinzufügen neuer Subnetze zu aktualisieren.
• Eignet sich gut für Umgebungen mit einem einzigen Mandanten.
• Funktionen, wenn ein Abonnement die maximale Anzahl von benutzerdefinierten Rollen erreicht.		 • Bietet umfassendere Berechtigungen als unbedingt erforderlich.
• Erfüllt möglicherweise keine strengen Sicherheitsanforderungen.

Erforderliche Berechtigungen

Um allgemeine VNet-Berechtigungen zuzuweisen, erteilen Sie der verwalteten Identität des Clusters die folgenden Berechtigungen im VNet:

# 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

Ein vollständiges Beispiel für das Einrichten von benutzerdefinierten Netzwerken und das Zuweisen umfassender VNet-Berechtigungen finden Sie unter Benutzerdefinierte VNet-Einrichtung: Beispielskript für RBAC mit den wenigsten Einschränkungen.

Beispiel für benutzerdefinierte Subnetzkonfigurationen

Das folgende Beispiel zeigt, wie Sie ein benutzerdefiniertes Subnetz für NAP-Knoten mithilfe des vnetSubnetID Felds in einer AKSNodeClass Ressource konfigurieren:

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"

Das folgende Beispiel zeigt, wie Sie mehrere Knotenklassen mit unterschiedlichen Subnetzkonfigurationen verwenden:

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"

Bring your own CNI (BYO CNI) support policy

Karpenter für Azure ermöglicht Ihnen, eigene Container Network Interface (BYO CNI) Konfigurationen bereitzustellen, wobei die gleiche Support-Richtlinie wie für AKS gilt. Dies bedeutet, dass bei der Verwendung eines benutzerdefinierten CNI netzwerkbezogener Support nicht unter die Service-Level-Vereinbarungen oder Garantien fällt.

Supportbereichsdetails

Im Folgenden wird dargelegt, was bei der Verwendung von BYO CNI mit Karpenter unterstützt wird und was nicht.

  • Unterstützt: Karpenter-spezifische Funktionalitäts- und Integrationsprobleme bei der Verwendung von BYO-CNI-Konfigurationen (Bring Your Own).
  • Nicht unterstützt: CNI-spezifische Netzwerkprobleme, Konfigurationsprobleme oder Problembehandlung bei verwendung von CNI-Plug-Ins von Drittanbietern.

Nächste Schritte

Weitere Informationen zur automatischen Bereitstellung von Knoten in AKS finden Sie in den folgenden Artikeln:

  • Last updated on