Dela via

AKS Legacy Container Networking Interfaces (CNI)

  • Artikel

I Azure Kubernetes Service (AKS), medan Azure CNI Overlay och Azure CNI Pod Subnet rekommenderas för de flesta scenarier, är äldre nätverksmodeller som Azure CNI Node Subnet och kubenet fortfarande tillgängliga och stöds. Dessa äldre modeller erbjuder olika metoder för hantering och nätverk av podd-IP-adresser, var och en med sin egen uppsättning funktioner och överväganden. Den här artikeln innehåller en översikt över dessa äldre nätverksalternativ som beskriver deras förutsättningar, distributionsparametrar och viktiga egenskaper som hjälper dig att förstå deras roller och hur de kan användas effektivt i dina AKS-kluster.

Förutsättningar

Följande krav krävs för Azure CNI Node-undernät och kubenet:

  • 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.

  • Klusteridentiteten som används av AKS-klustret måste ha minst behörighet för 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/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 kontrollerar du att säkerhetsreglerna i NSG:erna tillåter trafik inom nodens CIDR-intervall. Mer information finns i Nätverkssäkerhetsgrupper.

Kommentar

Kubenet är inte tillgängligt för Windows Server-containrar. Om du vill använda Windows Server-nodpooler måste du använda Azure CNI.

Azure CNI Node-undernät

Med Azure Container Networking Interface (CNI) får varje podd en IP-adress från undernätet och kan nås direkt. System i samma virtuella nätverk som AKS-klustret ser poddens IP-adress som källadress för trafik från podden. System utanför det virtuella AKS-klustrets virtuella nätverk ser nod-IP som källadress för all trafik från podden. Dessa IP-adresser måste vara unika i nätverket och måste planeras i förväg. Varje nod har en konfigurationsparameter för det maximala antalet poddar som den stöder. Motsvarande antal IP-adresser per nod reserveras sedan i förväg för den noden. Den här metoden kräver mer planering och leder ofta till överbelastning av IP-adresser eller behovet av att återskapa kluster i ett större undernät när programkraven växer.

Med Azure CNI Node-undernätet tar varje podd emot en IP-adress i IP-undernätet och kan kommunicera direkt med andra poddar och tjänster. Dina kluster kan vara så stora som det IP-adressintervall som du anger. Du måste dock planera IP-adressintervallet i förväg och alla IP-adresser förbrukas av AKS-noderna baserat på det maximala antalet poddar som de kan stödja. Avancerade nätverksfunktioner och scenarier som virtuella noder eller nätverksprinciper (antingen Azure eller Calico) stöds med Azure CNI.

Distributionsparametrar

När du skapar ett AKS-kluster kan följande parametrar konfigureras för Azure CNI-nätverk:

Virtuellt nätverk: Det virtuella nätverk som du vill distribuera Kubernetes-klustret till. Du kan skapa ett nytt virtuellt nätverk eller använda ett befintligt nätverk. Om du vill använda ett befintligt virtuellt nätverk kontrollerar du att det finns på samma plats och en Azure-prenumeration som ditt Kubernetes-kluster. Information om begränsningar och kvoter för ett virtuellt Azure-nätverk finns i Begränsningar, kvoter och begränsningar för Azure-prenumerationer och tjänster.

Undernät: Undernätet i det virtuella nätverk där du vill distribuera klustret. Du kan lägga till nya undernät i det virtuella nätverket när klustret skapas. För hybridanslutningar bör adressintervallet inte överlappa andra virtuella nätverk i din miljö.

Plugin-program för Azure-nätverk: När plugin-programmet för Azure-nätverk används kan den interna LoadBalancer-tjänsten med "externalTrafficPolicy=Local" inte nås från virtuella datorer med en IP-adress i clusterCIDR som inte tillhör AKS-klustret.

