Share via

Konfigurera Azure CNI-överläggsnätverk i Azure Kubernetes Service (AKS)

  • Artikel

Det traditionella Azure Container Networking Interface (CNI) tilldelar varje podd en VNet-IP-adress. Den tilldelar den här IP-adressen från en fördefinierad uppsättning IP-adresser på varje nod eller ett separat undernät som är reserverat för poddar. Den här metoden kräver IP-adressplanering och kan leda till överbelastning, vilket medför problem med att skala dina kluster när programkraven ökar.

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

Precis som Azure CNI Overlay tilldelar Kubenet IP-adresser till poddar från ett adressutrymme som skiljer sig logiskt från det virtuella nätverket, men det har skalning och andra begränsningar. Tabellen nedan innehåller en detaljerad jämförelse mellan Kubenet och Azure CNI Overlay. Om du inte vill tilldela virtuella nätverks-IP-adresser till poddar på grund av IP-brist rekommenderar vi att du använder 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 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 /24undernät får plats med upp till 251 noder eftersom de tre första IP-adresserna är reserverade för hanteringsuppgifter.
  • Poddar: Överläggslö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 poddadressutrymmet kontrollerar du 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.
    • När du planerar IP-adressutrymme för poddar bör du tänka på följande faktorer:
      • 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.
  • Adressintervall för Kubernetes-tjänsten: Storleken på tjänstadressens 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änsten: Den här IP-adressen ligger inom kubernetes-tjänstens adressintervall som används av identifiering av klustertjänster. 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. Standardvärdet för Azure CNI Overlay är 250. Det maximala värdet som du kan ange i 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) för ett Överläggskluster.
  • Virtuella datortillgänglighetsuppsättningar (VMAS) stöds inte för överlägg.
  • 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, VNET och resursgruppen som innehåller det virtuella nätverket vara högst 63 tecken. Detta kommer från det faktum att dessa namn kommer att användas som etiketter i AKS-arbetsnoder och därför omfattas av Kubernetes-etikettsyntaxregler.

Konfigurera Overlay-kluster

Kommentar

Du måste ha CLI version 2.48.0 eller senare för att kunna använda --network-plugin-mode argumentet. För Windows måste du ha det senaste Azure CLI-tillägget aks-preview installerat och kan följa anvisningarna nedan.

Skapa ett kluster med Azure CNI Overlay med kommandot az aks create . Använd argumentet --network-plugin-mode för att ange ett överläggskluster. Om podd-CIDR inte har angetts tilldelar AKS ett standardutrymme: viz. 10.244.0.0/16.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create -n $clusterName -g $resourceGroup \
  --location $location \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16

Lägga till en ny nodpool i ett dedikerat undernät

När du har skapat ett kluster med Azure CNI Overlay kan du skapa en annan nodpool och tilldela noderna till ett nytt undernät för samma virtuella nätverk. Den här metoden kan vara användbar om du vill styra värdens inkommande eller utgående IP-adresser från/mot mål i samma virtuella nätverk eller peer-kopplade virtuella nätverk.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"
nodepoolName="newpool1"
subscriptionId=$(az account show --query id -o tsv)
vnetName="yourVnetName"
subnetName="yourNewSubnetName"
subnetResourceId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName"
az aks nodepool add --resource-group $resourceGroup --cluster-name $clusterName \
  --name $nodepoolName --node-count 1 \
  --mode system --vnet-subnet-id $subnetResourceId

Uppgradera ett befintligt kluster till CNI-överlägg

Kommentar

Du kan uppdatera ett befintligt Azure CNI-kluster till Overlay om klustret uppfyller följande villkor:

  • Klustret finns på Kubernetes version 1.22+.
  • Använder inte funktionen för dynamisk podd-IP-allokering.
  • Nätverksprinciper är inte aktiverade. Nätverksprincipmotorn kan avinstalleras före uppgraderingen. Mer information finns i Avinstallera Azure Network Policy Manager eller Calico
  • Använder inte några Windows-nodpooler med Docker som containerkörning.

Kommentar

Eftersom routningsdomänen ännu inte stöds för ARM stöds inte CNI Overlay ännu på ARM-baserade (ARM64)-processornoder.

Kommentar

Att uppgradera ett befintligt kluster till CNI Overlay är en icke-reversibel process.

Varning

