Översikt över CNI-nätverk i Azure Kubernetes Service (AKS)

Kubernetes använder CNI-plugin-program (Container Networking Interface) för att hantera nätverk i Kubernetes-kluster. CNIs ansvarar för att tilldela IP-adresser till poddar, nätverksroutning mellan poddar, Kubernetes Service-routning med mera.

AKS innehåller flera CNI-plugin-program som du kan använda i dina kluster beroende på dina nätverkskrav.

Nätverksmodeller i AKS

Om du väljer ett CNI-plugin-program för ditt AKS-kluster beror det till stor del på vilken nätverksmodell som passar dina behov bäst. Varje modell har sina egna fördelar och nackdelar som du bör tänka på när du planerar ditt AKS-kluster.

AKS använder två huvudsakliga nätverksmodeller: överläggsnätverk och platt nätverk.

Båda nätverksmodellerna har flera CNI-plugin-alternativ som stöds. De största skillnaderna mellan modellerna är hur podd-IP-adresser tilldelas och hur trafiken lämnar klustret.

Överläggsnätverk

Överläggsnätverk är den vanligaste nätverksmodellen som används i Kubernetes. I överläggsnätverk får poddar en IP-adress från en privat, logiskt separat CIDR från Azure VNet-undernätet där AKS-noder distribueras. Detta möjliggör enklare och ofta bättre skalbarhet än den platta nätverksmodellen.

