Hantering av Kubernetes-noder och nodpooler

Kubernetes-arkitekturen baseras på två lager: kontrollplanet och en eller flera noder i nodpooler. Den här artikeln beskriver och jämför hur Amazon Elastic Kubernetes Service (Amazon EKS) och Azure Kubernetes Service (AKS) hanterar agent- eller arbetsnoder.

I både Amazon EKS och AKS tillhandahåller och hanterar molnplattformen kontrollplansskiktet, och kunden hanterar nodskiktet. Följande diagram visar relationen mellan kontrollplanet och noderna i AKS Kubernetes-arkitekturen.

Amazon EKS-hanterade nodgrupper

Amazon EKS-hanterade nodgrupper automatiserar etablerings- och livscykelhanteringen för Amazon Elastic Compute Cloud-arbetsnoder (EC2) för Amazon EKS-kluster. AWS-användare (Amazon Web Services) kan använda kommandoradsverktyget eksctl för att skapa, uppdatera eller avsluta noder för sina EKS-kluster. Noduppdateringar och avslutningar avspärrar automatiskt och tömmer noder för att säkerställa att program förblir tillgängliga.

Varje hanterad nod etableras som en del av en Amazon EC2-grupp för automatisk skalning som Amazon EKS använder och kontrollerar. Autoskalning av Kubernetes-kluster justerar automatiskt antalet arbetsnoder i ett kluster när poddar misslyckas eller schemaläggs om till andra noder. Varje nodgrupp kan konfigureras för att köras över flera tillgänglighetszoner i en region.

Mer information om Amazon EKS-hanterade noder finns i Skapa en hanterad nodgrupp och Uppdatera en hanterad nodgrupp.

Du kan också köra Kubernetes-poddar på AWS Fargate. Fargate tillhandahåller beräkningskapacitet på begäran och rätt storlek för containrar. Mer information om hur du använder Fargate med Amazon EKS finns i AWS Fargate.

AKS-noder och nodpooler

När du skapar ett AKS-kluster skapas och konfigureras automatiskt ett kontrollplan som tillhandahåller kubernetes-kärntjänster och dirigering av programarbetsbelastningar. Azure-plattformen tillhandahåller AKS-kontrollplanet utan kostnad som en hanterad Azure-resurs. Kontrollplanet och dess resurser finns bara i den region där du skapade klustret.

Noderna, som även kallas agentnoder eller arbetsnoder, är värdar för arbetsbelastningar och program. I AKS hanterar och betalar kunderna fullständigt för agentnoderna som är kopplade till AKS-klustret.

För att köra program och stödtjänster behöver ett AKS-kluster minst en nod: En virtuell Azure-dator (VM) för att köra Kubernetes-nodkomponenterna och containerkörningen. Varje AKS-kluster måste innehålla minst en systemnodpool med minst en nod.

AKS grupperar noder med samma konfiguration i nodpooler med virtuella datorer som kör AKS-arbetsbelastningar. Systemnodpooler har det primära syftet att vara värd för kritiska systempoddar, till exempel CoreDNS. Användarnodpooler har det primära syftet att vara värd för arbetsbelastningspoddar. Om du bara vill ha en nodpool i ditt AKS-kluster, till exempel i en utvecklingsmiljö, kan du schemalägga programpoddar i systemnodpoolen.

Du kan också skapa flera användarnodpooler för att separera olika arbetsbelastningar på olika noder för att undvika det bullriga granneproblemet eller för att stödja program med olika beräknings- eller lagringskrav.

Varje agentnod i en system- eller användarnodpool är en virtuell dator som etableras som en del av Azure Virtual Machine Scale Sets och hanteras av AKS-klustret. Mer information finns i Noder och nodpooler.

Du kan definiera det inledande talet och storleken för arbetsnoder när du skapar ett AKS-kluster eller när du lägger till nya noder och nodpooler i ett befintligt AKS-kluster. Om du inte anger en VM-storlek är standardstorleken Standard_D2s_v3 för Windows-nodpooler och Standard_DS2_v2 för Linux-nodpooler.

