Overzicht van Azure CNI-netwerken in Azure Kubernetes Service (AKS)

AKS-clusters maken standaard gebruik van kubenet en maken een virtueel netwerk en subnet. Met kubenet krijgen knooppunten een IP-adres van een subnet van een virtueel netwerk. Nat (Network Address Translation) wordt vervolgens geconfigureerd op de knooppunten en pods ontvangen een IP-adres 'verborgen' achter het IP-adres van het knooppunt. Deze aanpak vermindert het aantal IP-adressen dat u in uw netwerkruimte moet reserveren om pods te kunnen gebruiken.

Met Azure Container Networking Interface (CNI) krijgt elke pod een IP-adres van het subnet en kan deze rechtstreeks worden geopend. Systemen in hetzelfde virtuele netwerk als het AKS-cluster zien het IP-adres van de pod als het bronadres voor verkeer van de pod. Systemen buiten het virtuele netwerk van het AKS-cluster zien het IP-adres van het knooppunt als bronadres voor verkeer van de pod. Deze IP-adressen moeten uniek zijn binnen uw netwerkruimte en moeten van tevoren worden gepland. 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.

Notitie

In dit artikel maakt u alleen kennis met traditionele Azure CNI. Voor Azure CNI-overlay, Azure CNI VNet voor dynamische IP-toewijzing en Azure CNI VNet - Statische bloktoewijzing (preview). Raadpleeg in plaats daarvan hun documentatie.

Vereisten

  • Het virtuele netwerk voor het AKS-cluster moet uitgaande internetverbinding toestaan.

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

  • De clusteridentiteit die door het AKS-cluster wordt gebruikt, moet ten minste machtigingen voor netwerkbijdrager hebben voor het subnet binnen uw virtuele netwerk. Als u een aangepaste rol wilt definiëren in plaats van de ingebouwde rol Netwerkbijdrager te gebruiken, zijn de volgende machtigingen vereist:

    • Microsoft.Network/virtualNetworks/subnets/join/action

    • Microsoft.Network/virtualNetworks/subnets/read

    • Microsoft.Authorization/roleAssignments/write

  • Het subnet dat is toegewezen aan de AKS-knooppuntgroep kan geen gedelegeerd subnet zijn.

  • 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 binnen het CIDR-bereik van het knooppunt. Zie Netwerkbeveiligingsgroepen voor meer informatie.

IP-adressering plannen voor uw cluster

Clusters die zijn geconfigureerd met Azure CNI-netwerken, vereisen extra planning. De grootte van uw virtuele netwerk en het bijbehorende subnet moet voldoen aan het aantal pods dat u wilt uitvoeren en het aantal knooppunten voor het cluster.

IP-adressen voor de pods en de knooppunten van het cluster worden toegewezen vanuit het opgegeven subnet in het virtuele netwerk. Elk knooppunt wordt geconfigureerd met een primair IP-adres. Azure CNI configureert standaard 30 extra IP-adressen. Deze IP-adressen worden toegewezen aan pods die zijn gepland op het knooppunt. Wanneer u het cluster uitbreidt, wordt elk knooppunt op dezelfde manier geconfigureerd met IP-adressen van het subnet. U kunt ook de maximumpods per knooppunt weergeven.

Belangrijk

Het vereiste aantal IP-adressen moet overwegingen bevatten voor upgrade- en schaalbewerkingen. Als u het IP-adresbereik instelt om alleen een vast aantal knooppunten te ondersteunen, kunt u uw cluster niet upgraden of schalen.

  • Wanneer u uw AKS-cluster bijwerken , wordt er een nieuw knooppunt geïmplementeerd in het cluster. Services en workloads worden uitgevoerd op het nieuwe knooppunt en een ouder knooppunt wordt verwijderd uit het cluster. Voor dit rolling upgradeproces moet minimaal één extra blok IP-adressen beschikbaar zijn. Het aantal knooppunten is dan n + 1.

    • Deze overweging is met name belangrijk wanneer u Windows Server-knooppuntgroepen gebruikt. Windows Server-knooppunten in AKS passen windows-updates niet automatisch toe. In plaats daarvan voert u een upgrade uit op de knooppuntgroep. Met deze upgrade worden nieuwe knooppunten geïmplementeerd met de nieuwste installatiekopieën van windows Server 2019-basisknooppunten en beveiligingspatches. Zie Een knooppuntgroep upgraden in AKS voor meer informatie over het upgraden van een Windows Server-knooppuntgroep.
  • Wanneer u een AKS-cluster schaalt, wordt er een nieuw knooppunt geïmplementeerd in het cluster. Services en workloads worden uitgevoerd op het nieuwe knooppunt. Uw IP-adresbereik moet rekening houden met de vraag hoe u het aantal knooppunten en pods dat uw cluster kan ondersteunen, omhoog wilt schalen. Er moet ook een extra knooppunt voor upgradebewerkingen worden opgenomen. Het aantal knooppunten is dan n + number-of-additional-scaled-nodes-you-anticipate + 1.

