Overzicht van netwerkconfiguraties voor automatisch inrichten van knooppunten (NAP) in Azure Kubernetes Service (AKS)

In dit artikel vindt u een overzicht van de netwerkconfiguratievereisten en aanbevelingen voor AKS-clusters (Azure Kubernetes Service) met behulp van NAP (Automatisch inrichten van knooppunten). Hierin worden ondersteunde configuraties, standaardsubnetgedrag, RBAC-instellingen (op rollen gebaseerd toegangsbeheer) en overwegingen met betrekking tot classless interdomeinroutering (CIDR) behandeld.

Zie Overzicht van automatische inrichting van knooppunten in AKS voor een overzicht van het automatisch inrichten van knooppunten (NAP) in Azure Kubernetes Service (AKS).

Ondersteunde netwerkconfiguraties voor NAP

Houd bij het evalueren van netwerkondersteuning voor NAP rekening met de modus voor IP-adresbeheer (IPAM), de netwerkplug-in, het gegevensvlak van het netwerk en het netwerkbeleid. In de volgende tabel worden de opties beschreven die worden ondersteund door NAP:

Gebruik Azure CNI Overlay met de Azure CNI Powered by Cilium data plane. Cilium biedt geavanceerde netwerkmogelijkheden en is geoptimaliseerd voor prestaties met NAP.

Subnetconfiguraties voor NAP

Stel het optionele vnetSubnetID veld in een AKSNodeClass resource in om het aangepaste subnet te configureren dat Karpenter gebruikt om NAP-knooppunten in te richten. Als u dit niet opgeeft vnetSubnetID, gebruikt Karpenter het standaardsubnet dat tijdens de installatie is geconfigureerd. Dit is doorgaans het subnet dat is opgegeven door de --vnet-subnet-id parameter wanneer u het AKS-cluster maakt.

NAP implementeert, configureert en beheert Karpenter automatisch op uw AKS-cluster en is gebaseerd op de opensource Karpenter - en AKS Karpenter-providerprojecten .

AKSNodeClass resources in uw AKS-cluster kunnen elk een andere vnetSubnetIDopgeven, waardoor gemengde subnetconfiguraties tussen knooppuntgroepen mogelijk zijn. Knooppuntklassen die niet opgeven vnetSubnetID , maken gebruik van de standaardsubnetconfiguratie van het cluster.

Gedrag van subnetdrift

Karpenter bewaakt wijzigingen in de subnetconfiguratie en detecteert afwijkingen wanneer de vnetSubnetID in een AKSNodeClass wordt gewijzigd. Inzicht in dit gedrag is essentieel bij het beheren van aangepaste netwerkconfiguraties.

Voor clusters die een aangepast virtueel netwerk gebruiken, zorgt het wijzigen vnetSubnetID van het ene geldige subnet naar het andere ervoor dat bestaande knooppunten die zijn gekoppeld aan de AKSNodeClass drift. Karpenter maakt vervangende nodes aan in het nieuwe subnet en stelt de nodes met drift op gecontroleerde wijze buiten gebruik volgens de NodePool disruptiebudgetten.

Voordat u deze wijzigt vnetSubnetID, moet u ervoor zorgen dat de clusteridentiteit over de vereiste machtigingen beschikt voor het nieuwe subnet en of het subnet voldoende beschikbare IP-adressen heeft voor vervangende knooppunten. Budgetten en karpenter.sh/do-not-disrupt aantekeningen voor podonderbreking kunnen vrijwillige driftvervanging vertragen.

CIDR-bereiken voor AKS-cluster voor NAP