Skapa nodpool

Du kan lägga till en nodpool i ett nytt eller befintligt AKS-kluster med hjälp av Azure-portalen, Azure CLI, AKS REST API eller IaC-verktyg (infrastruktur som kod), till exempel Bicep, Azure Resource Manager-mallar eller Terraform. Mer information om hur du lägger till nodpooler i ett befintligt AKS-kluster finns i Skapa och hantera flera nodpooler för ett kluster i Azure Kubernetes Service (AKS).

När du skapar en ny nodpool skapas den associerade VM-skalningsuppsättningen i nodresursgruppen, en Azure-resursgrupp som innehåller alla infrastrukturresurser för AKS-klustret. Dessa resurser omfattar Kubernetes-noder, virtuella nätverksresurser, hanterade identiteter och lagring.

Som standard har nodresursgruppen ett namn som MC_<resourcegroupname>_<clustername>_<location>. AKS tar automatiskt bort nodresursgruppen när du tar bort ett kluster, så du bör endast använda den här resursgruppen för resurser som delar klustrets livscykel.

Lägga till en nodpool

I följande kodexempel används kommandot Azure CLI az aks nodepool add för att lägga till en nodpool med namnet mynodepool med tre noder i ett befintligt AKS-kluster som heter myAKSCluster i myResourceGroup resursgruppen.

az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --node-vm-size Standard_D8ds_v4 \
      --name mynodepool \
      --node-count 3

Nodpooler för oanvänd kapacitet

En nodpool för oanvänd kapacitet är en nodpool som backas upp av en skalningsuppsättning för virtuella datorer med oanvänd kapacitet. Användning av virtuella datorer med oanvänd kapacitet för noder med ditt AKS-kluster drar nytta av outnyttad Azure-kapacitet till betydande kostnadsbesparingar. Mängden tillgänglig outnyttad kapacitet varierar beroende på många faktorer, inklusive nodstorlek, region och tid på dagen.

När du distribuerar en nodpool för oanvänd kapacitet allokerar Azure de oanvända noderna om det finns tillgänglig kapacitet. Men det finns inget serviceavtal (SLA) för dekornoderna. En skalningsuppsättning för oanvänd kapacitet som säkerhetskopierar nodpoolen för oanvänd kapacitet distribueras i en enda feldomän och erbjuder inga garantier för hög tillgänglighet. När Azure behöver tillbaka kapaciteten avlägsnar Azure-infrastrukturen skalningsnoder för oanvänd kapacitet, och du får högst 30 sekunders varsel innan du avlägsnar den. Tänk på att en skalningsuppsättningsnodpool inte kan vara klustrets standardnodpool. En nodpool för oanvänd kapacitet kan endast användas för en sekundär pool.

Oanvända noder är för arbetsbelastningar som kan hantera avbrott, tidiga avslutningar eller avhysningar. Till exempel är batchbearbetningsjobb, utvecklings- och testmiljöer och stora beräkningsarbetsbelastningar bra kandidater för schemaläggning på en nodpool med oanvänd kapacitet. Mer information finns i punktinstansens begränsningar.

Följande az aks nodepool add kommando lägger till en nodpool för oanvänd kapacitet till ett befintligt kluster med automatisk skalning aktiverat.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name myspotnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --priority Spot \
      --eviction-policy Delete \
      --spot-max-price -1 \
      --enable-cluster-autoscaler \
      --min-count 1 \
      --max-count 3 \
      --no-wait

Mer information om nodpooler för oanvänd kapacitet finns i Lägga till en skalningsuppsättningsnodpool i ett AKS-kluster (Azure Kubernetes Service).

Tillfälliga operativsystemdiskar

Som standard replikerar Azure automatiskt den virtuella datorns operativsystemdisk (OS) till Azure Storage för att undvika dataförlust om den virtuella datorn behöver flyttas till en annan värd. Men eftersom containrar inte är utformade för att bevara det lokala tillståndet, ger operativsystemets disk i lagring ett begränsat värde för AKS. Det finns vissa nackdelar, till exempel långsammare nodetablering och högre svarstid för läsning/skrivning.

