Kubenet-netwerken gebruiken met uw eigen IP-adresbereiken in Azure Kubernetes Service (AKS)

AKS-clusters gebruiken kubenet en maken standaard een virtueel Azure-netwerk en subnet voor u. Met kubenet krijgen knooppunten een IP-adres uit het subnet van het virtuele Azure-netwerk. Pods krijgen een IP-adres van een logisch verschillende adresruimte van het subnet van het virtuele Azure-netwerk van de knooppunten. Nat (Network Address Translation) wordt vervolgens geconfigureerd, zodat de pods resources in het virtuele Azure-netwerk kunnen bereiken. Het bron-IP-adres van het verkeer is NAT naar het primaire IP-adres van het knooppunt. Deze aanpak vermindert het aantal IP-adressen dat u moet reserveren in uw netwerkruimte voor gebruik door pods.

Met Azure Container Networking Interface (CNI) krijgt elke pod een IP-adres van het subnet en kan deze rechtstreeks worden geopend. Deze IP-adressen moeten vooraf worden gepland en uniek zijn in uw netwerkruimte. Elk knooppunt heeft een configuratieparameter voor het maximum aantal pods dat wordt ondersteund. Het equivalente aantal IP-adressen per knooppunt wordt vervolgens vooraf gereserveerd voor dat knooppunt. Deze aanpak vereist meer planning en leidt vaak tot uitputting van IP-adressen of tot de noodzaak om clusters in een groter subnet opnieuw samen te stellen naarmate de vraag naar uw toepassing toeneemt. U kunt de maximale pods configureren die kunnen worden geïmplementeerd op een knooppunt tijdens het maken van een cluster of bij het maken van nieuwe knooppuntgroepen. Als u niet opgeeft maxPods wanneer u nieuwe knooppuntgroepen maakt, ontvangt u een standaardwaarde van 110 voor kubenet.

In dit artikel leest u hoe u kubenet-netwerken gebruikt om een subnet voor een virtueel netwerk te maken en te gebruiken voor een AKS-cluster. Zie Netwerkconcepten voor Kubernetes en AKS voor meer informatie over netwerkopties en overwegingen.

Vereisten

• Het virtuele netwerk voor het AKS-cluster moet uitgaande internetverbinding toestaan.
• Maak niet meer dan één AKS-cluster in hetzelfde subnet.
• AKS-clusters kunnen het adresbereik van de Kubernetes-service, het adresbereik van de pod of het adresbereik van het virtuele clusternetwerk niet gebruiken169.254.0.0/16172.31.0.0/16172.30.0.0/16192.0.2.0/24. Het bereik kan niet worden bijgewerkt nadat u het cluster hebt gemaakt.
• De clusteridentiteit die door het AKS-cluster wordt gebruikt, moet ten minste de rol Netwerkbijdrager hebben in het subnet binnen uw virtuele netwerk. CLI helpt de roltoewijzing automatisch in te stellen. Als u een ARM-sjabloon of andere clients gebruikt, moet u de roltoewijzing handmatig instellen. U moet ook over de juiste machtigingen beschikken, zoals de eigenaar van het abonnement, om een clusteridentiteit te maken en deze machtigingen toe te wijzen. Als u een aangepaste rol wilt definiëren in plaats van de ingebouwde rol Inzender voor netwerken te gebruiken, hebt u de volgende machtigingen nodig:
  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

Waarschuwing

Als u Windows Server-knooppuntgroepen wilt gebruiken, moet u Azure CNI gebruiken. Het kubenet-netwerkmodel is niet beschikbaar voor Windows Server-containers.

Voordat u begint

U moet Azure CLI versie 2.0.65 of hoger hebben geïnstalleerd en geconfigureerd. Voer az --version uit om de versie te bekijken. Als u Azure CLI 2.0 wilt installeren of upgraden, raadpleegt u Azure CLI 2.0 installeren.

Overzicht van kubenet-netwerken met uw eigen subnet