I överläggsnätverk kan poddar kommunicera direkt med varandra. Trafik som lämnar klustret är Källnätverksadress översatt (SNAT'd) till nodens IP-adress, och inkommande podd-IP-trafik dirigeras via någon tjänst, till exempel en lastbalanserare. Det innebär att podd-IP-adressen är "dold" bakom nodens IP-adress. Den här metoden minskar antalet virtuella nätverks-IP-adresser som krävs för dina kluster.

Azure Kubernetes Service tillhandahåller följande CNI-plugin-program för överläggsnätverk:

• Azure CNI Overlay, det rekommenderade CNI-plugin-programmet för de flesta scenarier.
• kubenet, den äldre överläggsmodellen CNI.

Platta nätverk

Till skillnad från ett överläggsnätverk tilldelar en platt nätverksmodell i AKS IP-adresser till poddar från ett undernät från samma virtuella Azure-nätverk som AKS-noderna. Det innebär att trafik som lämnar klustren inte är SNAT'd och att podd-IP-adressen är direkt exponerad för målet. Detta kan vara användbart för vissa scenarier, till exempel när du behöver exponera podd-IP-adresser för externa tjänster.

Azure Kubernetes Service tillhandahåller två CNI-plugin-program för platta nätverk. Den här artikeln går inte in på djupet för varje plugin-alternativ. Mer information finns i den länkade dokumentationen:

• Azure CNI Pod Subnet, det rekommenderade CNI-plugin-programmet för scenarier med platta nätverk.
• Azure CNI Node Subnet, en äldre platt nätverksmodell CNI rekommenderar vanligtvis bara att du använder om du behöver ett hanterat virtuellt nätverk för klustret.

Välja ett CNI

När du väljer ett CNI finns det flera faktorer att tänka på. Varje nätverksmodell har sina egna fördelar och nackdelar, och det bästa valet för klustret beror på dina specifika krav.

Välja en nätverksmodell

De två huvudsakliga nätverksmodellerna i AKS är överlägg och platta nätverk.

• Överläggsnätverk:

  • Spara VNet IP-adressutrymme med hjälp av logiskt separata CIDR-intervall för poddar.
  • Maximalt stöd för klusterskala.
  • Enkel IP-adresshantering.

• Platta nätverk:

  • Poddar får fullständig VNet-anslutning och kan nås direkt via sin privata IP-adress från anslutna nätverk.
  • Kräv stort, icke-fragmenterat VNet IP-adressutrymme.

Jämförelse av användningsfall

När du väljer en nätverksmodell bör du överväga användningsfallen för varje CNI-plugin-program och vilken typ av nätverksmodell som används:

CNI-plugin-program	Nätverksmodell	Markeringar för användningsfall
Azure CNI-överlägg	Överlägg	- Bäst för VNET IP-bevarande – Maximalt antal noder som stöds av API Server + 250 poddar per nod – Enklare konfiguration -Ingen direkt extern podd-IP-åtkomst
Azure CNI Pod-undernät (förhandsversion)	Förenklat	– Direkt åtkomst till extern podd – Lägen för effektiv IP-användning av virtuella nätverk eller stöd för stor klusterskala
Kubenet (äldre)	Överlägg	- Prioriterar IP-bevarande – Begränsad skala – Manuell väghantering
Azure CNI Node-undernät (äldre)	Förenklat	– Direkt åtkomst till extern podd – Enklare konfiguration – Begränsad skala – Ineffektiv användning av virtuella nätverks-IP-adresser

Jämför funktioner

Du kanske också vill jämföra funktionerna i varje CNI-plugin-program. Följande tabell innehåller en jämförelse på hög nivå av de funktioner som stöds av varje CNI-plugin-program:

Funktion	Azure CNI-överlägg	Azure CNI Pod-undernät	Azure CNI Node-undernät (äldre)	Kubenet
Distribuera kluster i befintligt eller nytt virtuellt nätverk	Stöds	Stöds	Stöds	Stöds – manuella UDF:ar
Podd-VM-anslutning med virtuell dator i samma eller peer-kopplade virtuella nätverk	Podd initierad	Båda sätten	Båda sätten	Podd initierad
Lokal åtkomst via VPN/Express Route	Podd initierad	Båda sätten	Båda sätten	Podd initierad
Åtkomst till tjänstslutpunkter	Stöds	Stöds	Stöds	Stöds
Exponera tjänster med lastbalanserare	Stöds	Stöds	Stöds	Stöds
Exponera tjänster med App Gateway	Stöds för närvarande inte	Stöds	Stöds	Stöds
Exponera tjänster med hjälp av ingresskontrollant	Stöds	Stöds	Stöds	Stöds
Windows-nodpooler	Stöds	Stöds	Stöds	Stöds inte
Standard azure DNS och privata zoner	Stöds	Stöds	Stöds	Stöds
Delning av VNet-undernät mellan flera kluster	Stöds	Stöds	Stöds	Stöds inte

Stödomfång mellan nätverksmodeller

Beroende på vilken CNI du använder kan klustrets virtuella nätverksresurser distribueras på något av följande sätt:

• Azure-plattformen kan automatiskt skapa och konfigurera de virtuella nätverksresurserna när du skapar ett AKS-kluster. som i Azure CNI Overlay, Azure CNI Node-undernätet och Kubenet.
• Du kan skapa och konfigurera de virtuella nätverksresurserna manuellt och ansluta till dessa resurser när du skapar AKS-klustret.

Även om funktioner som tjänstslutpunkter eller UDR stöds, definierar supportprinciperna för AKS vilka ändringar du kan göra. Till exempel:

• Om du manuellt skapar de virtuella nätverksresurserna för ett AKS-kluster stöds du när du konfigurerar dina egna UDR eller tjänstslutpunkter.
• Om Azure-plattformen automatiskt skapar de virtuella nätverksresurserna för ditt AKS-kluster kan du inte ändra dessa AKS-hanterade resurser manuellt för att konfigurera dina egna UDR eller tjänstslutpunkter.

Förutsättningar

Det finns flera krav och överväganden att tänka på när du planerar nätverkskonfigurationen för AKS:

• Det virtuella nätverket för AKS-klustret måste tillåta utgående Internetanslutning.
• AKS-kluster kan inte använda 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16eller 192.0.2.0/24 för Kubernetes-tjänstens adressintervall, poddadressintervall eller klusteradressintervall för virtuella nätverk.
• I BYO CNI-scenarier måste klusteridentiteten som används av AKS-klustret ha minst behörighet som nätverksdeltagare i undernätet i ditt virtuella nätverk. Om du vill definiera en anpassad roll i stället för att använda den inbyggda rollen Nätverksdeltagare krävs följande behörigheter:
  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read
  • Microsoft.Authorization/roleAssignments/write
• Det undernät som tilldelats AKS-nodpoolen kan inte vara ett delegerat undernät.
• AKS tillämpar inte nätverkssäkerhetsgrupper (NSG:er) på undernätet och ändrar inte någon av de NSG:er som är associerade med det undernätet. Om du anger ett eget undernät och lägger till NSG:er som är associerade med det undernätet måste du se till att säkerhetsreglerna i NSG:erna tillåter trafik inom nodens CIDR-intervall. Mer information finns i Nätverkssäkerhetsgrupper.

Nästa steg

• Azure CNI-överlägg
• Azure CNI Pod-undernät
• Äldre CNI-alternativ
• IP-adressplanering för dina kluster