Tillfälliga OS-diskar lagras däremot endast på värddatorn, till exempel en tillfällig disk, och ger lägre svarstid för läsning/skrivning och snabbare nodskalning och klusteruppgraderingar. Precis som en tillfällig disk ingår en tillfällig OS-disk i priset för virtuella datorer, så du debiteras inga extra lagringskostnader.

Om du vill använda tillfälliga operativsystem måste OS-disken få plats i den virtuella datorns cacheminne. Dokumentation om virtuella Azure-datorer visar storleken på den virtuella datorns cache i parenteser bredvid I/O-dataflöde som cachestorlek i gibibyte (GiB).

AkS-standardvärdet Standard_DS2_v2 VM-storlek med standardstorleken 100 GB OS stöder tillfälliga operativsystem, men har bara 86 GB cachestorlek. Den här konfigurationen är som standard hanterad disk om du inte uttryckligen anger något annat. Om du uttryckligen begär tillfälliga operativsystem för den här storleken får du ett verifieringsfel.

Om du begär samma Standard_DS2_v2 virtuella dator med en 60 GB OS-disk får du ett tillfälliga operativsystem som standard. Den begärda os-storleken på 60 GB är mindre än den maximala cachestorleken på 86 GB.

Standard_D8s_v3 med en 100 GB OS-disk stöder tillfälliga operativsystem och har 200 GB cacheutrymme. Om en användare inte anger operativsystemdisktypen får en nodpool ett tillfälliga operativsystem som standard.

Följande az aks nodepool add kommando visar hur du lägger till en ny nodpool i ett befintligt kluster med en tillfällig OS-disk. Parametern --node-osdisk-type anger os-disktypen till Ephemeral, och parametern --node-osdisk-size definierar os-diskstorleken.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynewnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --node-osdisk-type Ephemeral \
      --node-osdisk-size 48

Mer information om tillfälliga OS-diskar finns i tillfälliga operativsystem.

Virtuella noder

Du kan använda virtuella noder för att snabbt skala ut programarbetsbelastningar i ett AKS-kluster. Virtuella noder ger dig snabb poddetablering och du betalar bara per sekund för körningstid. Du behöver inte vänta tills klustrets autoskalning distribuerar nya arbetsnoder för att köra fler poddrepliker. Virtuella noder stöds endast med Linux-poddar och noder. Tillägget för virtuella noder för AKS baseras på det virtuella Kubelet-projektet med öppen källkod.

Funktionen för virtuell nod är beroende av Azure Container Instances. Mer information om virtuella noder finns i Skapa och konfigurera ett AKS-kluster (Azure Kubernetes Services) för användning av virtuella noder.

Taints, etiketter och taggar

När du skapar en nodpool kan du lägga till Kubernetes-taints och etiketter och Azure-taggar i den nodpoolen. När du lägger till en taint, etikett eller tagg får alla noder i nodpoolen den tainten, etiketten eller taggen.

Om du vill skapa en nodpool med en taint kan du använda az aks nodepool add kommandot med parametern --node-taints . Om du vill märka noderna i en nodpool kan du använda parametern --labels och ange en lista med etiketter, enligt följande kod:

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynodepool \
      --node-vm-size Standard_NC6 \
      --node-taints sku=gpu:NoSchedule \
      --labels dept=IT costcenter=9999

Mer information finns i Ange en taint, etikett eller tagg för en nodpool.

Reserverade systemetiketter

Amazon EKS lägger till automatiserade Kubernetes-etiketter till alla noder i en hanterad nodgrupp som eks.amazonaws.com/capacityType, som anger kapacitetstypen. AKS lägger också automatiskt till systemetiketter till agentnoder.

Följande prefix är reserverade för AKS-användning och kan inte användas för någon nod:

• kubernetes.azure.com/
• kubernetes.io/

För andra reserverade prefix, se Kubernetes välkända etiketter, anteckningar och taints.

