Delen via

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

NAP ondersteunt de volgende netwerkconfiguraties:

We raden u aan Azure CNI te gebruiken met Cilium. Cilium biedt geavanceerde netwerkmogelijkheden en is geoptimaliseerd voor prestaties met NAP.

Niet-ondersteunde netwerkconfiguraties voor NAP

NAP biedt geen ondersteuning voor de volgende netwerkconfiguraties:

  • Calico-netwerkbeleid
  • Dynamische IP-toewijzing

Subnetconfiguraties voor NAP

NAP implementeert, configureert en beheert Karpenter automatisch op uw AKS-clusters en is gebaseerd op de opensource Karpenter - en AKS Karpenter-providerprojecten . U kunt resources gebruiken AKSNodeClass om aangepaste subnetconfiguraties voor NAP-knooppunten in uw knooppuntgroepen op te geven door het optionele vnetSubnetID veld in te stellen. Karpenter gebruikt het subnet dat u opgeeft voor het inrichten van knooppunten. Als u geen subnet opgeeft, gebruikt Karpenter het standaardsubnet dat is geconfigureerd tijdens de installatie van Karpenter. Dit standaardsubnet is doorgaans hetzelfde subnet dat is opgegeven tijdens het maken van een AKS-cluster met de --vnet-subnet-id parameter in de az aks create opdracht.

Met deze benadering kunt u een combinatie van knooppuntklassen hebben, met sommigen die aangepaste subnetten gebruiken voor specifieke workloads en andere met behulp 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.

vnetSubnetID Het wijzigen van een geldig subnet naar een ander geldig subnet is geen ondersteunde bewerking. Als u het vnetSubnetID wijzigt om naar een ander geldig subnet te wijzen, detecteert Karpenter dit als subnet drift en voorkomt dat knooppunten worden geïmplementeerd totdat het probleem is opgelost door vnetSubnetID terug te zetten naar het oorspronkelijke subnet. Dit gedrag zorgt ervoor dat knooppunten alleen worden ingericht in de beoogde subnetten, waarbij de netwerkintegriteit en beveiliging behouden blijven. Er zijn echter uitzonderingen op deze regel. U kunt de vnetSubnetID alleen in de volgende scenario's wijzigen:

  • Het corrigeren van een onjuiste subnet-id die het inrichten van knooppunten voorkomt.
  • Een ongeldige subnetreferentie herstellen die configuratiefouten veroorzaakt.
  • Een subnet-id bijwerken die verwijst naar een niet-bestaand of ontoegankelijk subnet.

Inzicht in AKS-cluster Classless Inter-Domain Routing (CIDR)-bereiken

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

CIDR-overwegingen voor aangepaste 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:

# 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.

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.

Deze benadering is de meest permissieve en verleent de machtigingen van de clusteridentiteit om elk subnet in het hoofd-VNet te lezen en eraan deel te nemen en netwerkcontributortoegang te verlenen.

Belangrijk

Onderzoek de rol 'Netwerkbijdrager' voordat u deze benadering toepast op uw productiecluster.

Voordelen en overwegingen

De volgende tabel bevat een overzicht van de voordelen en overwegingen voor het toewijzen van brede VNet-machtigingen:

Voordelen Overwegingen
• Vereenvoudigt het beheer van machtigingen.
• Elimineert de noodzaak om machtigingen bij te werken bij het toevoegen van nieuwe subnetten.
• Werkt goed voor omgevingen met één tenant.
• Functies wanneer een abonnement het maximum aantal aangepaste rollen bereikt.		 • Biedt bredere machtigingen dan strikt noodzakelijk.
• Voldoet mogelijk niet aan strenge beveiligingsvereisten.

Vereiste toestemmingen

Als u brede VNet-machtigingen wilt toewijzen, verleent u de beheerde identiteit van het cluster de volgende machtigingen voor het 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

Voor een volledig voorbeeld van het instellen van aangepaste netwerken en het toewijzen van brede VNet-machtigingen, raadpleegt u de aangepaste VNET-installatie : het meest uitgebreide RBAC-voorbeeldscript.

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:

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"

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

BYO CNI-ondersteuningsbeleid (Bring Your Own CNI)

Karpenter voor Azure maakt byo-CNI-configuraties (Bring Your Own Container Network Interface) mogelijk, volgens hetzelfde ondersteuningsbeleid als AKS. Dit betekent dat wanneer u een aangepaste CNI gebruikt, ondersteuning voor probleemoplossing met betrekking tot netwerken buiten het bereik valt 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:

  • Last updated on