CNI-podsubnet (Azure Container Networking Interface)
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 deaks-preview
extensieversie2.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.
Azure Kubernetes Service