Als u verwacht dat uw knooppunten het maximum aantal pods uitvoeren en pods regelmatig vernietigen en implementeren, moet u ook rekening houden met enkele extra IP-adressen per knooppunt. Een paar seconden kan vereist zijn om een service te verwijderen en het IP-adres vrij te geven voordat een nieuwe service wordt geïmplementeerd en het adres wordt verkregen. Deze extra IP-adressen beschouwen deze mogelijkheid.

Het IP-adresplan voor een AKS-cluster bestaat uit een virtueel netwerk, ten minste één subnet voor knooppunten en pods en een Kubernetes-serviceadresbereik.

Adresbereik/Azure-resource Limieten en grootte
Virtueel netwerk Het virtuele Azure-netwerk kan zo groot zijn als /8, maar is beperkt tot 65.536 geconfigureerde IP-adressen. Houd rekening met al uw netwerkbehoeften, inclusief communicatie met services in andere virtuele netwerken, voordat u uw adresruimte configureert. Als u bijvoorbeeld te groot van een adresruimte configureert, kan het zijn dat u problemen ondervindt met overlappende andere adresruimten in uw netwerk.
Subnet Moet groot genoeg zijn voor de knooppunten, pods en alle Kubernetes- en Azure-resources die in uw cluster kunnen worden ingericht. Als u bijvoorbeeld een interne Azure Load Balancer implementeert, worden de front-end-IP-adressen toegewezen vanuit het clustersubnet, geen openbare IP-adressen. De subnetgrootte moet ook rekening houden met upgradebewerkingen of toekomstige schaalbehoeften.

Gebruik de volgende vergelijking om de minimale subnetgrootte te berekenen, inclusief een extra knooppunt voor upgradebewerkingen: (number of nodes + 1) + ((number of nodes + 1) * maximum pods per node that you configure)

Voorbeeld voor een cluster met 50 knooppunten: (51) + (51 * 30 (default)) = 1,581 (/21 of groter)

Voorbeeld voor een cluster met 50 knooppunten dat ook de voorbereiding omvat om een extra 10 knooppunten op te schalen: (61) + (61 * 30 (default)) = 1,891 (/21 of groter)

Als u geen maximum aantal pods per knooppunt opgeeft wanneer u uw cluster maakt, wordt het maximum aantal pods per knooppunt ingesteld op 30. Het minimale aantal vereiste IP-adressen is gebaseerd op die waarde. Als u uw minimale IP-adresvereisten voor een andere maximumwaarde berekent, raadpleegt u Maximumpods per knooppunt om deze waarde in te stellen wanneer u uw cluster implementeert.

Adresbereik van Kubernetes Service Elk netwerkelement in of verbonden met dit virtuele netwerk mag dit bereik niet gebruiken. Serviceadres CIDR moet kleiner zijn dan /12. U kunt dit bereik opnieuw gebruiken in verschillende AKS-clusters.
IP-adres van DNS-service van Kubernetes IP-adres binnen het Kubernetes-serviceadresbereik dat wordt gebruikt door clusterservicedetectie. Gebruik niet het eerste IP-adres in uw adresbereik. Het eerste adres in het subnetbereik wordt gebruikt voor het adres kubernetes.default.svc.cluster.local .

Maximum aantal pods per knooppunt

Het maximum aantal pods per knooppunt in een AKS-cluster is 250. Het standaard maximum aantal pods per knooppunt varieert tussen kubenet - en Azure CNI-netwerken en de methode voor clusterimplementatie.

Implementatiemethode Kubenet-standaard Azure CNI-standaard Configureerbaar bij implementatie
Azure-CLI 110 30 Ja (maximaal 250)
Resource Manager-sjabloon 110 30 Ja (maximaal 250)
Portal 110 110 (configureerbaar op het tabblad Knooppuntgroepen) Ja (maximaal 250)

Maximum aantal pods per knooppunt configureren voor nieuwe clusters

