Dela via


Azure Container Networking Interface (CNI) Överläggsnätverk

Med Azure CNI Overlay distribueras klusternoderna till ett undernät för Azure Virtual Network (VNet). Poddar tilldelas IP-adresser från en privat CIDR som logiskt skiljer sig från det virtuella nätverk som är värd för noderna. Podd- och nodtrafik i klustret använder ett Overlay-nätverk. NAT (Network Address Translation) använder nodens IP-adress för att nå resurser utanför klustret. Den här lösningen sparar en betydande mängd VNet-IP-adresser och gör att du kan skala klustret till stora storlekar. En extra fördel är att du kan återanvända den privata CIDR i olika AKS-kluster, vilket utökar det TILLGÄNGLIGA IP-utrymmet för containerbaserade program i Azure Kubernetes Service (AKS).

Översikt över Overlay-nätverk

I Overlay-nätverk tilldelas endast Kubernetes-klusternoderna IP-adresser från undernät. Poddar tar emot IP-adresser från en privat CIDR som tillhandahålls när klustret skapas. Varje nod tilldelas ett /24 adressutrymme som är utskuret från samma CIDR. Extra noder som skapas när du skalar ut ett kluster tar automatiskt emot /24 adressutrymmen från samma CIDR. Azure CNI tilldelar IP-adresser till poddar från det här /24 utrymmet.

En separat routningsdomän skapas i Azure Networking-stacken för poddens privata CIDR-utrymme, vilket skapar ett Overlay-nätverk för direkt kommunikation mellan poddar. Du behöver inte etablera anpassade vägar i klustrets undernät eller använda en inkapslingsmetod för att tunneltrafik mellan poddar, vilket ger anslutningsprestanda mellan poddar i nivå med virtuella datorer i ett virtuellt nätverk. Arbetsbelastningar som körs i poddarna är inte ens medvetna om att nätverksadressmanipulering sker.

Ett diagram som visar två noder med tre poddar som körs i ett Overlay-nätverk. Poddtrafik till slutpunkter utanför klustret dirigeras via NAT.

Kommunikation med slutpunkter utanför klustret, till exempel lokala och peerkopplade virtuella nätverk, sker med nod-IP via NAT. Azure CNI översätter käll-IP-adressen (overlay IP för podden) för trafiken till den virtuella datorns primära IP-adress, vilket gör att Azure Networking-stacken kan dirigera trafiken till målet. Slutpunkter utanför klustret kan inte ansluta direkt till en podd. Du måste publicera poddens program som en Kubernetes Load Balancer-tjänst för att den ska kunna nås på det virtuella nätverket.

Du kan tillhandahålla utgående (utgående) anslutning till Internet för Overlay-poddar med hjälp av en Standard SKU Load Balancer eller Managed NAT Gateway. Du kan också styra utgående trafik genom att dirigera den till en brandvägg med hjälp av användardefinierade vägar i klustrets undernät.

Du kan konfigurera ingressanslutning till klustret med hjälp av en ingresskontrollant, till exempel Nginx- eller HTTP-programroutning. Du kan inte konfigurera inkommande anslutning med Hjälp av Azure App Gateway. Mer information finns i Begränsningar med Azure CNI-överlägg.

Skillnader mellan kubenet och Azure CNI Overlay

Följande tabell innehåller en detaljerad jämförelse mellan kubenet och Azure CNI Overlay:

Ytdiagram Azure CNI-överlägg kubenet
Klusterskala 5 000 noder och 250 poddar/noder 400 noder och 250 poddar/nod
Konfiguration av nätverk Enkelt – inga extra konfigurationer krävs för poddnätverk Komplext – kräver routningstabeller och UDR i klusterundernät för poddnätverk
Prestanda för poddanslutning Prestanda i nivå med virtuella datorer i ett virtuellt nätverk Extra hopp lägger till mindre svarstid
Kubernetes-nätverksprinciper Azure-nätverksprinciper, Calico, Cilium Kalikå
Operativsystemplattformar som stöds Linux och Windows Server 2022, 2019 Endast Linux

Planering av IP-adress

Klusternoder

När du konfigurerar AKS-klustret kontrollerar du att dina VNet-undernät har tillräckligt med utrymme för att växa för framtida skalning. Du kan tilldela varje nodpool till ett dedikerat undernät.

Ett /24 undernät får plats med upp till 251 noder eftersom de tre första IP-adresserna är reserverade för hanteringsuppgifter.

Poddar

Overlay-lösningen tilldelar ett /24 adressutrymme för poddar på varje nod från den privata CIDR som du anger när klustret skapas. Storleken /24 är fast och kan inte ökas eller minskas. Du kan köra upp till 250 poddar på en nod.