Kubernetes-tjänstadressintervall: Den här parametern är den uppsättning virtuella IP-adresser som Kubernetes tilldelar interna tjänster i klustret. Det här intervallet kan inte uppdateras när du har skapat klustret. Du kan använda alla privata adressintervall som uppfyller följande krav:

  • Får inte ligga inom ip-adressintervallet för det virtuella nätverket i klustret.
  • Får inte överlappa andra virtuella nätverk med vilka klustrets virtuella nätverk peer-datorer.
  • Får inte överlappa med några lokala IP-adresser.
  • Får inte ligga inom intervallen 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16eller 192.0.2.0/24.

Även om det är möjligt att ange ett tjänstadressintervall inom samma virtuella nätverk som klustret rekommenderar vi det inte. Överlappande IP-intervall kan leda till oförutsägbart beteende. Mer information finns i vanliga frågor och svar. Mer information om Kubernetes-tjänster finns i Tjänster i Kubernetes-dokumentationen.

Ip-adress för Kubernetes DNS-tjänsten: IP-adressen för klustrets DNS-tjänst. Den här adressen måste ligga inom Kubernetes Service-adressintervallet. Använd inte den första IP-adressen i adressintervallet. Den första adressen i undernätsintervallet används för adressen kubernetes.default.svc.cluster.local .

Kubenet

AKS-kluster använder kubenet och skapar ett virtuellt Azure-nätverk och undernät åt dig som standard. Med kubenet får noder en IP-adress från det virtuella Azure-nätverkets undernät. Poddar får en IP-adress från ett annat logiskt adressutrymme än det virtuella Azure Virtual Network undernät för noderna. Nätverksadressöversättning (NAT) konfigureras sedan så att poddarna kan nå resurser i det virtuella Azure-nätverket. Källans IP-adress för trafiken är NAT'd till nodens primära IP-adress. Den här metoden minskar avsevärt antalet IP-adresser som du behöver reservera i ditt nätverksutrymme för poddar att använda.

Du kan konfigurera maximalt antal poddar som kan distribueras till en nod när klustret skapas eller när du skapar nya nodpooler. Om du inte anger maxPods när du skapar nya nodpooler får du ett standardvärde på 110 för kubenet.

Översikt över kubenet-nätverk med ditt eget undernät

I många miljöer har du definierat virtuella nätverk och undernät med allokerade IP-adressintervall, och du använder dessa resurser för att stödja flera tjänster och program. För att tillhandahålla nätverksanslutning kan AKS-kluster använda kubenet (grundläggande nätverk) eller Azure CNI (avancerat nätverk).

Med kubenet får endast noderna en IP-adress i det virtuella nätverksundernätet. Poddar kan inte kommunicera direkt med varandra. I stället hanterar användardefinierad routning (UDR) och IP-vidarebefordran anslutningen mellan poddar mellan noder. KONFIGURATION av UDR och IP-vidarebefordran skapas och underhålls som standard av AKS-tjänsten, men du kan ta med din egen routningstabell för anpassad väghantering om du vill. Du kan också distribuera poddar bakom en tjänst som tar emot en tilldelad IP-adress och belastningsutjämning av trafik för programmet. Följande diagram visar hur AKS-noderna tar emot en IP-adress i det virtuella nätverksundernätet, men inte poddarna:

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.

Azure stöder högst 400 vägar i en UDR, så du kan inte ha ett AKS-kluster som är större än 400 noder. Virtuella AKS-noder och Azure-nätverksprinciper stöds inte med kubenet. Calico-nätverksprinciper stöds.

Begränsningar och överväganden för kubenet

Kommentar

Vissa systempoddar, till exempel konnektivitet i klustret, använder ip-adressen för värdnoden i stället för en IP-adress från överläggsadressutrymmet. Systempoddarna använder bara nod-IP-adressen och inte en IP-adress från det virtuella nätverket.

TILLGÄNGLIGHET och överbelastning av IP-adresser

Ett vanligt problem med Azure CNI är att det tilldelade IP-adressintervallet är för litet för att sedan lägga till fler noder när du skalar eller uppgraderar ett kluster. Nätverksteamet kanske inte heller kan utfärda ett tillräckligt stort IP-adressintervall för att stödja dina förväntade programkrav. Som en kompromiss kan du skapa ett AKS-kluster som använder kubenet och ansluta till ett befintligt virtuellt nätverksundernät. Med den här metoden kan noderna ta emot definierade IP-adresser utan att behöva reservera ett stort antal IP-adresser i förväg för eventuella poddar som kan köras i klustret.