I följande tabell visas etiketter som är reserverade för AKS-användning och som inte kan användas för någon nod. I tabellen anger kolumnen Användning av virtuell nod om etiketten stöds på virtuella noder.

I kolumnen Virtuell nodanvändning:

• N/A innebär att egenskapen inte gäller för virtuella noder eftersom det skulle kräva att värden ändras.
• Samma innebär att de förväntade värdena är desamma för en virtuell nodpool som för en standardnodpool.
• Virtuell ersätter SKU-värden för virtuella datorer eftersom virtuella nodpoddar inte exponerar någon underliggande virtuell dator.
• Den virtuella nodversionen refererar till den aktuella versionen av den virtuella Versionen av Kubelet-ACI-anslutningsappen.
• Undernätsnamnet för virtuell nod är det undernät som distribuerar virtuella nodpoddar till Azure Container Instances.
• Virtuellt nodnätverk är det virtuella nätverket som innehåller det virtuella nodundernätet.

Windows-nodpooler

AKS har stöd för att skapa och använda Windows Server-containernodpooler via azure-containernätverksgränssnittet (CNI). Information om hur du planerar nödvändiga undernätsintervall och nätverksöverväganden finns i Konfigurera Azure CNI-nätverk.

Följande az aks nodepool add kommando lägger till en nodpool som kör Windows Server-containrar.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mywindowsnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --os-type Windows \
      --node-count 1

Föregående kommando använder standardundernätet i det virtuella AKS-klustrets virtuella nätverk. Mer information om hur du skapar ett AKS-kluster med en Windows-nodpool finns i Skapa en Windows Server-container i AKS.

Överväganden för nodpool

Följande överväganden och begränsningar gäller när du skapar och hanterar nodpooler och flera nodpooler:

• Kvoter, storleksbegränsningar för virtuella datorer och regiontillgänglighet gäller för AKS-nodpooler.

• Systempooler måste innehålla minst en nod. Du kan ta bort en systemnodpool om du har en annan systemnodpool som ska ta plats i AKS-klustret. Användarnodpooler kan innehålla noll eller fler noder.

• Du kan inte ändra storleken på den virtuella datorn för en nodpool när du har skapat den.

• För flera nodpooler måste AKS-klustret använda Standard SKU-lastbalanserare. Grundläggande SKU-lastbalanserare stöder inte flera nodpooler.

• Alla klusternodpooler måste finnas i samma virtuella nätverk och alla undernät som är tilldelade till en nodpool måste finnas i samma virtuella nätverk.

• Om du skapar flera nodpooler när klustret skapas måste Kubernetes-versionerna för alla nodpooler matcha kontrollplanets version. Du kan uppdatera versioner när klustret har etablerats med hjälp av åtgärder per nodpool.

Skalning av nodpool

När programarbetsbelastningen ändras kan du behöva ändra antalet noder i en nodpool. Du kan skala upp eller ned antalet noder manuellt med kommandot az aks nodepool scale . I följande exempel skalas antalet noder in mynodepool till fem:

az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5

Skala nodpooler automatiskt med hjälp av autoskalning av kluster

AKS stöder automatiskt skalning av nodpooler med autoskalning av kluster. Du aktiverar den här funktionen i varje nodpool och definierar ett minsta och ett maximalt antal noder.

Följande az aks nodepool add kommando lägger till en ny nodpool som anropas mynodepool till ett befintligt kluster. Parametern --enable-cluster-autoscaler aktiverar autoskalning av kluster i den nya nodpoolen, och parametrarna --min-count och --max-count anger det lägsta och högsta antalet noder i poolen.

  az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --node-vm-size Standard_D8ds_v4 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

Följande az aks nodepool update-kommando uppdaterar det minsta antalet noder från en till tre för nodpoolen mynewnodepool .

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --update-cluster-autoscaler \
  --min-count 1 \
  --max-count 3

Du kan inaktivera autoskalning av klustret med az aks nodepool update genom att skicka parametern --disable-cluster-autoscaler .

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynodepool \
  --disable-cluster-autoscaler

