Delen via

AKS Legacy Container Networking Interfaces (CNI)

  • Artikel

In Azure Kubernetes Service (AKS) worden verouderde netwerkmodellen zoals Azure CNI Node Subnet en kubenet nog steeds beschikbaar en ondersteund, terwijl Azure CNI-overlay en Azure CNI Pod Subnet worden aanbevolen voor de meeste scenario's. Deze verouderde modellen bieden verschillende benaderingen voor ip-adresbeheer en netwerken voor pods, elk met een eigen set mogelijkheden en overwegingen. Dit artikel bevat een overzicht van deze verouderde netwerkopties, waarin de vereisten, implementatieparameters en belangrijke kenmerken worden beschreven, zodat u inzicht krijgt in hun rollen en hoe ze effectief kunnen worden gebruikt in uw AKS-clusters.

Vereisten

De volgende vereisten zijn vereist voor het Subnet van Azure CNI Node en kubenet:

  • 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 inzender voor het netwerk in het virtuele netwerk hebben. 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.

Notitie

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

Subnet van Azure CNI-knooppunt

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.

Met azure CNI Node Subnet 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.

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. U kunt een nieuw virtueel netwerk maken of een bestaand netwerk gebruiken. Als u een bestaand virtueel netwerk wilt gebruiken, 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. U kunt nieuwe subnetten toevoegen aan het virtuele netwerk tijdens het maken van het cluster. 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 heeft.
  • Mag niet overlappen met on-premises IP-adressen.
  • Mag niet binnen de bereiken 169.254.0.0/16, 172.30.0.0/16of 172.31.0.0/16192.0.2.0/24.

Hoewel het mogelijk is om een serviceadresbereik op te geven binnen hetzelfde virtuele netwerk als uw cluster, raden we dit niet aan. Overlappende IP-bereiken kunnen onvoorspelbaar gedrag opleveren. Zie de veelgestelde vragen 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 .

Kubenet

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.

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.

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:

Een diagram met twee knooppunten met drie pods die elk worden uitgevoerd in een Overlay-netwerk. Podverkeer naar eindpunten buiten het cluster wordt gerouteerd via NAT.

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.

Beperkingen en overwegingen voor kubenet

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 8 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

U kunt peering van virtuele Azure-netwerken of ExpressRoute-verbindingen gebruiken met Azure CNI en kubenet om on-premises connectiviteit te bieden. Zorg ervoor dat u uw IP-adressen zorgvuldig plant 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.

Zie Netwerkmodellen en hun ondersteuningsbereiken vergelijken voor meer informatie.

Veelgestelde vragen over Azure CNI Pod Subnet

  • Kan ik VM's implementeren in mijn clustersubnet?

    Ja voor Azure CNI Node Subnet, de VM's kunnen worden geïmplementeerd in hetzelfde subnet als het AKS-cluster.

  • 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 dynamische IP-toewijzing van Azure CNI, ongeacht of de verbinding zich binnen 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?

    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.

  • 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 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. Ja, wanneer u een cluster implementeert met de Azure CLI of een Resource Manager-sjabloon. Zie Maximum aantal pods per knooppunt.

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