Före Windows OS Build 20348.1668 fanns det en begränsning kring Windows Overlay-poddar som felaktigt SNATing-paket från värdnätverkspoddar, vilket hade en mer skadlig effekt för kluster som uppgraderade till Overlay. Undvik det här problemet genom att använda Windows OS Build som är större än eller lika med 20348.1668.

Varning

Om du använder en anpassad azure-ip-masq-agent-konfiguration för att inkludera ytterligare IP-intervall som inte ska SNAT-paket från poddar kan uppgradering till Azure CNI Overlay bryta anslutningen till dessa intervall. Podd-IP-adresser från överläggsutrymmet kan inte nås av något utanför klusternoderna. För tillräckligt gamla kluster kan det dessutom finnas en ConfigMap kvar från en tidigare version av azure-ip-masq-agent. Om den här ConfigMap med namnet azure-ip-masq-agent-configfinns och inte avsiktligt är på plats bör den tas bort innan du kör uppdateringskommandot. Om du inte använder en anpassad ip-masq-agent-konfiguration bör endast azure-ip-masq-agent-config-reconciled ConfigMap finnas med avseende på Azure ip-masq-agent Config Kartor och detta uppdateras automatiskt under uppgraderingsprocessen.

Uppgraderingsprocessen utlöser att varje nodpool avbildas på nytt samtidigt. Det går inte att uppgradera varje nodpool separat till Overlay. Eventuella avbrott i klusternätverk liknar en uppgradering av nodavbildningen eller uppgradering av Kubernetes-versionen där varje nod i en nodpool avbildas på nytt.

Uppgradering av Azure CNI-kluster

Uppdatera ett befintligt Azure CNI-kluster för att använda Overlay med kommandot az aks update .

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin-mode overlay \
--pod-cidr 192.168.0.0/16

Parametern --pod-cidr krävs vid uppgradering från äldre CNI eftersom poddarna måste hämta IP-adresser från ett nytt överläggsutrymme, vilket inte överlappar det befintliga nodundernätet. Podd-CIDR kan inte heller överlappa med någon VNet-adress för nodpoolerna. Om din VNet-adress till exempel är 10.0.0.0/8 och noderna finns i undernätet 10.240.0.0/16, --pod-cidr kan det inte överlappa med 10.0.0.0/8 eller den befintliga tjänsten CIDR i klustret.

Kubenet-klusteruppgradering

Uppdatera ett befintligt Kubenet-kluster för att använda Azure CNI Overlay med hjälp av az aks update kommandot .

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin azure \
--network-plugin-mode overlay

Eftersom klustret redan använder en privat CIDR för poddar som inte överlappar det virtuella nätverkets IP-utrymme behöver du inte ange parametern --pod-cidr och Pod CIDR förblir densamma.

Kommentar

När du uppgraderar från Kubenet till CNI Overlay krävs inte längre routningstabellen för poddroutning. Om klustret använder en kund tillhandahållen routningstabell tas de vägar som användes för att dirigera poddtrafik till rätt nod automatiskt bort under migreringsåtgärden. Om klustret använder en hanterad routningstabell (routningstabellen skapades av AKS och finns i nodresursgruppen) tas routningstabellen bort som en del av migreringen.

Nätverk med dubbla staplar

Du kan distribuera dina AKS-kluster i ett läge med dubbla staplar när du använder Overlay-nätverk och ett virtuellt Azure-nätverk med dubbla staplar. I den här konfigurationen får noderna både en IPv4- och IPv6-adress från det virtuella Azure-nätverkets undernät. Poddar får både en IPv4- och IPv6-adress från ett logiskt annat adressutrymme än det virtuella Azure-nätverksundernätet för noderna. NAT (Network Address Translation) konfigureras sedan så att poddarna kan komma åt resurser i Azure Virtual Network. Källans IP-adress för trafiken är NAT'd till nodens primära IP-adress för samma familj (IPv4 till IPv4 och IPv6 till IPv6).

Förutsättningar

  • Du måste ha Azure CLI 2.48.0 eller senare installerat.
  • Kubernetes version 1.26.3 eller senare.

Begränsningar

Följande funktioner stöds inte med nätverk med dubbla staplar:

  • Windows Nodepools
  • Azure-nätverksprinciper
  • Calico-nätverksprinciper
  • NAT Gateway
  • Tillägg för virtuella noder

Distribuera ett AKS-kluster med dubbla staplar

