Dela via

Översikt över nätverkskonfigurationer för automatisk etablering av noder (NAP) i Azure Kubernetes Service (AKS)

Den här artikeln innehåller en översikt över konfigurationskrav för nätverk och rekommendationer för AKS-kluster (Azure Kubernetes Service) med hjälp av nodbaserad automatisk etablering (NAP). Den omfattar konfigurationer som stöds, standardbeteende för undernät, rollbaserad åtkomstkontroll (RBAC) och CIDR-överväganden (classless inter-domain routing).

En översikt över automatisk nodetablering i AKS finns i Översikt över automatisk etablering av noder (NAP) i Azure Kubernetes Service (AKS).

Nätverkskonfigurationer som stöds för NAP

NAP stöder följande nätverkskonfigurationer:

Vi rekommenderar att du använder Azure CNI med Cilium. Cilium tillhandahåller avancerade nätverksfunktioner och är optimerad för prestanda med NAP.

Nätverkskonfigurationer som inte stöds för NAP

NAP stöder inte följande nätverkskonfigurationer:

  • Calico-nätverksprincip
  • Dynamisk IP-allokering

Undernätskonfigurationer för NAP

NAP distribuerar, konfigurerar och hanterar Karpenter automatiskt i dina AKS-kluster och baseras på karpenter - och AKS Karpenter-providerprojekt med öppen källkod. Du kan använda AKSNodeClass resurser för att ange anpassade undernätskonfigurationer för NAP-noder i nodpoolerna genom att ange det valfria vnetSubnetID fältet, och Karpenter använder det undernät som du anger för nodetablering. Om du inte anger något undernät använder Karpenter standardundernätet som konfigurerades under Karpenter-installationen. Det här standardundernätet är vanligtvis samma undernät som angavs när AKS-klustret skapades med parametern --vnet-subnet-idaz aks create i kommandot .

Med den här metoden kan du ha en blandning av nodklasser, där vissa använder anpassade undernät för specifika arbetsbelastningar och andra använder klustrets standardkonfiguration av undernät.

Driftbeteende för undernät

Karpenter övervakar ändringar i undernätets konfiguration och identifierar drift när vnetSubnetID i en AKSNodeClass ändras. Det är viktigt att förstå det här beteendet när du hanterar anpassade nätverkskonfigurationer.

Det går inte att vnetSubnetID ändra från ett giltigt undernät till ett annat giltigt undernät. Om du ändrar vnetSubnetID till att peka på ett annat giltigt undernät identifierar Karpenter detta som undernätsdrift och förhindrar nodetablering tills problemet har lösts genom att vnetSubnetID återgå till det ursprungliga undernätet. Det här beteendet säkerställer att noder endast etableras i de avsedda undernäten, med bibehållen nätverksintegritet och säkerhet. Det finns dock undantag till den här regeln. Du kan bara ändra vnetSubnetID i följande scenarier:

  • Korrigera ett felaktigt undernäts-ID som förhindrar nodetablering.
  • Åtgärda en ogiltig undernätsreferens som orsakar konfigurationsfel.
  • Uppdatera en undernätsidentifierare som pekar på ett obefintligt eller otillgängligt undernät.

Förstå AKS-kluster och CIDR-intervall (Classless Inter-Domain Routing)

När du konfigurerar anpassade nätverk med vnetSubnetIDansvarar du för att förstå och hantera klustrets CIDR-intervall för att undvika nätverkskonflikter. Till skillnad från traditionella AKS-nodpooler som skapats via ARM-mallar tillämpar Karpenter anpassade resursdefinitioner (CRD) som etablerar noder direkt utan den utökade validering som ARM tillhandahåller.

CIDR-överväganden för anpassade undernätskonfigurationer

När du konfigurerar vnetSubnetIDmåste du:

  • Verifiera CIDR-kompatibilitet: Kontrollera att anpassade undernät inte är i konflikt med befintliga CIDR-intervall.
  • Planera IP-kapacitet: Beräkna nödvändiga IP-adresser för förväntad skalning.
  • Verifiera anslutningen: Testa nätverksvägar och säkerhetsgruppsregler.
  • Övervaka användning: Spåra undernätsanvändning och planera för tillväxt.
  • Dokumentkonfiguration: Bevara dokumentation av val för nätverksdesign.

Vanliga CIDR-konflikter

Tänk på följande vanliga CIDR-konfliktscenarier när du använder anpassade undernät med 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-konfiguration för anpassade undernätskonfigurationer

När du använder anpassade undernätskonfigurationer med NAP måste du se till att Karpenter har de behörigheter som krävs för att läsa undernätsinformation och koppla noder till de angivna undernäten. Detta kräver att du konfigurerar lämpliga RBAC-behörigheter för klustrets hanterade identitet.

Det finns två huvudsakliga metoder för att konfigurera dessa behörigheter: Tilldela behörigheter för ett brett virtuellt nätverk (VNet) eller Tilldela begränsade undernätsbehörigheter.

Den här metoden är den mest tillåtande och ger klusteridentiteten behörighet att läsa och ansluta alla undernät i det huvudsakliga virtuella nätverket och ger åtkomst till nätverksdeltagare.

Viktigt!

Undersök rollen "Nätverksdeltagare" innan du tillämpar den här metoden på ditt produktionskluster.

Fördelar och överväganden

I följande tabell beskrivs fördelarna och övervägandena med att tilldela breda VNet-behörigheter:

Fördelar Överväganden
• Förenklar behörighetshantering.
• Eliminerar behovet av att uppdatera behörigheter när du lägger till nya undernät.
• Fungerar bra för miljöer med en enda klientorganisation.
• Fungerar när en prenumeration når det maximala antalet anpassade roller.		 • Ger bredare behörigheter än vad som är absolut nödvändigt.
• Kanske inte uppfyller strikta säkerhetskrav.

Behörigheter som krävs

Om du vill tilldela breda VNet-behörigheter beviljar du klustrets hanterade identitet följande behörigheter för det virtuella nätverket:

# 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

Ett fullständigt exempel på hur du konfigurerar anpassade nätverk och tilldelar breda VNet-behörigheter finns i Custom VNET setup – Most permissive RBAC sample script (Anpassad VNET-konfiguration – Mest tillåtande RBAC-exempelskript).

Exempel på anpassade undernätskonfigurationer

I följande exempel visas hur du konfigurerar ett anpassat undernät för NAP-noder med hjälp av fältet vnetSubnetID i en AKSNodeClass resurs:

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"

I följande exempel visas hur du använder flera nodklasser med olika undernätskonfigurationer:

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"

Policy för att ta med eget CNI-stöd (BYO CNI)

Karpenter för Azure möjliggör att använda egna Container Network Interface (CNI)-konfigurationer genom att följa samma supportpolicy som AKS. Det innebär att när du använder ett anpassat CNI är felsökningsstöd som rör nätverk utanför omfånget för eventuella serviceavtal eller garantier.

Information om supportomfattning

Följande beskriver vad som stöds och inte stöds när du använder BYO CNI med Karpenter:

  • Stöds: Karpenter-specifika funktioner och integrationsproblem när du använder CNI-konfigurationer med BYO (bring-your-own).
  • Stöds inte: CNI-specifika nätverksproblem, konfigurationsproblem eller felsökning när du använder CNI-plugin-program från tredje part.

Nästa steg

Mer information om automatisk nodetablering i AKS finns i följande artiklar:

  • Last updated on