Om du vill återanvända autoskalning av klustret i ett befintligt kluster använder du az aks nodepool update, anger parametrarna --enable-cluster-autoscaler, --min-countoch --max-count .

Mer information om hur du använder autoskalning av kluster för enskilda nodpooler finns i Skala ett kluster automatiskt för att uppfylla programkraven på Azure Kubernetes Service (AKS).

Uppdateringar och uppgraderingar

Azure uppdaterar regelbundet sin värdplattform för virtuella datorer för att förbättra tillförlitlighet, prestanda och säkerhet. Dessa uppdateringar sträcker sig från korrigering av programvarukomponenter i värdmiljön till uppgradering av nätverkskomponenter eller avaktivering av maskinvara. Mer information om hur Azure uppdaterar virtuella datorer finns i Underhåll för virtuella datorer i Azure.

Uppdateringar av vm-värdinfrastruktur påverkar vanligtvis inte värdbaserade virtuella datorer, till exempel agentnoder i befintliga AKS-kluster. För uppdateringar som påverkar värdbaserade virtuella datorer minimerar Azure de fall som kräver omstarter genom att pausa den virtuella datorn när värden uppdateras eller direktmigrera den virtuella datorn till en redan uppdaterad värd.

Om en uppdatering kräver en omstart tillhandahåller Azure ett meddelande och ett tidsfönster så att du kan starta uppdateringen när den fungerar åt dig. Självunderhållsfönstret för värddatorer är vanligtvis 35 dagar, såvida inte uppdateringen är brådskande.

