Ö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

När du utvärderar nätverksstöd för NAP bör du tänka på IPAM-läget (IP-adresshantering), plugin-nätverket, nätverksdataplanet och nätverksprincipen. I följande tabell beskrivs de alternativ som stöds av NAP:

Använd Azure CNI-överlägg med Azure CNI som drivs av dataplanet Cilium. Cilium tillhandahåller avancerade nätverksfunktioner och är optimerad för prestanda med NAP.

Undernätskonfigurationer för NAP

Ange det valfria vnetSubnetID fältet i en AKSNodeClass resurs för att konfigurera det anpassade undernät som Karpenter använder för att etablera NAP-noder. Om du inte anger vnetSubnetIDanvänder Karpenter standardundernätet som konfigurerades under installationen, vilket vanligtvis är det undernät som anges av parametern --vnet-subnet-id när du skapar AKS-klustret.

NAP distribuerar, konfigurerar och hanterar Karpenter automatiskt i ditt AKS-kluster och baseras på karpenter - och AKS Karpenter-providerprojekt med öppen källkod.

AKSNodeClass resurser i AKS-klustret kan var och en ange en annan vnetSubnetID, som möjliggör konfigurationer av blandade undernät mellan nodpooler. Nodklasser som inte anger vnetSubnetID använder klustrets standardkonfiguration av undernätet.

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.

För kluster som använder ett anpassat virtuellt nätverk orsakar det att ändra vnetSubnetID från ett giltigt undernät till ett annat att befintliga noder som är associerade med AKSNodeClass börjar avvika. Karpenter skapar ersättningsnoder i det nya undernätet och avvecklar på ett kontrollerat sätt noder som avviker från den önskade konfigurationen enligt NodePoolstörningsbudgetarna.

Innan du ändrar vnetSubnetIDkontrollerar du att klusteridentiteten har de behörigheter som krävs för det nya undernätet och att undernätet har tillräckligt med tillgängliga IP-adresser för ersättningsnoder. Poddavbrottsbudgetar och karpenter.sh/do-not-disrupt anteckningar kan fördröja frivillig driftsättning.

AKS-kluster CIDR-intervall för NAP

När du konfigurerar anpassade nätverk med vnetSubnetIDmåste du förstå och hantera klustrets CIDR-intervall för att undvika nätverkskonflikter. Till skillnad från traditionella AKS-nodpooler som du skapar via Azure Resource Manager (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 nap-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:

Följande exempel visar CIDR-intervall för undernät som är i konflikt med klustrets podd- och tjänst-CIDR-intervall, tillsammans med en konfiguration som undviker dessa konflikter. Använd dessa mönster för att verifiera dina undernätsintervall innan du konfigurerar 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-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.

Den person som kör följande kommandon måste ha behörighet att skapa den rolldefinition och rolltilldelning som krävs, till exempel rollbaserad Access Control administratörsroll. Bevilja inte skrivbehörigheter för rolltilldelning till klusteridentiteten om den inte behöver skapa rolltilldelningar för ett annat scenario.

Hämta huvud-ID:t för klustrets hanterade identitet. Använd kommandot som motsvarar klusteridentitetstypen:

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)

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.

# 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

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:

spec.vnetSubnetID Ange fältet till det fullständiga Azure resurs-ID:t för målundernätet med hjälp av formatet /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"

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

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

Karpenter for Azure tillåter BYO CNI-konfigurationer (Container Network Interface) och följer samma supportprincip som AKS. BYO CNI innebär inte att en konfiguration som NAP anger som inte stödd, till exempel kubenet eller Calico, blir stödd. 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:

• Använda automatisk nodetablering i ett anpassat virtuellt nätverk
• Konfigurera nodpooler för automatisk tilldelning av noder i AKS
• Konfigurera störningsprinciper för automatisk nodtilldelning i AKS