Share via

CNI-podsubnet (Azure Container Networking Interface)

  • Artikel

Azure CNI Pod Subnet wijst IP-adressen toe aan pods uit een afzonderlijk subnet van uw clusterknooppunten. Deze functie is beschikbaar in twee modi: dynamische IP-toewijzing en statische bloktoewijzing (preview).

Vereisten

Notitie

Wanneer u statische bloktoewijzing van CIDR's gebruikt, wordt het beschikbaar maken van een toepassing als een Private Link-service met behulp van een Kubernetes Load Balancer-service niet ondersteund.

  • Bekijk de vereisten voor het configureren van eenvoudige Azure CNI-netwerken in AKS, aangezien dezelfde vereisten van toepassing zijn op dit artikel.

  • Controleer de implementatieparameters voor het configureren van eenvoudige Azure CNI-netwerken in AKS, omdat dezelfde parameters van toepassing zijn.

  • AKS Engine- en DIY-clusters worden niet ondersteund.

  • Azure CLI-versie 2.37.0 of hoger en de aks-preview extensieversie 2.0.0b2 of hoger.

  • Registreer de functievlag op abonnementsniveau voor uw abonnement: 'Microsoft.ContainerService/AzureVnetScalePreview'.

  • Als u een bestaand cluster hebt, moet u de Container Insights inschakelen voor het bewaken van de invoegtoepassing IP-subnetgebruik. U kunt Container Insights inschakelen met behulp van de az aks enable-addons opdracht, zoals wordt weergegeven in het volgende voorbeeld:

    az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>

Dynamische IP-toewijzingsmodus

Dynamische IP-toewijzing helpt bij het beperken van problemen met het IP-adres van pods door pod-IP-adressen toe te wijzen vanuit een subnet dat losstaat van het subnet dat als host fungeert voor het AKS-cluster.

De dynamische IP-toewijzingsmodus biedt de volgende voordelen:

  • Beter IP-gebruik: IP-adressen worden dynamisch toegewezen aan clusterpods vanuit het subnet Pods. Dit leidt tot een beter gebruik van IP-adressen in het cluster in vergelijking met de traditionele CNI-oplossing, die statische toewijzing van IP-adressen voor elk knooppunt uitvoert.
  • Schaalbaar en flexibel: subnetten van knooppunten en pods kunnen onafhankelijk worden geschaald. Eén podsubnet kan worden gedeeld over meerdere knooppuntgroepen van een cluster of over meerdere AKS-clusters die in hetzelfde VNet zijn geïmplementeerd. U kunt ook een afzonderlijk podsubnet configureren voor een knooppuntgroep.
  • Hoge prestaties: omdat pods VNet-IP's krijgen toegewezen, hebben ze directe connectiviteit met andere clusterpods en -resources in het VNet. De oplossing ondersteunt zeer grote clusters zonder dat de prestaties afnemen.
  • Afzonderlijk VNet-beleid voor pods: aangezien pods een afzonderlijk subnet hebben, kunt u afzonderlijke VNet-beleidsregels configureren die afwijken van knooppuntbeleid. Dit maakt veel nuttige scenario's mogelijk, zoals het toestaan van internetverbinding alleen voor pods en niet voor knooppunten, het herstellen van het bron-IP-adres voor pods in een knooppuntgroep met behulp van een Azure NAT-gateway en het gebruik van netwerkbeveiligingsgroepen (NSG's) om verkeer tussen knooppuntgroepen te filteren.
  • Kubernetes-netwerkbeleid: zowel het Azure-netwerkbeleid als Calico werken met deze modus.

IP-adressering plannen

Met dynamische IP-toewijzing worden knooppunten en pods onafhankelijk geschaald, zodat u hun adresruimten afzonderlijk kunt plannen. Aangezien podsubnetten kunnen worden geconfigureerd voor de granulariteit van een knooppuntgroep, kunt u altijd een nieuw subnet toevoegen wanneer u een knooppuntgroep toevoegt. De systeempods in een cluster-/knooppuntgroep ontvangen ook IP-adressen van het subnet van de pod, dus dit gedrag moet worden verwerkt.

IP-adressen worden toegewezen aan knooppunten in batches van 16. Ip-toewijzing van podsubnet moet worden gepland met minimaal 16 IP-adressen per knooppunt in het cluster, omdat de knooppunten 16 IP-adressen aanvragen bij het opstarten en een andere batch van 16 aanvragen wanneer er <8 IP's niet zijn toegewezen in hun toewijzing.

De planning van IP-adressen voor Kubernetes-services en Docker Bridge blijft ongewijzigd.

Statische modus voor bloktoewijzing (preview)

Met statische bloktoewijzing kunt u de grootte van potentiële podsubnetten en azure-adrestoewijzingsbeperkingen beperken door CIDR-blokken toe te wijzen aan knooppunten in plaats van afzonderlijke IP-adressen.

