Dela via

Poddundernät för Azure Container Networking Interface (CNI)

  • Artikel

Azure CNI Pod Subnet tilldelar IP-adresser till poddar från ett separat undernät från dina klusternoder. Den här funktionen är tillgänglig i två lägen: Dynamisk IP-allokering och statisk blockallokering (förhandsversion).

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 och tilläggsversionen aks-preview 2.0.0b2 eller senare.

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

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

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

Dynamiskt IP-allokeringsläge

Dynamisk IP-allokering hjälper till att minimera problem med podd-IP-adressöverbelastning genom att allokera podd-IP-adresser från ett undernät som är separat från undernätet som är värd för AKS-klustret.

Det dynamiska IP-allokeringsläget har följande fördelar:

  • Bättre IP-användning: IP-adresser allokeras dynamiskt till klusterpoddar från poddundernätet. Detta leder till bättre användning av IP-adresser i klustret jämfört med den traditionella CNI-lösningen, som utför statisk allokering av IP-adresser för varje nod.
  • Skalbart och flexibelt: 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 virtuella nätverks-IP-adresser har de direkt anslutning till andra klusterpoddar och resurser i det virtuella nätverket. Lösningen stöder mycket stora kluster utan försämrad prestanda.
  • 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, till exempel 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 nätverkssäkerhetsgrupper (NSG:er) för att filtrera trafik mellan nodpooler.
  • Kubernetes-nätverksprinciper: Både Azure-nätverksprinciperna och Calico fungerar med det här läget.

Planera IP-adress

Med dynamisk IP-allokering skalas noder och poddar separat, så att du kan planera deras adressutrymmen 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.

IP-adresser allokeras till noder i batchar med 16. IP-allokering av poddundernät bör planeras med minst 16 IP-adresser per nod i klustret, eftersom noderna begär 16 IP-adresser vid start och begär en annan batch på 16 när det finns 8 IP-adresser som inte allokerats <i tilldelningen.

IP-adressplaneringen för Kubernetes-tjänster och Docker Bridge förblir oförändrad.

Statiskt blockallokeringsläge (förhandsversion)

Med statisk blockallokering kan du minimera potentiella begränsningar för poddundernätsstorlek och Azure-adressmappning genom att tilldela CIDR-block till noder i stället för enskilda IP-adresser.

Det statiska blockallokeringsläget har 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 lösningen.

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

Med statisk blockallokering skalas noder och poddar separat, så att du kan planera deras adressutrymmen 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.

CIDR-block med /28 (16 IP-adresser) allokeras till noder baserat på din --max-pods konfiguration för nodpoolen, vilket 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 planerar dina IP-adresser är det viktigt att definiera konfigurationen --max-pods med hjälp av följande beräkning: 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.

Se följande exempelfall:

Exempel max_pods CIDR-block allokerade per nod Totalt antal TILLGÄNGLIGA IP-adresser för poddar IP-avlagring för nod
Låg avlagring (acceptabelt) 30 2 (16 * 2) - 1 = 32 - 1 = 31 31 - 30 = 1
Idealiskt skiftläge 31 2 (16 * 2) - 1 = 32 - 1 = 31 31 - 31 = 0
Hög mängd (rekommenderas inte) 32 3 (16 * 3) - 1 = 48 - 1 = 47 47 - 32 = 15

IP-adressplaneringen 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.