In veel omgevingen hebt u virtuele netwerken en subnetten met toegewezen IP-adresbereiken gedefinieerd en gebruikt u deze resources om meerdere services en toepassingen te ondersteunen. AKS-clusters kunnen kubenet (basisnetwerken) of Azure CNI (geavanceerde netwerken) gebruiken om netwerkconnectiviteit te bieden.

Met kubenet ontvangen alleen de knooppunten een IP-adres in het subnet van het virtuele netwerk. Pods kunnen niet rechtstreeks met elkaar communiceren. In plaats daarvan verwerken door de gebruiker gedefinieerde routering (UDR) en doorsturen via IP de connectiviteit tussen pods tussen knooppunten. UDR's en configuratie voor doorsturen via IP worden standaard gemaakt en onderhouden door de AKS-service, maar u kunt desgewenst uw eigen routetabel gebruiken voor aangepast routebeheer . U kunt pods ook implementeren achter een service die een toegewezen IP-adres ontvangt en verkeer voor de toepassing verdeelt. In het volgende diagram ziet u hoe de AKS-knooppunten een IP-adres ontvangen in het subnet van het virtuele netwerk, maar niet de pods:

ondersteuning voor Azure maximaal 400 routes in een UDR, zodat u geen AKS-cluster kunt hebben dat groter is dan 400 knooppunten. Virtuele AKS-knooppunten en Azure-netwerkbeleid worden niet ondersteund met kubenet. Calico-netwerkbeleid wordt ondersteund.

Met Azure CNI ontvangt elke pod een IP-adres in het IP-subnet en kan deze rechtstreeks communiceren met andere pods en services. Uw clusters kunnen zo groot zijn als het IP-adresbereik dat u opgeeft. U moet echter vooraf het IP-adresbereik plannen en alle IP-adressen worden gebruikt door de AKS-knooppunten op basis van het maximum aantal pods dat ze kunnen ondersteunen. Geavanceerde netwerkfuncties en -scenario's, zoals virtuele knooppunten of netwerkbeleid (Azure of Calico), worden ondersteund met Azure CNI.

Beperkingen en overwegingen voor kubenet

• Er is een extra hop vereist in het ontwerp van kubenet, waardoor kleine latentie aan podcommunicatie wordt toegevoegd.
• Routetabellen en door de gebruiker gedefinieerde routes zijn vereist voor het gebruik van kubenet, waardoor bewerkingen complexer worden.
  • Zie Clusteruitgangen aanpassen met een door de gebruiker gedefinieerde routeringstabel in AKS en Uitgaand verkeer van clusters aanpassen met uitgaande typen in AKS voor meer informatie.
