Dela via

Konfigurera Azure CNI-nätverk för statisk allokering av CIDR-block och utökat undernätsstöd i Azure Kubernetes Service (AKS) – (förhandsversion)

  • Artikel

En begränsning för dynamisk IP-allokering i Azure CNI är skalbarheten för poddundernätsstorleken utöver ett /16-undernät. Även med ett stort undernät kan stora kluster fortfarande begränsas till 65 000 poddar på grund av en gräns för Azure-adressmappning. Den nya funktionen för statisk blockallokering i Azure CNI löser problemet genom att tilldela CIDR-block till noder i stället för enskilda IP-adresser.

Den erbjuder följande fördelar:

  • Bättre IP-skalbarhet: CIDR-block allokeras statiskt till klusternoderna och finns för nodens livslängd, i motsats till den traditionella dynamiska allokeringen av enskilda IP-adresser med traditionell CNI. Detta möjliggör routning baserat på CIDR-block och hjälper till att skala klustergränsen upp till 1 miljon poddar från de traditionella 65K-poddarna per kluster. Ditt virtuella Azure-nätverk måste vara tillräckligt stort för att hantera klustrets skala.
  • Flexibilitet: Nod- och poddundernät kan skalas separat. Ett enda poddundernät kan delas mellan flera nodpooler i ett kluster eller över flera AKS-kluster som distribueras i samma virtuella nätverk. Du kan också konfigurera ett separat poddundernät för en nodpool.
  • Höga prestanda: Eftersom poddar har tilldelats IP-adresser för virtuella nätverk har de direktanslutning till andra klusterpoddar och resurser i det virtuella nätverket.
  • Separata VNet-principer för poddar: Eftersom poddar har ett separat undernät kan du konfigurera separata VNet-principer för dem som skiljer sig från nodprinciper. Detta möjliggör många användbara scenarier som att endast tillåta internetanslutning för poddar och inte för noder, åtgärda käll-IP för podden i en nodpool med hjälp av en Azure NAT Gateway och använda NSG:er för att filtrera trafik mellan nodpooler.
  • Kubernetes-nätverksprinciper: Cilium, Azure NPM och Calico fungerar med den här nya lösningen.

Den här artikeln visar hur du använder Azure CNI-nätverk för statisk allokering av CIDR och förbättrat undernätsstöd i AKS.

Förutsättningar

Kommentar

När du använder statisk blockallokering av CIDR stöds inte att exponera ett program som en Private Link-tjänst med en Kubernetes Load Balancer-tjänst.

  • Granska förutsättningarna för att konfigurera grundläggande Azure CNI-nätverk i AKS, eftersom samma förutsättningar gäller för den här artikeln.

  • Granska distributionsparametrarna för att konfigurera grundläggande Azure CNI-nätverk i AKS, eftersom samma parametrar gäller.

  • AKS Engine- och DIY-kluster stöds inte.

  • Azure CLI-version 2.37.0 eller senare med tillägget aks-preview av version 2.0.0b2 eller senare

  • Om du har ett befintligt kluster måste du aktivera Container Insights för övervakning av IP-undernätsanvändning. Du kan aktivera Container Insights med hjälp av az aks enable-addons kommandot, som du ser i följande exempel:

  • Registrera funktionsflaggan på prenumerationsnivå för din prenumeration: "Microsoft.ContainerService/AzureVnetScalePreview"

    az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>

Begränsningar

Nedan följer några av begränsningarna med att använda Azure CNI Static Block-allokering:

  • Lägsta Kubernetes-version som krävs är 1,28
  • Maximal undernätsstorlek som stöds är x.x.x.x/12 ~ 1 miljon IP-adresser
  • Stöds inte för Windows-nodpooler (Windows-stöd kommer snart)
  • Stöds inte för Cilium Data Plane (stöd kommer snart)
  • Endast ett enskilt driftläge kan användas per undernät. Om ett undernät använder statiskt blockallokeringsläge kan det inte användas dynamiskt IP-allokeringsläge i ett annat kluster eller en annan nodpool med samma undernät och vice versa.
  • Stöds endast i nya kluster eller när du lägger till nodpooler med ett annat undernät till befintliga kluster. Det går inte att migrera eller uppdatera befintliga kluster eller nodpooler.
  • I alla CIDR-block som tilldelats en nod i nodpoolen väljs en IP-adress som nodens primära IP-adress. För nätverksadministratörer som --max-pods väljer värdet kan du därför försöka använda beräkningen nedan för att på bästa sätt uppfylla dina behov och ha optimal användning av IP-adresser i undernätet:
    max_pods = (N * 16) - 1' där N är något positivt heltal och N > 0