När du planerar IP-adressutrymme för poddar bör du tänka på följande faktorer:

  • Se till att den privata CIDR är tillräckligt stor för att tillhandahålla /24 adressutrymmen för nya noder för att stödja framtida klusterexpansion.
  • Samma podd-CIDR-utrymme kan användas på flera oberoende AKS-kluster i samma virtuella nätverk.
  • Podd-CIDR-utrymme får inte överlappa klustrets undernätsintervall.
  • Podd-CIDR-utrymme får inte överlappa direktanslutna nätverk (till exempel VNet-peering, ExpressRoute eller VPN). Om extern trafik har käll-IP-adresser i podCIDR-intervallet behöver den översättning till en icke-överlappande IP-adress via SNAT för att kommunicera med klustret.

Kubernetes Service-adressintervall

Storleken på tjänstadressen CIDR beror på antalet klustertjänster som du planerar att skapa. Den måste vara mindre än /12. Det här intervallet får inte överlappa poddens CIDR-intervall, klusterundernätsintervall och IP-intervall som används i peerkopplade virtuella nätverk och lokala nätverk.

IP-adress för Kubernetes DNS-tjänst

Den här IP-adressen ligger inom kubernetes-tjänstens adressintervall som används av klustertjänstidentifiering. Använd inte den första IP-adressen i adressintervallet eftersom den här adressen används för kubernetes.default.svc.cluster.local adressen.

Nätverkssäkerhetsgrupper

Podd-till-poddtrafik med Azure CNI-överlägg är inte inkapslat och regler för nätverkssäkerhetsgrupper för undernät tillämpas. Om undernätets NSG innehåller nekanderegler som skulle påverka poddens CIDR-trafik kontrollerar du att följande regler finns på plats för att säkerställa rätt klusterfunktioner (förutom alla KRAV på AKS-utgående trafik):

  • Trafik från nodens CIDR till nodens CIDR på alla portar och protokoll
  • Trafik från nodens CIDR till podd-CIDR på alla portar och protokoll (krävs för tjänsttrafikroutning)
  • Trafik från podd-CIDR till podd-CIDR på alla portar och protokoll (krävs för podd-till-podd- och poddtrafik till tjänst, inklusive DNS)

Trafik från en podd till ett mål utanför podd-CIDR-blocket använder SNAT för att ange käll-IP till IP-adressen för noden där podden körs.

Om du vill begränsa trafiken mellan arbetsbelastningar i klustret rekommenderar vi att du använder nätverksprinciper.

Maximalt antal poddar per nod

Du kan konfigurera det maximala antalet poddar per nod när klustret skapas eller när du lägger till en ny nodpool. Standard- och maxvärdet för Azure CNI Overlay är 250., och det minsta värdet är 10. Det maximala poddvärdet per nod som konfigurerades när en nodpool skapades gäller endast noderna i den nodpoolen.

Välja en nätverksmodell att använda

Azure CNI erbjuder två IP-adresseringsalternativ för poddar: Den traditionella konfigurationen som tilldelar virtuella nätverks-IP-adresser till poddar och Overlay-nätverk. Valet av vilket alternativ som ska användas för ditt AKS-kluster är en balans mellan flexibilitet och avancerade konfigurationsbehov. Följande överväganden hjälper dig att beskriva när varje nätverksmodell kan vara lämpligast.

Använd Overlay-nätverk när:

  • Du vill skala till ett stort antal poddar, men har begränsat IP-adressutrymme i ditt virtuella nätverk.
  • Merparten av poddkommunikationen finns i klustret.
  • Du behöver inte avancerade AKS-funktioner, till exempel virtuella noder.

Använd det traditionella VNet-alternativet när:

  • Du har tillgängligt IP-adressutrymme.
  • Merparten av poddkommunikationen är till resurser utanför klustret.
  • Resurser utanför klustret måste nå poddar direkt.
  • Du behöver avancerade AKS-funktioner, till exempel virtuella noder.

Begränsningar med Azure CNI-överlägg

Azure CNI Overlay har följande begränsningar:

  • Du kan inte använda Application Gateway som ingresskontrollant (AGIC).
  • Virtuella datortillgänglighetsuppsättningar (VMAS) stöds inte.
  • Du kan inte använda virtuella datorer i DCsv2-serien i nodpooler. Om du vill uppfylla kraven för konfidentiell databehandling bör du överväga att använda konfidentiella virtuella datorer i DCasv5- eller DCadsv5-serien i stället.
  • Om du använder ditt eget undernät för att distribuera klustret måste namnen på undernätet, det virtuella nätverket och resursgruppen som innehåller det virtuella nätverket vara högst 63 tecken. Dessa namn används som etiketter i AKS-arbetsnoder och omfattas av Kubernetes-etikettsyntaxregler.