Ö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ö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 (förhandsversion) |
| 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/16eller192.0.2.0/24för Kubernetes-tjänstens adressintervall, poddadressintervall eller klusteradressintervall för virtuella nätverk. - I BYO VNet-scenarier måste klusteridentiteten som används av AKS-klustret ha minst behörighet som nätverksdeltagare i undernätet i det virtuella nätverket. 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/actionMicrosoft.Authorization/roleAssignments/writeMicrosoft.Network/virtualNetworks/subnets/read(behövs bara om du definierar dina egna undernät och CIDRs)
- 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 Kubernetes Service