Region tillgänglighet

Den här funktionen är inte tillgänglig i följande regioner:

  • USA, södra
  • USA, östra 2
  • USA, västra
  • USA, västra 2

Planera IP-adress

Att planera din IP-adressering är mer flexibelt och detaljerat. Eftersom noderna och poddarna skalas separat kan deras adressutrymmen också planeras separat. Eftersom poddundernät kan konfigureras till kornigheten för en nodpool kan du alltid lägga till ett nytt undernät när du lägger till en nodpool. Systempoddarna i en kluster-/nodpool tar också emot IP-adresser från poddundernätet, så det här beteendet måste redovisas.

I det här scenariot allokeras CIDR-block med /28 (16 IP-adresser) till noder baserat på konfigurationen "--max-pod" för nodpoolen som definierar det maximala antalet poddar per nod. 1 IP-adress är reserverad på varje nod från alla tillgängliga IP-adresser på den noden för interna ändamål.

När du fastställer och planerar dina IP-adresser är det därför viktigt att definiera konfigurationen "--max-pods" och den kan beräknas bäst enligt nedan: max_pods_per_node = (16 * N) - 1 där N är ett positivt heltal större än 0

Idealvärden utan IP-avlagring skulle kräva att max poddar-värdet överensstämmer med ovanstående uttryck.

  • Exempel 1: max_pods = 30, CIDR-block allokerade per nod = 2, Totalt antal IP-adresser som är tillgängliga för poddar = (16 * 2) - 1 = 32 - 1 = 31, IP-wastage per nod = 31 - 30 = 1 [Låg varning - acceptabelt fall]
  • Exempel 2: max_pods = 31, CIDR-block allokerade per nod = 2, Totalt antal IP-adresser tillgängliga för poddar = (16 * 2) - 1 = 32 - 1 = 31, IP-varning per nod = 31 - 31 = 0 [Idealfall]
  • Exempel 3: max_pods = 32, CIDR-block allokerade per nod = 3, Totalt antal IP-adresser som är tillgängliga för poddar = (16 * 3) - 1 = 48 - 1 = 47, IP-varning per nod = 47 - 32 = 15 [Hög avlagring - inte rekommenderat fall]

Planeringen av IP-adresser för Kubernetes-tjänster förblir oförändrad.

Kommentar

Se till att ditt virtuella nätverk har ett tillräckligt stort och sammanhängande adressutrymme för att stödja klustrets skala.

Distributionsparametrar

Distributionsparametrarna för att konfigurera grundläggande Azure CNI-nätverk i AKS är alla giltiga, med två undantag:

  • Parametern vnet-undernäts-ID refererar nu till det undernät som är relaterat till klustrets noder.
  • Parameterpoddens undernäts-ID används för att ange det undernät vars IP-adresser ska allokeras statiskt eller dynamiskt till poddar i nodpoolen.
  • Parametern för podd-ip-allokeringsläge anger om dynamisk individuell eller statisk blockallokering ska användas.

Innan du börjar

  • Om du använder Azure CLI behöver aks-preview du tillägget. Se Installera Azure CLI-tilläggetaks-preview.
  • Om du använder ARM eller REST API måste AKS API-versionen vara 2024-01-02-preview eller senare.

Installera Azure CLI-tillägget aks-preview

  1. aks-preview Installera tillägget med kommandot az extension add .

    az extension add --name aks-preview

  2. Uppdatera till den senaste versionen av tillägget med kommandot az extension update . Tillägget bör ha en version av "2.0..0b2" eller senare

    az extension update --name aks-preview