Wanneer u aangepaste netwerken configureert met vnetSubnetID, moet u de CIDR-bereiken van uw cluster begrijpen en beheren om netwerkconflicten te voorkomen. In tegenstelling tot traditionele AKS-knooppuntgroepen die u maakt via arm-sjablonen (Azure Resource Manager), past Karpenter aangepaste resourcedefinities (CRD's) toe die knooppunten direct inrichten zonder de uitgebreide validatie die ARM biedt.

CIDR-overwegingen voor aangepaste NAP-subnetconfiguraties

Bij het vnetSubnetIDconfigureren moet u het volgende doen:

• Controleer de CIDR-compatibiliteit: zorg ervoor dat aangepaste subnetten niet conflicteren met bestaande CIDR-bereiken.
• IP-capaciteit plannen: bereken de vereiste IP-adressen voor verwachte schaalaanpassing.
• Connectiviteit valideren: netwerkroutes en beveiligingsgroepsregels testen.
• Gebruik bewaken: het subnetgebruik bijhouden en groei plannen.
• Documentconfiguratie: beheer records van beslissingen over netwerkontwerp.

Veelvoorkomende CIDR-conflicten

Houd rekening met de volgende veelvoorkomende CIDR-conflictscenario's bij het gebruik van aangepaste subnetten met NAP:

In de volgende voorbeelden ziet u ciDR-bereiken van het subnet die conflicteren met de clusterpod en service-CIDR's, samen met een configuratie die deze conflicten voorkomt. Gebruik deze patronen om uw subnetbereiken te valideren voordat u deze configureert 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-installatie voor aangepaste subnetconfiguraties

Wanneer u aangepaste subnetconfiguraties met NAP gebruikt, moet u ervoor zorgen dat Karpenter over de benodigde machtigingen beschikt om subnetgegevens te lezen en knooppunten toe te voegen aan de opgegeven subnetten. Hiervoor moet u de juiste RBAC-machtigingen instellen voor de beheerde identiteit van het cluster.

De persoon die de volgende opdrachten uitvoert, moet over de machtigingen beschikken om de vereiste roldefinitie en roltoewijzingen te maken, zoals de rol Role Based Access Control Administrator. Verdeel geen schrijfmachtigingen voor de roltoewijzing aan de clusteridentiteit, tenzij deze roltoewijzingen voor een ander scenario moet maken.

Haal de principal-id op voor de beheerde identiteit van het cluster. Gebruik de opdracht die overeenkomt met het clusteridentiteitstype:

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)

Er zijn twee hoofdmethoden voor het instellen van deze machtigingen: wijs machtigingen voor een breed virtueel netwerk (VNet) toe of wijs subnetmachtigingen binnen het bereik toe.

# 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

Voorbeeld van aangepaste subnetconfiguraties

In het volgende voorbeeld ziet u hoe u een aangepast subnet voor NAP-knooppunten configureert met behulp van het vnetSubnetID veld in een AKSNodeClass resource:

Stel het spec.vnetSubnetID veld in op de volledige Azure resource-id van het doelsubnet met behulp van de indeling/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"

In het volgende voorbeeld ziet u hoe u meerdere knooppuntklassen met verschillende subnetconfiguraties gebruikt:

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"

BYO CNI-ondersteuningsbeleid (Bring Your Own CNI)

Karpenter voor Azure maakt BYO CNI-configuraties (Bring Your Own Container Network Interface) mogelijk en volgt hetzelfde ondersteuningsbeleid als AKS. BYO CNI zorgt er niet voor dat een configuratie die door NAP als niet ondersteund wordt vermeld, zoals kubenet of Calico, wel wordt ondersteund. Wanneer u een aangepaste CNI gebruikt, valt de ondersteuning voor het oplossen van problemen met betrekking tot netwerken buiten het bereik van eventuele serviceovereenkomsten of garanties.

Details van ondersteuningsbereik

In het volgende overzicht wordt beschreven wat wel en niet wordt ondersteund bij het gebruik van BYO CNI met Karpenter:

• Ondersteund: Karpenter-specifieke functionaliteit en integratieproblemen bij het gebruik van BYO-configuraties (Bring-Your-Own) CNI.
• Niet ondersteund: CNI-specifieke netwerkproblemen, configuratieproblemen of probleemoplossing bij het gebruik van CNI-invoegtoepassingen van derden.

Volgende stappen

Zie de volgende artikelen voor meer informatie over automatische inrichting van knooppunten in AKS:

• Auto-provisioning van knooppunten gebruiken in een aangepast virtueel netwerk
• Knooppuntgroepen configureren voor automatische inrichting van knooppunten in AKS
• Onderbrekingsbeleid configureren voor auto-provisioning van knooppunten op AKS