U kunt het maximum aantal pods per knooppunt configureren tijdens de clusterimplementatie of wanneer u nieuwe knooppuntgroepen toevoegt. U kunt de maximale pods per knooppuntwaarde instellen tot 250.

Als u geen maxPods opgeeft bij het maken van nieuwe knooppuntgroepen, ontvangt u een standaardwaarde van 30 voor Azure CNI.

Een minimumwaarde voor maximale pods per knooppunt wordt afgedwongen om ruimte te garanderen voor systeempods die essentieel zijn voor de clusterstatus. De minimumwaarde die kan worden ingesteld voor maximumpods per knooppunt is 10 als en alleen als de configuratie van elke knooppuntgroep ruimte heeft voor minimaal 30 pods. Als u bijvoorbeeld de maximumpods per knooppunt instelt op minimaal 10, moet elke afzonderlijke knooppuntgroep minimaal drie knooppunten hebben. Deze vereiste geldt ook voor elke nieuwe knooppuntgroep die is gemaakt. Als er dus 10 als maximumpods per knooppunt zijn gedefinieerd, moet elke volgende knooppuntgroep ten minste drie knooppunten bevatten.

Netwerken Minimum Maximum
Azure CNI 10 250
Kubenet 10 250

Notitie

De minimale waarde in de vorige tabel wordt strikt afgedwongen door de AKS-service. U kunt geen waarde instellen voor maxPods die lager is dan het minimum dat wordt weergegeven, omdat dit kan voorkomen dat het cluster wordt gestart.

  • Azure CLI: Geef het --max-pods argument op wanneer u een cluster implementeert met de opdracht az aks create . De maximumwaarde is 250.
  • Resource Manager-sjabloon: Geef de maxPods eigenschap op in het object ManagedClusterAgentPoolProfile wanneer u een cluster met een Resource Manager-sjabloon implementeert. De maximumwaarde is 250.
  • Azure Portal: Wijzig het veld in de instellingen van de knooppuntgroep bij het Max pods per node maken van een cluster of het toevoegen van een nieuwe knooppuntgroep.

Maximum aantal pods per knooppunt configureren voor bestaande clusters

De maxPods per knooppuntinstelling kunnen worden gedefinieerd wanneer u een nieuwe knooppuntgroep maakt. Als u de maxPods-instelling op een bestaand cluster wilt verhogen, voegt u een nieuwe knooppuntgroep toe met het nieuwe gewenste aantal maxPods . Nadat u uw pods naar de nieuwe pool hebt gemigreerd, verwijdert u de oudere pool. Als u een oudere pool in een cluster wilt verwijderen, moet u ervoor zorgen dat u de modi voor knooppuntgroepen instelt zoals gedefinieerd in het document met systeemknooppuntgroepen.

Implementatieparameters

Wanneer u een AKS-cluster maakt, kunnen de volgende parameters worden geconfigureerd voor Azure CNI-netwerken:

Virtueel netwerk: het virtuele netwerk waarin u het Kubernetes-cluster wilt implementeren. Als u een nieuw virtueel netwerk voor uw cluster wilt maken, selecteert u Nieuw maken en volgt u de stappen in de sectie Virtueel netwerk maken. Als u een bestaand virtueel netwerk wilt selecteren, moet u ervoor zorgen dat het zich op dezelfde locatie en hetzelfde Azure-abonnement bevindt als uw Kubernetes-cluster. Zie azure-abonnements- en servicelimieten, quota en beperkingen voor azure voor informatie over de limieten en quota voor een virtueel Azure-netwerk.

Subnet: het subnet in het virtuele netwerk waar u het cluster wilt implementeren. Als u een nieuw subnet wilt maken in het virtuele netwerk voor uw cluster, selecteert u Nieuw maken en volgt u de stappen in de sectie Subnet maken. Voor hybride connectiviteit mag het adresbereik niet overlappen met andere virtuele netwerken in uw omgeving.

Azure Network Plugin: Wanneer de Azure-netwerkinvoegtoepassing wordt gebruikt, kan de interne LoadBalancer-service met 'externalTrafficPolicy=Local' niet worden geopend vanaf VM's met een IP in clusterCIDR die niet tot het AKS-cluster behoort.

Kubernetes-serviceadresbereik: deze parameter is de set virtuele IP-adressen die Kubernetes toewijst aan interne services in uw cluster. Dit bereik kan niet worden bijgewerkt nadat u het cluster hebt gemaakt. U kunt elk privéadresbereik gebruiken dat voldoet aan de volgende vereisten:

  • Mag zich niet binnen het IP-adresbereik van het virtuele netwerk van uw cluster bevinden
  • Mag niet overlappen met andere virtuele netwerken waarmee het virtuele clusternetwerk peers
  • Mag niet overlappen met on-premises IP-adressen
  • Mag niet binnen de bereiken169.254.0.0/16, 172.30.0.0/16, of 172.31.0.0/16192.0.2.0/24