• Directe podadressering wordt niet ondersteund voor kubenet vanwege het kubenet-ontwerp.
• In tegenstelling tot Azure CNI-clusters kunnen meerdere Kubenet-clusters geen subnet delen.
• AKS past geen netwerkbeveiligingsgroepen (NSG's) toe op het subnet en wijzigt geen NSG's die aan dat subnet zijn gekoppeld. Als u uw eigen subnet opgeeft en NSG's toevoegt die aan dat subnet zijn gekoppeld, moet u ervoor zorgen dat de beveiligingsregels in de NSG's verkeer toestaan tussen het knooppunt en de CIDR van de pod. Zie Netwerkbeveiligingsgroepen voor meer informatie.
• Functies die niet worden ondersteund in kubenet zijn onder andere:
  • Azure-netwerkbeleid
  • Windows-knooppuntgroepen
  • Invoegtoepassing voor virtuele knooppunten

Notitie

Sommige systeempods, zoals konnectiviteit in het cluster, gebruiken het IP-adres van het hostknooppunt in plaats van een IP-adres uit de overlayadresruimte. De systeempods gebruiken alleen het IP-adres van het knooppunt en niet een IP-adres van het virtuele netwerk.

Beschikbaarheid en uitputting van IP-adressen

Een veelvoorkomend probleem met Azure CNI is dat het toegewezen IP-adresbereik te klein is om vervolgens meer knooppunten toe te voegen wanneer u een cluster schaalt of upgradet. Het netwerkteam kan mogelijk ook geen groot genoeg IP-adresbereik uitgeven om uw verwachte toepassingsvereisten te ondersteunen.

Als compromis kunt u een AKS-cluster maken dat gebruikmaakt van kubenet en verbinding maakt met een bestaand subnet van een virtueel netwerk. Met deze methode kunnen de knooppunten gedefinieerde IP-adressen ontvangen zonder dat een groot aantal IP-adressen vooraf hoeft te worden gereserveerd voor potentiële pods die in het cluster kunnen worden uitgevoerd. Met kubenet kunt u een veel kleiner IP-adresbereik gebruiken en grote clusters en toepassingsvereisten ondersteunen. Met een /27 IP-adresbereik op uw subnet kunt u bijvoorbeeld een cluster met 20-25 knooppunten uitvoeren met voldoende ruimte om te schalen of te upgraden. Deze clustergrootte kan maximaal 2.200-2.750 pods ondersteunen (met een standaard maximum van 110 pods per knooppunt). Het maximum aantal pods per knooppunt dat u kunt configureren met kubenet in AKS is 250.

De volgende basisberekeningen vergelijken het verschil in netwerkmodellen:

• kubenet: Een eenvoudig /24 IP-adresbereik kan maximaal 251 knooppunten in het cluster ondersteunen. Elk subnet van een virtueel Azure-netwerk reserveert de eerste drie IP-adressen voor beheerbewerkingen. Dit aantal knooppunten kan maximaal 27.610 pods ondersteunen, met een standaard maximum van 110 pods per knooppunt.
• Azure CNI: Hetzelfde basis-/24-subnetbereik kan maximaal acht knooppunten in het cluster ondersteunen. Dit aantal knooppunten kan maximaal 240 pods ondersteunen, met een standaard maximum van 30 pods per knooppunt.

Notitie

Bij deze maximumlimieten wordt geen rekening gehouden met upgrade- of schaalbewerkingen. In de praktijk kunt u het maximum aantal knooppunten dat het IP-adresbereik van het subnet ondersteunt, niet uitvoeren. U moet enkele IP-adressen beschikbaar laten voor het schalen of upgraden van bewerkingen.

Peering van virtuele netwerken en ExpressRoute-verbindingen

Om on-premises connectiviteit te bieden, kunnen kubenet- en Azure-CNI-netwerkbenaderingen gebruikmaken van peering van virtuele Azure-netwerken of ExpressRoute-verbindingen. Plan uw IP-adresbereiken zorgvuldig om overlapping en onjuiste verkeersroutering te voorkomen. Veel on-premises netwerken gebruiken bijvoorbeeld een adresbereik van 10.0.0.0/8 dat wordt geadverteerd via de ExpressRoute-verbinding. Het is raadzaam om uw AKS-clusters te maken in subnetten van virtuele Azure-netwerken buiten dit adresbereik, zoals 172.16.0.0/16.

Kies een netwerkmodel dat u wilt gebruiken

De volgende overwegingen helpen een overzicht te geven wanneer elk netwerkmodel mogelijk het meest geschikt is:

Gebruik kubenet wanneer:

• U hebt beperkte IP-adresruimte.
• De meeste podcommunicatie bevindt zich in het cluster.
• U hebt geen geavanceerde AKS-functies nodig, zoals virtuele knooppunten of Azure Network Policy.

Gebruik Azure CNI wanneer:

• U hebt beschikbare IP-adresruimte.
• De meeste podcommunicatie is naar resources buiten het cluster.
• U wilt geen door de gebruiker gedefinieerde routes beheren voor podconnectiviteit.
• U hebt geavanceerde AKS-functies nodig, zoals virtuele knooppunten of Azure Network Policy.

Zie Netwerkmodellen en hun ondersteuningsbereik vergelijken voor meer informatie om u te helpen bepalen welk netwerkmodel u wilt gebruiken.

Een virtueel netwerk en een subnet maken

1. Maak een resourcegroep met behulp van de az group create opdracht.

   az group create --name myResourceGroup --location eastus
   

2. Als u geen bestaand virtueel netwerk en subnet hebt dat u wilt gebruiken, maakt u deze netwerkbronnen met behulp van de az network vnet create opdracht. Met de volgende voorbeeldopdracht maakt u een virtueel netwerk met de naam myAKSVnet met het adresvoorvoegsel 192.168.0.0/16 en een subnet met de naam myAKSSubnet met het adresvoorvoegsel 192.168.1.0/24:

   az network vnet create \
       --resource-group myResourceGroup \
       --name myAKSVnet \
       --address-prefixes 192.168.0.0/16 \
       --subnet-name myAKSSubnet \
       --subnet-prefix 192.168.1.0/24 \
       --location eastus
   

3. Haal de resource-id van het subnet op met behulp van de az network vnet subnet show opdracht en sla deze op als een variabele met de naam SUBNET_ID voor later gebruik.

   SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)
   