Med kubenet kan du använda ett mycket mindre IP-adressintervall och stödja stora kluster och programkrav. Med ip-adressintervallet /27 i undernätet kan du till exempel köra ett nodkluster med 20–25 noder med tillräckligt med utrymme för att skala eller uppgradera. Den här klusterstorleken har stöd för upp till 2 200–2 750 poddar (med ett standardvärde på högst 110 poddar per nod). Det maximala antalet poddar per nod som du kan konfigurera med kubenet i AKS är 250.

I följande grundläggande beräkningar jämförs skillnaden i nätverksmodeller:

  • kubenet: Ett enkelt /24 IP-adressintervall kan stödja upp till 251 noder i klustret. Varje virtuellt Azure-nätverksundernät reserverar de tre första IP-adresserna för hanteringsåtgärder. Det här antalet noder kan ha stöd för upp till 27 610 poddar, med ett standardantal på högst 110 poddar per nod.
  • Azure CNI: Samma grundläggande /24-undernätsintervall kan bara stödja högst 8 noder i klustret. Det här antalet noder kan bara stödja upp till 240 poddar, med ett standardantal på högst 30 poddar per nod.

Kommentar

Dessa maximum tar inte hänsyn till uppgraderings- eller skalningsåtgärder. I praktiken kan du inte köra det maximala antalet noder som undernätets IP-adressintervall stöder. Du måste lämna vissa IP-adresser tillgängliga för skalning eller uppgradering.

Peering för virtuella nätverk och ExpressRoute-anslutningar

Du kan använda Peering för virtuella Azure-nätverk eller ExpressRoute-anslutningar med Azure CNI och kubenet för att tillhandahålla lokal anslutning. Se till att du planerar dina IP-adresser noggrant för att förhindra överlappning och felaktig trafikroutning. Till exempel använder många lokala nätverk ett adressintervall på 10.0.0.0/8 som annonseras via ExpressRoute-anslutningen. Vi rekommenderar att du skapar dina AKS-kluster i virtuella Azure-nätverksundernät utanför det här adressintervallet, till exempel 172.16.0.0/16.

Mer information finns i Jämför nätverksmodeller och deras supportomfattningar.

Vanliga frågor och svar om Azure CNI Pod Subnet

  • Kan jag distribuera virtuella datorer i mitt klusterundernät?

    Ja för Azure CNI Node-undernät kan de virtuella datorerna distribueras i samma undernät som AKS-klustret.

  • Vilken käll-IP ser externa system för trafik som kommer från en Azure CNI-aktiverad podd?

    System i samma virtuella nätverk som AKS-klustret ser poddens IP-adress som källadress för trafik från podden. System utanför det virtuella AKS-klustrets virtuella nätverk ser nod-IP som källadress för all trafik från podden. Men för dynamisk IP-allokering i Azure CNI, oavsett om anslutningen finns i samma virtuella nätverk eller mellan virtuella nätverk, är podd-IP alltid källadressen för all trafik från podden. Det beror på att Azure CNI för dynamisk IP-allokering implementerar Microsoft Azure Container Networking-infrastrukturen , vilket ger en upplevelse från slutpunkt till slutpunkt. Därför eliminerar det användningen av ip-masq-agent, som fortfarande används av traditionell Azure CNI.

  • Kan jag konfigurera nätverksprinciper per podd?

    Ja, Kubernetes-nätverksprincip är tillgänglig i AKS. Information om hur du kommer igång finns i Skydda trafik mellan poddar med hjälp av nätverksprinciper i AKS.

  • Kan det maximala antalet poddar distribueras till en nod?

    Som standard använder AKS-kluster kubenet och skapar ett virtuellt nätverk och undernät. Med kubenet får noder en IP-adress från ett virtuellt nätverksundernät. Nätverksadressöversättning (NAT) konfigureras sedan på noderna och poddar får en IP-adress "dold" bakom nodens IP-adress. Den här metoden minskar antalet IP-adresser som du behöver reservera i ditt nätverksutrymme för poddar att använda.

    Med Azure Container Networking Interface (CNI) får varje podd en IP-adress från undernätet och kan nås direkt. System i samma virtuella nätverk som AKS-klustret ser poddens IP-adress som källadress för trafik från podden. System utanför det virtuella AKS-klustrets virtuella nätverk ser nod-IP som källadress för all trafik från podden. Dessa IP-adresser måste vara unika i nätverket och måste planeras i förväg. Varje nod har en konfigurationsparameter för det maximala antalet poddar som den stöder. Motsvarande antal IP-adresser per nod reserveras sedan i förväg för den noden. Den här metoden kräver mer planering och leder ofta till överbelastning av IP-adresser eller behovet av att återskapa kluster i ett större undernät när programkraven växer.

  • Kan jag distribuera virtuella datorer i mitt klusterundernät?

    Ja. Men för Azure CNI för dynamisk IP-allokering kan de virtuella datorerna inte distribueras i poddens undernät.

  • Vilken käll-IP ser externa system för trafik som kommer från en Azure CNI-aktiverad podd?

    System i samma virtuella nätverk som AKS-klustret ser poddens IP-adress som källadress för trafik från podden. System utanför det virtuella AKS-klustrets virtuella nätverk ser nod-IP som källadress för all trafik från podden.

    Men för Azure CNI för dynamisk IP-allokering, oavsett om anslutningen finns i samma virtuella nätverk eller mellan virtuella nätverk, är podd-IP alltid källadressen för all trafik från podden. Det beror på att Azure CNI för dynamisk IP-allokering implementerar Microsoft Azure Container Networking-infrastrukturen , vilket ger en upplevelse från slutpunkt till slutpunkt. Därför eliminerar det användningen av ip-masq-agent, som fortfarande används av traditionell Azure CNI.

  • Kan jag använda ett annat undernät i mitt virtuella klusternätverk för Kubernetes-tjänstens adressintervall?

    Det rekommenderas inte, men den här konfigurationen är möjlig. Tjänstadressintervallet är en uppsättning virtuella IP-adresser som Kubernetes tilldelar interna tjänster i klustret. Azure Networking har ingen insyn i tjänstens IP-intervall för Kubernetes-klustret. Bristen på insyn i klustrets tjänstadressintervall kan leda till problem. Du kan senare skapa ett nytt undernät i klustrets virtuella nätverk som överlappar tjänstadressintervallet. Om en sådan överlappning inträffar kan Kubernetes tilldela en tjänst en IP-adress som redan används av en annan resurs i undernätet, vilket orsakar oförutsägbart beteende eller fel. Genom att se till att du använder ett adressintervall utanför klustrets virtuella nätverk kan du undvika den här överlappningsrisken. Ja, när du distribuerar ett kluster med Azure CLI eller en Resource Manager-mall. Se Maximalt antal poddar per nod.

  • Kan jag använda ett annat undernät i mitt virtuella klusternätverk för Kubernetes-tjänstens adressintervall?

    Det rekommenderas inte, men den här konfigurationen är möjlig. Tjänstadressintervallet är en uppsättning virtuella IP-adresser som Kubernetes tilldelar interna tjänster i klustret. Azure Networking har ingen insyn i tjänstens IP-intervall för Kubernetes-klustret. Bristen på insyn i klustrets tjänstadressintervall kan leda till problem. Du kan senare skapa ett nytt undernät i klustrets virtuella nätverk som överlappar tjänstadressintervallet. Om en sådan överlappning inträffar kan Kubernetes tilldela en tjänst en IP-adress som redan används av en annan resurs i undernätet, vilket orsakar oförutsägbart beteende eller fel. Genom att se till att du använder ett adressintervall utanför klustrets virtuella nätverk kan du undvika den här överlappningsrisken.