Följande attribut tillhandahålls för att stödja kluster med dubbla staplar:

  • --ip-families: Tar en kommaavgränsad lista över IP-familjer som ska aktiveras i klustret.
    • Endast ipv4 eller ipv4,ipv6 stöds.
  • --pod-cidrs: Tar en kommaavgränsad lista över IP-intervall för CIDR-notering att tilldela podd-IP-adresser från.
    • Antalet och ordningen på intervallen i den här listan måste matcha värdet som anges till --ip-families.
    • Om inga värden anges används standardvärdet 10.244.0.0/16,fd12:3456:789a::/64 .
  • --service-cidrs: Tar en kommaavgränsad lista över IP-intervall för CIDR-notering att tilldela tjänst-IP-adresser från.
    • Antalet och ordningen på intervallen i den här listan måste matcha värdet som anges till --ip-families.
    • Om inga värden anges används standardvärdet 10.0.0.0/16,fd12:3456:789a:1::/108 .
    • Det IPv6-undernät som tilldelats får --service-cidrs inte vara större än /108.

Skapa ett AKS-kluster med dubbla staplar

  1. Skapa en Azure-resursgrupp för klustret med kommandot [az group create][az-group-create].

    az group create --location <region> --name <resourceGroupName>

  2. Skapa ett AKS-kluster med dubbla staplar med az aks create kommandot med parametern inställd på --ip-familiesipv4,ipv6.

    az aks create --location <region> --resource-group <resourceGroupName> --name <clusterName> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --ip-families ipv4,ipv6

Skapa en exempelarbetsbelastning

När klustret har skapats kan du distribuera dina arbetsbelastningar. Den här artikeln beskriver ett exempel på en arbetsbelastningsdistribution av en NGINX-webbserver.

Distribuera en NGINX-webbserver

Tillägget för programroutning är det rekommenderade sättet för ingress i ett AKS-kluster. Mer information om tillägget för programroutning och ett exempel på hur du distribuerar ett program med tillägget finns i Hanterad NGINX-ingress med tillägget för programroutning.

Exponera arbetsbelastningen via en LoadBalancer typtjänst

Viktigt!

Det finns för närvarande två begränsningar som gäller IPv6-tjänster i AKS.

  • Azure Load Balancer skickar hälsoavsökningar till IPv6-mål från en länklokal adress. I Azure Linux-nodpooler kan den här trafiken inte dirigeras till en podd, så trafik som flödar till IPv6-tjänster som distribueras utan externalTrafficPolicy: Cluster fel. IPv6-tjänster måste distribueras med externalTrafficPolicy: Local, vilket gör kube-proxy att den svarar på avsökningen på noden.
  • Före Kubernetes version 1.27 kommer endast den första IP-adressen för en tjänst att etableras till lastbalanseraren, så en tjänst med dubbla staplar tar bara emot en offentlig IP-adress för sin första ip-familj. Om du vill tillhandahålla en tjänst med dubbla staplar för en enda distribution skapar du två tjänster som riktar sig till samma väljare, en för IPv4 och en för IPv6. Detta är inte längre en begränsning i kubernetes 1.27 eller senare.

  1. Exponera NGINX-distributionen med kommandot kubectl expose deployment nginx .

    kubectl expose deployment nginx --name=nginx-ipv4 --port=80 --type=LoadBalancer'
kubectl expose deployment nginx --name=nginx-ipv6 --port=80 --type=LoadBalancer --overrides='{"spec":{"ipFamilies": ["IPv6"]}}'

    Du får utdata som visar att tjänsterna har exponerats.

    service/nginx-ipv4 exposed
service/nginx-ipv6 exposed

  2. När distributionen har exponerats och LoadBalancer tjänsterna har etablerats fullständigt hämtar du IP-adresserna för tjänsterna med kommandot kubectl get services .

    kubectl get services

    NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s

  3. Verifiera funktioner via en kommandoradswebbbegäran från en IPv6-kompatibel värd. Azure Cloud Shell är inte IPv6-kompatibelt.

    SERVICE_IP=$(kubectl get services nginx-ipv6 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
curl -s "http://[${SERVICE_IP}]" | head -n5

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>

Nästa steg

Mer information om hur du använder AKS med ditt eget CNI-plugin-program (Container Network Interface) finns i Ta med ditt eget CNI-plugin-program (Container Network Interface).