De statische bloktoewijzingsmodus biedt de volgende voordelen:

  • Betere SCHAALBAARHEID van IP: CIDR-blokken worden statisch toegewezen aan de clusterknooppunten en zijn aanwezig voor de levensduur van het knooppunt, in tegenstelling tot de traditionele dynamische toewijzing van afzonderlijke IP-adressen met traditionele CNI. Dit maakt routering op basis van CIDR-blokken mogelijk en helpt bij het schalen van de clusterlimiet tot 1 miljoen pods van de traditionele 65.000 pods per cluster. Uw virtuele Azure-netwerk moet groot genoeg zijn om de schaal van uw cluster aan te kunnen.
  • Flexibiliteit: subnetten van knooppunten en pods kunnen onafhankelijk worden geschaald. Eén podsubnet kan worden gedeeld over meerdere knooppuntgroepen van een cluster of over meerdere AKS-clusters die in hetzelfde VNet zijn geïmplementeerd. U kunt ook een afzonderlijk podsubnet configureren voor een knooppuntgroep.
  • Hoge prestaties: omdat pods ip-adressen van virtuele netwerken krijgen toegewezen, hebben ze directe connectiviteit met andere clusterpods en -resources in het VNet.
  • Afzonderlijk VNet-beleid voor pods: aangezien pods een afzonderlijk subnet hebben, kunt u afzonderlijke VNet-beleidsregels configureren die afwijken van knooppuntbeleid. Dit maakt veel nuttige scenario's mogelijk, zoals het toestaan van internetverbinding alleen voor pods en niet voor knooppunten, het herstellen van het bron-IP-adres voor pods in een knooppuntgroep met behulp van een Azure NAT-gateway en het gebruik van NSG's om verkeer tussen knooppuntgroepen te filteren.
  • Kubernetes-netwerkbeleid: Cilium, Azure NPM en Calico werken met deze oplossing.

Beperkingen

Hieronder ziet u enkele beperkingen voor het gebruik van azure CNI Static Block Allocation:

  • Minimale Kubernetes-versie is 1.28 vereist
  • De maximale ondersteunde subnetgrootte is x.x.x.x/12 ~ 1 miljoen IP-adressen
  • Per subnet kan slechts één bewerkingsmodus worden gebruikt. Als een subnet de statische bloktoewijzingsmodus gebruikt, kan het geen dynamische IP-toewijzingsmodus gebruiken in een ander cluster of knooppuntgroep met hetzelfde subnet en omgekeerd.
  • Alleen ondersteund in nieuwe clusters of bij het toevoegen van knooppuntgroepen met een ander subnet aan bestaande clusters. Het migreren of bijwerken van bestaande clusters of knooppuntgroepen wordt niet ondersteund.
  • In alle CIDR-blokken die zijn toegewezen aan een knooppunt in de knooppuntgroep, wordt één IP geselecteerd als het primaire IP-adres van het knooppunt. Voor netwerkbeheerders die de --max-pods waarde selecteren, probeert u de onderstaande berekening te gebruiken om uw behoeften optimaal te kunnen benutten en optimaal gebruik te maken van IP-adressen in het subnet:

max_pods = (N * 16) - 1 waarbij N een positief geheel getal en N> 0 is

Regionale beschikbaarheid

Deze functie is niet beschikbaar in de volgende regio's:

  • VS Zuid
  • VS - oost 2
  • VS - west
  • VS - west 2

IP-adressering plannen

Met statische bloktoewijzing worden knooppunten en pods onafhankelijk geschaald, zodat u hun adresruimten afzonderlijk kunt plannen. Aangezien podsubnetten kunnen worden geconfigureerd voor de granulariteit van een knooppuntgroep, kunt u altijd een nieuw subnet toevoegen wanneer u een knooppuntgroep toevoegt. De systeempods in een cluster-/knooppuntgroep ontvangen ook IP-adressen van het subnet van de pod, dus dit gedrag moet worden verwerkt.

CIDR-blokken van /28 (16 IP's) worden toegewezen aan knooppunten op basis van uw --max-pods configuratie voor uw knooppuntgroep, waarmee het maximum aantal pods per knooppunt wordt gedefinieerd. 1 IP is gereserveerd op elk knooppunt van alle beschikbare IP-adressen op dat knooppunt voor interne doeleinden.

Tijdens het plannen van uw IP-adressen is het belangrijk om uw --max-pods configuratie te definiëren met behulp van de volgende berekening: max_pods_per_node = (16 * N) - 1, waarbij N een positief geheel getal groter is dan 0.

Voor ideale waarden zonder IP-verspilling is de maximale waarde voor pods vereist om te voldoen aan de bovenstaande expressie.

Bekijk de volgende voorbeeldscenario's:

Voorbeeld max_pods TOEGEWEZEN CIDR-blokken per knooppunt Totaal IP-adres dat beschikbaar is voor pods IP-verspilling voor knooppunt
Laag verspilling (acceptabel) 30 2 (16 * 2) - 1 = 32 - 1 = 31 31 - 30 = 1
Ideale case 31 2 (16 * 2) - 1 = 32 - 1 = 31 31 - 31 = 0
Hoog verspilling (niet aanbevolen) 32 3 (16 * 3) - 1 = 48 - 1 = 47 47 - 32 = 15

De planning van IP-adressen voor Kubernetes-services blijft ongewijzigd.

Notitie

Zorg ervoor dat uw VNet voldoende grote en aaneengesloten adresruimte heeft ter ondersteuning van de schaal van uw cluster.