Hoewel het technisch mogelijk is om een serviceadresbereik op te geven binnen hetzelfde virtuele netwerk als uw cluster, wordt dit niet aanbevolen. Onvoorspelbaar gedrag kan resulteren als overlappende IP-bereiken worden gebruikt. Zie de sectie Veelgestelde vragen van dit artikel voor meer informatie. Zie Services in de Kubernetes-documentatie voor meer informatie over Kubernetes-services .

IP-adres van kubernetes DNS-service: het IP-adres voor de DNS-service van het cluster. Dit adres moet binnen het adresbereik van Kubernetes Service liggen. Gebruik niet het eerste IP-adres in uw adresbereik. Het eerste adres in het subnetbereik wordt gebruikt voor het adres kubernetes.default.svc.cluster.local .

Veelgestelde vragen

  • Kan ik VM's implementeren in mijn clustersubnet?

    Ja. Maar voor Azure CNI voor dynamische IP-toewijzing kunnen de VM's niet worden geïmplementeerd in het subnet van de pod.

  • Welk bron-IP-adres zien externe systemen voor verkeer dat afkomstig is van een pod met Azure CNI?

    Systemen in hetzelfde virtuele netwerk als het AKS-cluster zien het IP-adres van de pod als het bronadres voor verkeer van de pod. Systemen buiten het virtuele netwerk van het AKS-cluster zien het IP-adres van het knooppunt als bronadres voor verkeer van de pod.

    Maar voor Azure CNI voor dynamische IP-toewijzing, ongeacht of de verbinding zich in hetzelfde virtuele netwerk of in meerdere virtuele netwerken bevindt, is het ip-adres van de pod altijd het bronadres voor verkeer van de pod. Dit komt doordat de Azure CNI voor dynamische IP-toewijzing microsoft Azure Container Networking-infrastructuur implementeert, wat end-to-end ervaring biedt. Daarom elimineert het gebruik van ip-masq-agent, dat nog steeds wordt gebruikt door traditionele Azure CNI.

  • Kan ik netwerkbeleid per pod configureren?

    Ja, Kubernetes-netwerkbeleid is beschikbaar in AKS. Zie Verkeer tussen pods beveiligen met behulp van netwerkbeleid in AKS om aan de slag te gaan.

  • Kan het maximum aantal pods worden geïmplementeerd op een knooppunt dat kan worden geconfigureerd?

    Ja, wanneer u een cluster implementeert met de Azure CLI of een Resource Manager-sjabloon. Zie Maximum aantal pods per knooppunt.

    U kunt het maximum aantal pods per knooppunt op een bestaand cluster niet wijzigen.

  • Hoe kan ik aanvullende eigenschappen configureren voor het subnet dat ik heb gemaakt tijdens het maken van een AKS-cluster? Bijvoorbeeld service-eindpunten.

    De volledige lijst met eigenschappen voor het virtuele netwerk en subnetten die u tijdens het maken van een AKS-cluster maakt, kan worden geconfigureerd op de standaardpagina voor configuratie van virtuele netwerken in Azure Portal.

  • Kan ik een ander subnet in mijn virtuele clusternetwerk gebruiken voor het adresbereik van de Kubernetes-service?

    Dit wordt niet aanbevolen, maar deze configuratie is mogelijk. Het serviceadresbereik is een set virtuele IP's (VIP's) die Kubernetes toewijst aan interne services in uw cluster. Azure Networking heeft geen inzicht in het IP-adresbereik van de service van het Kubernetes-cluster. Het gebrek aan zichtbaarheid in het servicebereik van het cluster kan leiden tot problemen. Het is mogelijk om later een nieuw subnet te maken in het virtuele clusternetwerk dat overlapt met het serviceadresbereik. Als een dergelijke overlapping optreedt, kan Kubernetes een service toewijzen aan een IP-adres dat al wordt gebruikt door een andere resource in het subnet, wat onvoorspelbaar gedrag of fouten veroorzaakt. Door ervoor te zorgen dat u een adresbereik buiten het virtuele netwerk van het cluster gebruikt, kunt u dit overlappingsrisico voorkomen.

Volgende stap

Meer informatie over netwerken in AKS vindt u in de volgende artikelen: