Ändra storleken på nodpooler i Azure Kubernetes Service (AKS)

Du kanske vill ändra storleken på dina virtuella datorer (VM) för att hantera ett ökande antal distributioner eller för att köra en större arbetsbelastning. Storleksändring av AKS-instanser direkt stöds inte när du använder Virtuella Datorers Skalningsuppsättningar i AKS, enligt AKS supportprinciper:

AKS-agentnoder visas i Azure Portal som vanliga Azure IaaS-resurser. Men dessa virtuella datorer distribueras till en anpassad Azure-resursgrupp (vanligtvis prefix med MC_*). Du kan inte göra direkta anpassningar till dessa noder med hjälp av IaaS-API:er eller resurser. Eventuella anpassade ändringar som inte görs via AKS-API:et bevaras inte via en uppgradering, skalning, uppdatering eller omstart.

I den här artikeln lär du dig den rekommenderade metoden för att ändra storlek på en nodpool genom att skapa en ny nodpool med önskad SKU-storlek, spärra och tömma befintliga noder och sedan ta bort den befintliga nodpoolen.

Ändra storlek på en VMSS-nodpool på plats (förhandsversion)

Nu kan du ändra storlek på vm-storleken (SKU) för en befintlig VMSS-baserad nodpool i ett enda kommando med hjälp av az aks nodepool update --node-vm-size <new-size>. När du utlöser den här uppdateringen utför AKS-resursprovidern en löpande uppgradering genom att:

1. Skalar upp nya noder med målstorleken för den virtuella datorn.
2. Avspärrning och tömning av de gamla noderna.
3. Ta bort de gamla noderna.

Detta undviker det manuella arbetsflödet med create/cordon/drain/delete som beskrivs i resten av den här artikeln.

Så här fungerar storleksändringsdistributionen

Storleksändringsdistributionen använder samma löpande uppgraderingsmotor som en nodbilduppgradering och en Kubernetes-versionsuppgradering, så att den uppfyller följande uppgraderingsrelaterade inställningar som redan har konfigurerats i nodpoolen. I synnerhet tar storleksändringen hänsyn till:

• Maximal ökning (--max-surge): Styr hur många extra noder med mål-VM-storleken som läggs till under distributionen. Ett högre värde ändrar storlek på poolen snabbare men förbrukar mer beräknings- och IP-kvot. ett lägre värde är långsammare men mindre störande. AKS-standardvärdet är 1, och 33% rekommenderas för produktionsnodpooler.
• Tidsgräns för noddränering (--drain-timeout): Hur länge AKS väntar på att poddavhysningen ska tas bort på varje gammal nod innan den tas bort. Standardvärdet är 30 minuter. Kombinera detta med lämpliga PodDisruptionBudgets så att arbetsbelastningar kan tömmas på ett säkert sätt.
• Varaktighet för nodblödning (--node-soak-duration): Hur länge AKS väntar efter att en ny nod blir Klar innan den går vidare till nästa batch. Användbart för att låta arbetsbelastningar stabiliseras på den nya vm-storleken innan du fortsätter distributionen.

Eftersom ändring av storlek återanvänder uppgraderingsprocessen gäller samma förutsättningar: se till att din prenumeration har tillräcklig ersättningskapacitet för målstorleken på den virtuella datorn och tillgängliga undernäts-IP-adresser för surge-noder, och att dina PodDisruptionBudgets tillåter att minst en replik avvisas i taget, annars kan ändring av storlek blockeras under dräneringen. Rekommendationer från slutpunkt till slutpunkt finns i Metodtips för uppgraderingar av AKS-nodpooler.

Prerequisites

• AKS API-version 2026-01-02-preview eller senare.
• Den senaste versionen av aks-preview Azure CLI-tillägget.

Ändra storlek på nodpoolen

az aks nodepool update Använd kommandot med parametern --node-vm-size för att ändra storleken på den virtuella datorn för en befintlig VMSS-baserad nodpool:

az aks nodepool update \
    --resource-group MyResourceGroup \
    --cluster-name MyManagedCluster \
    --name nodepool1 \
    --node-vm-size Standard_D4s_v3

Validering och kombinationer som inte stöds

AKS-resursprovidern validerar storleksändringsbegäran och blockerar ändringar i den inkompatibla vm-storleken. Följande ändringar stöds inte som en del av en VMSS-storleksändring på plats:

• Ändra typ av diskkontrollant (till exempel SCSI till NVMe).
• Ändra CPU-arkitekturen (till exempel x64 till ARM64).
• Ändra stöd för konfidentiell databehandling (till exempel aktivering eller inaktivering av SNP).
• Ändra hypervisor-genereringen (till exempel V1 till V2).
• Kombinera storleksändringen med en Kubernetes-versionsuppgradering eller en ändring av antalet noder i samma åtgärd.

Om din virtuella måldators storlek kräver någon av ändringarna ovan använder du arbetsflödet för manuell avspärrning och avspärrning som beskrivs i följande avsnitt i stället.

az aks nodepool update \
    --resource-group MyResourceGroup \
    --cluster-name MyManagedCluster \
    --name nodepool1 \
    --node-vm-size Standard_D4s_v3 \
    --max-surge 33%

Skapa en ny nodpool med önskad SKU

Spärra de befintliga noderna

Avspärrning markerar angivna noder som oplanerade och förhindrar att fler poddar läggs till i noderna.

1. Hämta namnen på de noder som du vill spärra med kommandot kubectl get nodes .

   kubectl get nodes
   

   Dina utdata bör likna följande exempelutdata som visar noderna i den befintliga nodpoolen nodepool1 som du vill spärra:

   NAME                                STATUS   ROLES   AGE     VERSION
   aks-nodepool1-12345678-vmss000000   Ready    agent   7d21h   v1.21.9
   aks-nodepool1-12345678-vmss000001   Ready    agent   7d21h   v1.21.9
   aks-nodepool1-12345678-vmss000002   Ready    agent   7d21h   v1.21.9
   

2. Spärra de befintliga noderna med kommandot kubectl cordon och ange önskade noder i en blankstegsavgränsad lista. Till exempel:

   kubectl cordon aks-nodepool1-12345678-vmss000000 aks-nodepool1-12345678-vmss000001 aks-nodepool1-12345678-vmss000002
   

   Dina utdata bör likna följande exempelutdata som visar att noderna är avspärrade:

   node/aks-nodepool1-12345678-vmss000000 cordoned
   node/aks-nodepool1-12345678-vmss000001 cordoned
   node/aks-nodepool1-12345678-vmss000002 cordoned
   

Töm de befintliga noderna

När du tömmer noder avlägsnas podarna som körs på dem, vilket innebär att de återskapas på andra schemaläggningsbara noder.

1. Töm de befintliga noderna med kubectl drain-kommandot och flaggorna --ignore-daemonsets och --delete-emptydir-data, genom att ange önskade noder i en blankstegsavgränsad lista. Till exempel:

   Viktigt!

   Det är nödvändigt att använda --delete-emptydir-data för att ta bort de coredns- och metrics-server-poddar som skapats av AKS. Om du inte använder den här flaggan får du ett fel. Mer information finns i dokumentationen om emptydir.

   kubectl drain aks-nodepool1-12345678-vmss000000 aks-nodepool1-12345678-vmss000001 aks-nodepool1-12345678-vmss000002 --ignore-daemonsets --delete-emptydir-data
   

2. När dräneringsåtgärden är klar ska alla poddar (exklusive poddar som styrs av daemonuppsättningar) köras i den nya nodpoolen. Du kan verifiera detta med kommandot kubectl get pods.

   kubectl get pods -o wide -A
   

Felsöka problem med utvisning av poddar

Du kan stöta på följande fel när du tömmer noder:

Error when evicting pods/[podname] -n [namespace] (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

Som standardinställning har klustret AKS-hanterade poddavbrottsbudgetar (till exempel coredns-pdb eller konnectivity-agent) med en MinAvailable av 1. Om det till exempel finns två coredns poddar som körs kan bara en avbrytas i taget. Medan en av dem återskapas och inte är tillgänglig kan den andra coredns podden inte tas bort på grund av poddens avbrottsbudget. Det här problemet löser sig när den första coredns podden schemaläggs och är igång, vilket möjliggör att den andra podden kan avlägsnas och återskapas korrekt.

Ta bort den befintliga nodpoolen

Nästa steg

När du har storleksanpassat en nodpool genom avspärrning och tömning kan du läsa mer om hur du använder flera nodpooler.