Ü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

Berücksichtigen Sie beim Auswerten der Netzwerkunterstützung für NAP den IP-Adressverwaltungsmodus, das Netzwerk-Plug-In, die Netzwerkdatenebene und die Netzwerkrichtlinie. In der folgenden Tabelle werden die von NAP unterstützten Optionen beschrieben:

Verwenden Sie Azure CNI Overlay mit der von Azure CNI Powered by Cilium bereitgestellten Datenebene. Cilium bietet erweiterte Netzwerkfunktionen und ist für die Leistung mit NAP optimiert.

Subnetzkonfigurationen für NAP

Legen Sie das optionale vnetSubnetID Feld in einer AKSNodeClass Ressource fest, um das benutzerdefinierte Subnetz zu konfigurieren, das Karpenter zum Bereitstellen von NAP-Knoten verwendet. Wenn Sie nicht angeben vnetSubnetID, verwendet Karpenter das während der Installation konfigurierte Standardsubnetz. Dies ist in der Regel das subnetz, das durch den --vnet-subnet-id Parameter beim Erstellen des AKS-Clusters angegeben wird.

NAP stellt Karpenter automatisch bereit, konfiguriert und verwaltet Karpenter auf Ihrem AKS-Cluster und basiert auf den Open-Source-Karpenter - und AKS-Karpenter-Anbieterprojekten .

AKSNodeClass Ressourcen in Ihrem AKS-Cluster können jeweils ein anderes vnetSubnetID angeben, wodurch gemischte Subnetzkonfigurationen über Knotenpools hinweg ermöglicht werden. Knotenklassen, die nicht angeben vnetSubnetID , verwenden die Standardmäßige Subnetzkonfiguration des Clusters.

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.

Bei Clustern, die ein benutzerdefiniertes virtuelles Netzwerk verwenden, führt eine Änderung von vnetSubnetID von einem gültigen Subnetz zu einem anderen dazu, dass vorhandene, dem AKSNodeClass zugeordnete Knoten driften. Karpenter erstellt Ersatzknoten im neuen Subnetz und nimmt die abgewichenen Knoten gemäß den NodePool Disruption-Budgets kontrolliert außer Betrieb.

Bevor Sie vnetSubnetID ändern, stellen Sie sicher, dass die Clusteridentität über die erforderlichen Berechtigungen für das neue Subnetz verfügt und dass das Subnetz über genügend verfügbare IP-Adressen für Ersatzknoten verfügt. Pod-Unterbrechungsbudgets und karpenter.sh/do-not-disrupt Annotationen können die freiwillige Drift-Ersetzung verzögern.

AKS-Cluster-CIDR-Bereiche für NAP

Wenn Sie das benutzerdefinierte Networking mit vnetSubnetID konfigurieren, müssen Sie die CIDR-Bereiche Ihres Clusters verstehen und verwalten, um Netzwerkkonflikte zu vermeiden. Im Gegensatz zu herkömmlichen AKS-Knotenpools, die Sie über Azure Resource Manager(ARM)-Vorlagen erstellen, wendet Karpenter benutzerdefinierte Ressourcendefinitionen (CRDs) an, die Knoten sofort bereitstellen, ohne die erweiterte Überprüfung, die ARM bereitstellt.

Überlegungen zu CIDR für benutzerdefinierte NAP-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:

Die folgenden Beispiele zeigen Subnetz-CIDR-Bereiche, die mit dem Cluster-Pod und Dienst-CIDRs in Konflikt stehen, zusammen mit einer Konfiguration, die diese Konflikte vermeidet. Verwenden Sie diese Muster, um Ihre Subnetzbereiche zu überprüfen, bevor Sie konfigurieren 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

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.

Die Person, die die folgenden Befehle ausführt, muss über die Berechtigung zum Erstellen der erforderlichen Rollendefinition und Rollenzuweisungen verfügen, z. B. die Rollenbasierte Access Control Administratorrolle. Erteilen Sie der Clusteridentität keine Berechtigung zum Schreiben von Rollenzuweisungen, es sei denn, sie muss Rollenzuweisungen für ein anderes Szenario erstellen.

Rufen Sie die Prinzipal-ID für die verwaltete Identität des Clusters ab. Verwenden Sie den Befehl, der dem Clusteridentitätstyp entspricht:

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

CLUSTER_IDENTITY=$(az identity show \
  --resource-group $IDENTITY_RESOURCE_GROUP \
  --name $IDENTITY_NAME \
  --query principalId \
  --output tsv)

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

# 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

# For each subnet, assign specific subnet permissions
SUBNET_ID="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

# Create custom role definition for subnet access
cat > subnet-access-role.json << EOF
{
  "Name": "Karpenter Subnet Access",
  "IsCustom": true,
  "Description": "Allows reading subnet information and joining VMs to subnets",
  "Actions": [
    "Microsoft.Network/virtualNetworks/subnets/read",
    "Microsoft.Network/virtualNetworks/subnets/join/action"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/<subscription-id>"
  ]
}
EOF

# Create the custom role (only needed once per subscription)
az role definition create --role-definition subnet-access-role.json

# Assign the custom role to each subnet
az role assignment create \
  --assignee-object-id $CLUSTER_IDENTITY \
  --assignee-principal-type ServicePrincipal \
  --role "Karpenter Subnet Access" \
  --scope $SUBNET_ID

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:

Legen Sie das spec.vnetSubnetID-Feld mithilfe des Formats /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Network/virtualNetworks/{vnetName}/subnets/{subnetName} auf die vollständige Azure-Ressourcen-ID des Zielsubnetzes fest.

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"

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/$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"

Supportrichtlinie für Bring your own CNI (BYO CNI)

Karpenter für Azure ermöglicht das Mitbringen eigener BYO-CNI-Konfigurationen (Container Network Interface), und es folgt der gleichen Supportrichtlinie wie AKS. BYO CNI führt nicht dazu, dass eine Konfiguration, die von NAP als nicht unterstützt aufgeführt wird, wie z. B. kubenet oder Calico, unterstützt wird. Wenn Sie einen benutzerdefinierten CNI verwenden, ist die Problembehandlung im Zusammenhang mit Dem Netzwerk für alle Vereinbarungen oder Garantien auf Serviceebene nicht vorgesehen.

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:

• Automatische Bereitstellung von Knoten in einem benutzerdefinierten virtuellen Netzwerk verwenden
• Konfigurieren von Knotenpools für die automatische Bereitstellung von Knoten auf AKS
• Konfigurieren von Störungsrichtlinien für die automatische Knotenbereitstellung auf AKS