Registrera funktionsflaggan AzureVnetScalePreview

  1. Registrera funktionsflaggan AzureVnetScalePreviewaz feature register med kommandot .

    az feature register --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"

    Det tar några minuter för statusen att visa Registrerad.

  2. Kontrollera registreringsstatusen az feature show med kommandot .

    az feature show --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"

  3. När statusen visar Registrerad uppdaterar du registreringen av resursprovidern Microsoft.ContainerService med hjälp av az provider register kommandot .

    az provider register --namespace Microsoft.ContainerService

Konfigurera nätverk med statisk allokering av CIDR-block och förbättrat undernätsstöd – Azure CLI

Att använda statisk allokering av CIDR-block i klustret liknar standardmetoden för att konfigurera ett Kluster-Azure CNI för dynamisk IP-allokering. I följande exempel går vi igenom hur du skapar ett nytt virtuellt nätverk med ett undernät för noder och ett undernät för poddar och skapar ett kluster som använder Azure CNI med statisk allokering av CIDR-block. Se till att ersätta variabler som $subscription med dina värden.

Skapa det virtuella nätverket med två undernät.

resourceGroup="myResourceGroup"
vnet="myVirtualNetwork"
location="myRegion"

# Create the resource group
az group create --name $resourceGroup --location $location

# Create our two subnet network 
az network vnet create --resource-group $resourceGroup --location $location --name $vnet --address-prefixes 10.0.0.0/8 -o none 
az network vnet subnet create --resource-group $resourceGroup --vnet-name $vnet --name nodesubnet --address-prefixes 10.240.0.0/16 -o none 
az network vnet subnet create --resource-group $resourceGroup --vnet-name $vnet --name podsubnet --address-prefixes 10.40.0.0/13 -o none

Skapa klustret, referera till nodundernätet med , --vnet-subnet-idpoddundernätet med , --pod-subnet-id--pod-ip-allocation-mode för att definiera ip-allokeringsläget och aktivera övervakningstillägget.

clusterName="myAKSCluster"
subscription="aaaaaaa-aaaaa-aaaaaa-aaaa"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --max-pods 250 \
    --node-count 2 \
    --network-plugin azure \
    --pod-ip-allocation-mode StaticBlock \
    --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/nodesubnet \
    --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/podsubnet \
    --enable-addons monitoring \
    --generate-ssh-keys

Lägga till nodpool

När du lägger till nodpool refererar du till nodundernätet med , --vnet-subnet-idpoddundernätet med och --pod-subnet-id allokeringsläget med hjälp av "-pod-ip-allocation-mode". I följande exempel skapas två nya undernät som sedan refereras i skapandet av en ny nodpool:

az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name node2subnet --address-prefixes 10.242.0.0/16 -o none 
az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name pod2subnet --address-prefixes 10.243.0.0/16 -o none 

az aks nodepool add --cluster-name $clusterName -g $resourceGroup  -n newnodepool \
    --max-pods 250 \
    --node-count 2 \
    --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/node2subnet \
    --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/pod2subnet \
    --pod-ip-allocation-mode StaticBlock \
    --no-wait

Statisk allokering av CIDR-block och utökat undernät stöder vanliga frågor och svar

  • Kan jag tilldela flera poddundernät till ett kluster?

    Flera undernät kan tilldelas till ett kluster, men endast ett undernät kan tilldelas till varje nodpool. Olika nodpooler i samma/olika kluster kan dela samma undernät.

  • Kan jag tilldela poddundernät från ett annat virtuellt nätverk helt och hållet?

    Nej, poddundernätet ska komma från samma virtuella nätverk som klustret.

  • Kan vissa nodpooler i ett kluster använda dynamisk IP-allokering medan andra använder den nya statiska blockallokeringen?

    Ja, olika nodpooler kan använda olika allokeringslägen. När ett undernät används i ett allokeringsläge kan det dock bara användas i samma allokeringsläge för alla nodpooler som det är associerat med.

Nästa steg

Läs mer om nätverk i AKS i följande artiklar: