Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Välj en konfiguration för poddnätverk baserat på om poddar behöver direkt IP-åtkomst från anslutna nätverk och kraven på IP-adressskala.
Behöver du direkt podd-IP-åtkomst?
Poddnätverk styr hur poddar får IP-adresser och definierar hur poddar kommunicerar med varandra, klusternoder och mål utanför klustret. Kubernetes implementerar poddnätverk via ett CNI-plugin-program (Container Network Interface), som hanterar podd-IP-adresser och nätverksanslutning.
När du konfigurerar poddnätverk måste du planera för IP-adresshantering (IPAM) och ruttning och transport (dataplanet).
Om dina arbetsbelastningar kräver att poddar kan nås via privat IP från nätverk som är anslutna till det Azure Kubernetes Service (AKS) klustrets virtuella nätverk använder du en platt nätverksmodell. Annars använder du Azure CNI-överlägg.
IP-adresshanteringsalternativ (IPAM)
När du konfigurerar IPAM kan du välja mellan en överläggsnätverksmodell med Azure CNI-överlägg och en platt nätverksmodell med Azure CNI Pod Subnet eller Azure CNI Node-undernät:
I följande tabell jämförs de IPAM-alternativ som är tillgängliga för AKS-poddnätverk, inklusive deras viktigaste funktioner och skalningsgränser.
| IPAM-alternativ | Diagram över nätverkskomponenter | Funktioner och funktionalitet |
|---|---|---|
| Overlay-nätverksmodell (med Azure CNI-Overlay) |
|
• Podd-IP-adresser kommer från ett överläggsintervall som inte är en del av det virtuella nätverkets utrymme. • Mycket skalbara nätverk med upp till 5 000 noder och 200 000 poddar per kluster. Gränserna för nod, poddar per nod och aggregerade poddar är oberoende. • Adressutrymme för poddöverlägg kan återanvändas i oberoende kluster. Podd-CIDR får inte överlappa med direktanslutna nätverk, inklusive peerkopplade virtuella nätverk, nätverk som är anslutna via ExpressRoute eller ett VPN och andra vägar som exponerar privat adressutrymme. • Stöd för dubbla staplar (IPv4/IPv6). • Poddar kan inte nås direkt utanför klustret. |
| Flat nätverksmodell (med Azure CNI Pod-undernät eller nodundernät) |
|
• Nod- och podd-IP-adresser kommer från VNet-utrymme. • Poddar kan nås via sina privata IP-adresser från anslutna nätverk. Azure CNI Pod Subnet bevarar poddens käll-IP-adress i anslutna virtuella nätverk, medan mål utanför klustrets virtuella nätverk ser nodens käll-IP-adress med Azure CNI Node Subnet. • Alternativen för Azure CNI Pod-undernät inkluderar dynamisk IP-allokering för effektivitet eller statisk blockallokering för skalning. |
Överväganden för alternativ för flat nätverksmodell
Tänk på följande när du bestämmer dig för mellan Azure CNI Pod Subnet med dynamisk IP-allokering, Azure CNI Pod-undernät med statisk blockallokering och Azure CNI Node-undernät:
| Alternativ för platt nätverksmodell | Överväganden |
|---|---|
| Azure CNI Pod-undernät med dynamisk IP-allokering | • Kräver separata noder och poddundernät som du kan ändra storlek på och skala separat. • Allokerar podd-IP-adresser till noder från poddundernätet i batchar om 16. • Omfattas av VNet-konfigurerade gränser för privata IP-adresser. |
| Azure CNI Pod-undernät med statisk blockallokering | • Kräver noggrann planering, eftersom du behöver allokera ett visst intervall ip-adresser för dina poddar och se till att det inte överlappar andra undernät. • Kan få upp till 1 000 000 IP-adresser. • Ip-adresser kanske inte används lika effektivt, vilket kan leda till avlagring. |
| Azure CNI Node-undernät | • Äldre alternativ som kan använda ett AKS-hanterat VNet eller ett kundhanterat VNet och undernät. • Noder och poddar delar nodundernätet, så du måste planera kapaciteten i förväg för noder, poddar, skalning och uppgraderingar. • Omfattas av VNet-konfigurerade gränser för privata IP-adresser. |
Alternativ för routning och transport (dataplan)
När du konfigurerar dataplanet kan du välja mellan Azure CNI som drivs av Cilium, Azure iptables-dataplanet och BYO CNI:
I följande tabell jämförs de tillgängliga dataplansalternativen för AKS-poddnätverk och deras viktigaste funktioner.
| Alternativ för dataplan | Funktioner och funktionalitet |
|---|---|
| Azure CNI drivs av Cilium | • Förbättrad skalning och prestanda för Linux-nodpooler. Windows nodpooler stöds inte. • Inbyggd tillämpning av Cilium-nätverksprinciper. • FQDN-filtrering kräver Advanced Container Networking Services och Kubernetes 1.29 eller senare. |
| Azure iptables | • Använd Calico för Windows nätverksprinciptillämpning. stöd för Azure Network Policy Manager (NPM) upphör den 30 september 2026 för Windows och 30 september 2028 för Linux. Nya prenumerationer kan inte längre aktivera Azure NPM. • För Linux-kluster använder du Azure CNI som drivs av Cilium i stället för Azure NPM. • Stöder Kubernetes NetworkPolicy. |
| BYO CNI | • Inget hanterat CNI-plugin-program installerat – du kan använda valfritt alternativ som stöder AKS. • Microsoft stöder inga CNI-relaterade problem. |
AKS-poddnätverksrekommendationer
Vår allmänna rekommendation är att använda Azure CNI Overlay. Om du behöver direkt podd-IP-åtkomst från anslutna nätverk och har effektivitets- eller skalningskrav kan du överväga att använda Azure CNI Pod-undernät med dynamisk IP-allokering eller Azure CNI Pod-undernät med statisk blockallokering. Azure CNI Node Subnet är ett äldre alternativ. Använd det i allmänhet endast om du behöver ett AKS-hanterat VNet för klustret.