Een AKS-cluster maken in het virtuele netwerk

Een AKS-cluster maken met door het systeem toegewezen beheerde identiteiten

Notitie

Wanneer u een door het systeem toegewezen identiteit gebruikt, verleent de Azure CLI de rol Netwerkbijdrager aan de door het systeem toegewezen identiteit nadat het cluster is gemaakt. Als u een ARM-sjabloon of andere clients gebruikt, moet u in plaats daarvan de door de gebruiker toegewezen beheerde identiteit gebruiken.

• Maak een AKS-cluster met door het systeem toegewezen beheerde identiteiten met behulp van de az aks create opdracht.

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --network-plugin kubenet \
      --service-cidr 10.0.0.0/16 \
      --dns-service-ip 10.0.0.10 \
      --pod-cidr 10.244.0.0/16 \
      --vnet-subnet-id $SUBNET_ID \
      --generate-ssh-keys 
  

  Implementatieparameters:

  • --service-cidr is optioneel. Dit adres wordt gebruikt om interne services in het AKS-cluster een IP-adres toe te wijzen. Dit IP-adresbereik moet een adresruimte zijn die elders in uw netwerkomgeving niet wordt gebruikt, inclusief on-premises netwerkbereiken als u verbinding maakt of verbinding wilt maken met uw virtuele Azure-netwerken met behulp van Express Route of een site-naar-site-VPN-verbinding. De standaardwaarde is 10.0.0.0/16.
  • --dns-service-ip is optioneel. Het adres moet het .10-adres van het IP-adresbereik van uw service zijn. De standaardwaarde is 10.0.0.10.
  • --pod-cidr is optioneel. Dit adres moet een grote adresruimte zijn die elders in uw netwerkomgeving niet wordt gebruikt. Dit bereik omvat alle on-premises netwerkbereiken als u verbinding maakt of verbinding wilt maken met uw virtuele Azure-netwerken met behulp van Express Route of een site-naar-site-VPN-verbinding. De standaardwaarde is 10.244.0.0/16.
    • Dit adresbereik moet groot genoeg zijn om tegemoet te komen aan het aantal knooppunten dat u verwacht op te schalen. U kunt dit adresbereik niet wijzigen zodra het cluster is geïmplementeerd.
    • Het IP-adresbereik van de pod wordt gebruikt om een /24-adresruimte toe te wijzen aan elk knooppunt in het cluster. In het volgende voorbeeld wijst de --pod-cidr van 10.244.0.0/16 het eerste knooppunt 10.244.0.0/24, het tweede knooppunt 10.244.1.0/24 en het derde knooppunt 10.244.2.0/24 toe.
    • Naarmate het cluster wordt geschaald of bijgewerkt, blijft het Azure-platform een IP-adresbereik voor pods toewijzen aan elk nieuw knooppunt.

Een AKS-cluster maken met door de gebruiker toegewezen beheerde identiteit

Een beheerde identiteit maken