Du kan använda Planerat underhåll för att uppdatera virtuella datorer och hantera meddelanden om planerat underhåll med Azure CLI, PowerShell eller Azure-portalen. Planerat underhåll identifierar om du använder automatisk uppgradering av kluster och schemalägger uppgraderingar under underhållsfönstret automatiskt. Mer information om planerat underhåll finns i kommandot az aks maintenanceconfiguration och Use Planned Maintenance to schedule maintenance windows for your Azure Kubernetes Service (AKS) cluster (Använda planerat underhåll för att schemalägga underhållsperioder för ditt AKS-kluster (Azure Kubernetes Service).

Kubernetes-uppgraderingar

En del av AKS-klusterlivscykeln uppgraderar regelbundet till den senaste Kubernetes-versionen. Det är viktigt att använda uppgraderingar för att få de senaste säkerhetsversionerna och funktionerna. Om du vill uppgradera Kubernetes-versionen av befintliga virtuella nodpooler måste du spärra och tömma noder och ersätta dem med nya noder som baseras på en uppdaterad Kubernetes-diskavbildning.

Som standard konfigurerar AKS uppgraderingar till överspänning med en extra nod. Ett standardvärde för en för max-surge inställningarna minimerar arbetsbelastningsavbrott genom att skapa en extra nod som ersätter äldre versionsnoder innan befintliga program spärras eller töms. Du kan anpassa max-surge värdet per nodpool för att möjliggöra en kompromiss mellan uppgraderingshastighet och uppgraderingsavbrott. max-surge Om du ökar värdet slutförs uppgraderingsprocessen snabbare, men ett stort värde för max-surge kan orsaka störningar under uppgraderingsprocessen.

Ett värde på 100 % ger till exempel max-surge den snabbaste möjliga uppgraderingsprocessen genom att dubblera antalet noder, men gör också att alla noder i nodpoolen töms samtidigt. Du kanske vill använda det här höga värdet för testning, men för produktionsnodpooler är en max-surge inställning på 33 % bättre.

AKS accepterar både heltals- och procentvärden för max-surge. Ett heltal som 5 anger att fem extra noder ska ökas. Procentvärden för max-surge kan vara minst 1% och högst , avrundade 100%upp till närmaste nodantal. Värdet 50% anger ett överspänningsvärde på hälften av det aktuella antalet noder i poolen.

Under en uppgradering max-surge kan värdet vara minst 1 och ett högsta värde som är lika med antalet noder i nodpoolen. Du kan ange större värden, men det maximala antalet noder som används för max-surge är inte högre än antalet noder i poolen.

Uppgradera nodpooler

Om du vill se tillgängliga uppgraderingar använder du az aks get-upgrades.

az aks get-upgrades --resource-group <myResourceGroup> --name <myAKSCluster>

Om du vill se status för nodpooler använder du az aks nodepool-listan.

  az aks nodepool list -g <myResourceGroup> --cluster-name <myAKSCluster>

Följande kommando använder az aks nodepool upgrade för att uppgradera en enskild nodpool.

  az aks nodepool upgrade \
      --resource-group <myResourceGroup> \
      --cluster-name <myAKSCluster> \
      --name <mynodepool> \
      --kubernetes-version <KUBERNETES_VERSION>

Mer information om hur du uppgraderar Kubernetes-versionen för ett klusterkontrollplan och nodpooler finns i:

• Uppgradering av AKS-nodavbildning (Azure Kubernetes Service)
• Uppgradera ett klusterkontrollplan med flera nodpooler

Att tänka på när du uppgraderar

Observera dessa metodtips och överväganden för att uppgradera Kubernetes-versionen i ett AKS-kluster.

• Det är bäst att uppgradera alla nodpooler i ett AKS-kluster till samma Kubernetes-version. Standardbeteendet för uppgraderingar av az aks upgrade alla nodpooler och kontrollplanet.

• Uppgradera manuellt eller ange en kanal för automatisk uppgradering i klustret. Om du använder Planerat underhåll för att korrigera virtuella datorer startar även automatiska uppgraderingar under det angivna underhållsfönstret. Mer information finns i Uppgradera ett kluster i Azure Kubernetes Service (AKS).

• Kommandot az aks upgrade med --control-plane-only flaggan uppgraderar bara klusterkontrollplanet och ändrar inte någon av de associerade nodpoolerna i klustret. Om du vill uppgradera enskilda nodpooler anger du målnodpoolen och Kubernetes-versionen i az aks nodepool upgrade kommandot .

• En AKS-klusteruppgradering utlöser en avspärrning och tömning av dina noder. Om du har låg beräkningskvot kan uppgraderingen misslyckas. Mer information om hur du ökar din kvot finns i Öka regionala vCPU-kvoter.

• Konfigurera parametern max-surge baserat på dina behov med hjälp av ett heltal eller ett procentvärde. För produktionsnodpooler använder du en max-surge inställning på 33 %. Mer information finns i Anpassa uppgradering av nodtoppar.

• När du uppgraderar ett AKS-kluster som använder CNI-nätverk kontrollerar du att undernätet har tillräckligt med tillgängliga privata IP-adresser för de extra noder som max-surge inställningarna skapar. Mer information finns i Konfigurera Azure CNI-nätverk i Azure Kubernetes Service (AKS).

• Om klusternodpoolerna sträcker sig över flera tillgänglighetszoner i en region kan uppgraderingsprocessen tillfälligt orsaka en obalanserad zonkonfiguration. Mer information finns i Särskilda överväganden för nodpooler som omfattar flera tillgänglighetszoner.

Virtuella nodnätverk

När du skapar ett nytt kluster eller lägger till en ny nodpool i ett befintligt kluster anger du resurs-ID för ett undernät i klustrets virtuella nätverk där du distribuerar agentnoderna. En arbetsbelastning kan kräva att ett klusters noder delas upp i separata nodpooler för logisk isolering. Du kan uppnå denna isolering med separata undernät, som var och en är dedikerade till en separat nodpool. De virtuella nodpoolsdatorerna får varsin privat IP-adress från sitt associerade undernät.

AKS stöder två plugin-program för nätverk:

• Kubenet är ett grundläggande, enkelt nätverksinsticksprogram för Linux. Med kubenetfår noder en privat IP-adress från Azure Virtual Network-undernätet. Poddar får en IP-adress från ett logiskt annat adressutrymme. Med NAT (Network Address Translation) kan poddarna nå resurser i det virtuella Azure-nätverket genom att översätta källtrafikens IP-adress till nodens primära IP-adress. Den här metoden minskar antalet IP-adresser som du behöver reservera i ditt nätverksutrymme för poddar.

• Azure Container Networking Interface (CNI) ger varje podd en IP-adress för att anropa och komma åt direkt. Dessa IP-adresser måste vara unika i nätverket. Varje nod har en konfigurationsparameter för det maximala antalet poddar som den stöder. Motsvarande antal IP-adresser per nod reserveras sedan för den noden. Den här metoden kräver förhandsplanering och kan leda till överbelastning av IP-adresser eller behovet av att återskapa kluster i ett större undernät när programkraven ökar.

  När du skapar ett nytt kluster eller lägger till en ny nodpool i ett kluster som använder Azure CNI kan du ange resurs-ID för två separata undernät, ett för noderna och ett för poddarna. Mer information finns i Dynamisk allokering av IP-adresser och utökat undernätsstöd.

Dynamisk IP-allokering

Poddar som använder Azure CNI får privata IP-adresser från ett undernät i värdnodpoolen. Dynamisk IP-allokering i Azure CNI kan allokera privata IP-adresser till poddar från ett undernät som är separat från nodpoolen som är värd för undernätet. Den här funktionen ger följande fördelar:

• Poddundernätet allokerar ip-adresser dynamiskt till poddar. Dynamisk allokering ger bättre IP-användning jämfört med den traditionella CNI-lösningen, som utför statisk allokering av IP-adresser för varje nod.

• Du kan skala och dela nod- och poddundernät oberoende av varandra. Du kan dela ett enda poddundernät över flera nodpooler eller kluster som distribuerats i samma virtuella nätverk. Du kan också konfigurera ett separat poddundernät för en nodpool.

• Eftersom poddar har privata IP-adresser för virtuella nätverk har de direktanslutning till andra klusterpoddar och resurser i det virtuella nätverket. Den här funktionen stöder bättre prestanda för mycket stora kluster.

• Om poddar har ett separat undernät kan du konfigurera principer för virtuella nätverk för poddar som skiljer sig från nodprinciper. Separata principer tillåter 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 en podd i en nodpool med hjälp av NAT Gateway och använda nätverkssäkerhetsgrupper (NSG: er) för att filtrera trafik mellan nodpooler.

• Både nätverksprincip och Calico Kubernetes-nätverksprinciper fungerar med dynamisk IP-allokering.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

• Paolo Salvatori | Huvudsystemtekniker

Övriga medarbetare:

• Laura Nicolas | Senior programvarutekniker
• Chad Kittel | Huvudprogramtekniker
• Ed Price | Senior Content Program Manager
• Theano Petersen | Teknisk författare

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

• AKS för Amazon EKS-proffs
• Kubernetes-identitets- och åtkomsthantering
• Övervakning och loggning av Kubernetes
• Säker nätverksåtkomst till Kubernetes
• Lagringsalternativ för ett Kubernetes-kluster
• Kostnadshantering för Kubernetes
• Klusterstyrning
• Lösningsresa för Azure Kubernetes Service (AKS)
• Dagsguide för Azure Kubernetes Services (AKS) dag-2
• Välj en Kubernetes vid beräkningsalternativet edge
• GitOps för Azure Kubernetes Service

Relaterade resurser

• Metodtips för AKS-kluster
• Skapa ett privat AKS-kluster med en offentlig DNS-zon
• Skapa ett privat Azure Kubernetes Service-kluster med Terraform och Azure DevOps
• Skapa ett offentligt eller privat Azure Kubernetes Service-kluster med Azure NAT Gateway och Azure Application Gateway
• Använda privata slutpunkter med ett privat AKS-kluster
• Skapa ett Azure Kubernetes Service-kluster med Application Gateway-ingresskontrollanten
• Introduktion till Kubernetes
• Introduktion till Kubernetes i Azure
• Implementera Azure Kubernetes Service (AKS)
• Utveckla och distribuera program i Kubernetes
• Optimera beräkningskostnader för Azure Kubernetes Service (AKS)