• Maak een beheerde identiteit met behulp van de az identity opdracht. Als u een bestaande beheerde identiteit hebt, zoekt u in plaats daarvan de principal-id met behulp van de az identity show --ids <identity-resource-id> opdracht.

  az identity create --name myIdentity --resource-group myResourceGroup
  

  De uitvoer moet er ongeveer uitzien als in de volgende voorbeelduitvoer:

  {                                  
    "clientId": "<client-id>",
    "clientSecretUrl": "<clientSecretUrl>",
    "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
    "location": "westus2",
    "name": "myIdentity",
    "principalId": "<principal-id>",
    "resourceGroup": "myResourceGroup",                       
    "tags": {},
    "tenantId": "<tenant-id>",
    "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
  }
  

Roltoewijzing toevoegen voor beheerde identiteit

Als u de Azure CLI gebruikt, wordt de rol automatisch toegevoegd en kunt u deze stap overslaan. Als u een ARM-sjabloon of andere clients gebruikt, moet u de principal-id van de beheerde identiteit van het cluster gebruiken om een roltoewijzing uit te voeren.

• Haal de resource-id van het virtuele netwerk op met behulp van de az network vnet show opdracht en sla deze op als een variabele met de naam VNET_ID.

  VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)
  

• Wijs de beheerde identiteit toe voor de machtigingen voor inzender voor het AKS-cluster in het virtuele netwerk met behulp van de az role assignment create opdracht en geef de <principalId> op.

  az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"
  
  # Example command
  az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"
  

Notitie

Het kan 60 minuten duren voordat de machtiging die is verleend aan de beheerde identiteit van uw cluster die door Azure wordt gebruikt, is ingevuld.

Een AKS-cluster maken

• Maak een AKS-cluster met behulp van de az aks create opdracht en geef de resource-id van de beheerde identiteit van het besturingsvlak op voor het assign-identity argument om de door de gebruiker toegewezen beheerde identiteit toe te wijzen.

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --node-count 3 \
      --network-plugin kubenet \
      --vnet-subnet-id $SUBNET_ID \
      --assign-identity <identity-resource-id> \
      --generate-ssh-keys
  

Wanneer u een AKS-cluster maakt, worden automatisch een netwerkbeveiligingsgroep en routetabel gemaakt. Deze netwerkbronnen worden beheerd door het AKS-besturingsvlak. De netwerkbeveiligingsgroep wordt automatisch gekoppeld aan de virtuele NIC's op uw knooppunten. De routetabel wordt automatisch gekoppeld aan het subnet van het virtuele netwerk. Regels en routetabellen voor netwerkbeveiligingsgroepen worden automatisch bijgewerkt wanneer u services maakt en beschikbaar maakt.

Uw eigen subnet en routeringstabel meenemen met kubenet

Met kubenet moet er een routetabel bestaan in uw clustersubnet(s). AKS biedt ondersteuning voor het meenemen van uw eigen bestaande subnet en routetabel. Als uw aangepaste subnet geen routetabel bevat, maakt AKS er een voor u en voegt U regels toe gedurende de levenscyclus van het cluster. Als uw aangepaste subnet een routetabel bevat wanneer u uw cluster maakt, bevestigt AKS de bestaande routetabel tijdens clusterbewerkingen en voegt/updateregels dienovereenkomstig toe voor bewerkingen van de cloudprovider.

Waarschuwing

U kunt aangepaste regels toevoegen/bijwerken in de aangepaste routetabel. Regels worden echter toegevoegd door de Kubernetes-cloudprovider die niet kan worden bijgewerkt of verwijderd. Regels zoals 0.0.0.0/0 moeten altijd bestaan op een bepaalde routetabel en toewijzen aan het doel van uw internetgateway, zoals een NVA of een andere uitgaande gateway. Wees voorzichtig bij het bijwerken van regels.

Meer informatie over het instellen van een aangepaste routetabel.

Voor Kubenet-netwerken zijn geordend regels voor routetabellen vereist om aanvragen te routeren. Vanwege dit ontwerp moeten routetabellen zorgvuldig worden onderhouden voor elk cluster dat ervan afhankelijk is. Meerdere clusters kunnen geen routetabel delen omdat pod-CIDR's van verschillende clusters elkaar kunnen overlappen, wat onverwachte en verbroken routeringsscenario's veroorzaakt. Houd rekening met de volgende beperkingen bij het configureren van meerdere clusters in hetzelfde virtuele netwerk of het toewijzen van een virtueel netwerk aan elk cluster:

• Een aangepaste routetabel moet zijn gekoppeld aan het subnet voordat u het AKS-cluster maakt.
• De gekoppelde routetabelresource kan niet worden bijgewerkt nadat het cluster is gemaakt. Aangepaste regels kunnen echter worden gewijzigd in de routetabel.
• Elk AKS-cluster moet één unieke routetabel gebruiken voor alle subnetten die aan het cluster zijn gekoppeld. U kunt een routetabel met meerdere clusters niet opnieuw gebruiken vanwege het potentieel voor overlappende pod-CIDR's en conflicterende routeringsregels.
• Voor door het systeem toegewezen beheerde identiteit wordt het alleen ondersteund om uw eigen subnet en routetabel via Azure CLI op te geven, omdat Azure CLI de roltoewijzing automatisch toevoegt. Als u een ARM-sjabloon of andere clients gebruikt, moet u een door de gebruiker toegewezen beheerde identiteit gebruiken, machtigingen toewijzen voordat het cluster wordt gemaakt en ervoor zorgen dat de door de gebruiker toegewezen identiteit schrijfmachtigingen heeft voor uw aangepaste subnet en aangepaste routetabel.
• Het gebruik van dezelfde routetabel met meerdere AKS-clusters wordt niet ondersteund.

Notitie

Wanneer u uw eigen VNet en routetabel maakt en gebruikt met de kubenet-netwerkinvoegtoepassing, moet u een door de gebruiker toegewezen beheerde identiteit voor het cluster configureren. Met een door het systeem toegewezen beheerde identiteit kunt u de id-id niet ophalen voordat u een cluster maakt, wat een vertraging veroorzaakt tijdens de roltoewijzing.

Zowel door het systeem toegewezen als door de gebruiker toegewezen beheerde identiteiten worden ondersteund wanneer u uw eigen VNet en routetabel maakt en gebruikt met de Azure-netwerkinvoegtoepassing. We raden u ten zeerste aan om een door de gebruiker toegewezen beheerde identiteit te gebruiken voor BYO-scenario's.

Een routetabel met een door de gebruiker toegewezen beheerde identiteit toevoegen aan uw AKS-cluster

Nadat u een aangepaste routetabel hebt gemaakt en deze hebt gekoppeld aan een subnet in uw virtuele netwerk, kunt u een nieuw AKS-cluster maken dat uw routetabel opgeeft met een door de gebruiker toegewezen beheerde identiteit. U moet de subnet-id gebruiken voor de locatie waar u uw AKS-cluster wilt implementeren. Dit subnet moet ook zijn gekoppeld aan uw aangepaste routetabel.

1. Haal de subnet-id op met behulp van de az network vnet subnet list opdracht.

   az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]
   

2. Maak een AKS-cluster met een aangepast subnet dat vooraf is geconfigureerd met een routetabel met behulp van de az aks create opdracht en geef uw waarden op voor de --vnet-subnet-id en --assign-identity parameters.

   az aks create \
       --resource-group myResourceGroup \
       --name myManagedCluster \
       --vnet-subnet-id mySubnetIDResourceID \
       --assign-identity controlPlaneIdentityResourceID \
       --generate-ssh-keys
   

Volgende stappen

In dit artikel hebt u gezien hoe u uw AKS-cluster implementeert in het bestaande subnet van het virtuele netwerk. U kunt nu beginnen met het maken van nieuwe apps met Helm of het implementeren van bestaande apps met behulp van Helm.