Formaat van knooppuntgroepen wijzigen in Azure Kubernetes Service (AKS)

Mogelijk wilt u de grootte van uw virtuele machines (VM's) wijzigen om een toenemend aantal implementaties aan te bieden of om een grotere workload uit te voeren. Het rechtstreeks wijzigen van het formaat van AKS-exemplaren wordt niet ondersteund bij het gebruik van virtuele-machineschaalsets in AKS, zoals wordt beschreven in het ondersteuningsbeleid voor AKS:

AKS-agentknooppunten worden in Azure Portal weergegeven als gewone Azure IaaS-resources. Deze virtuele machines worden echter geïmplementeerd in een aangepaste Azure-resourcegroep (meestal voorafgegaan door MC_*). U kunt geen directe aanpassingen aan deze knooppunten maken met behulp van de IaaS-API's of -resources. Aangepaste wijzigingen die niet via de AKS-API worden uitgevoerd, blijven niet behouden via een upgrade, schalen, update of opnieuw opstarten.

In dit artikel leert u de aanbevolen methode om het formaat van een knooppuntgroep te wijzigen door een nieuwe knooppuntgroep te maken met de gewenste SKU-grootte, cordoning en leegmaken van de bestaande knooppunten en vervolgens de bestaande knooppuntgroep te verwijderen.

Belangrijk

Deze methode is specifiek voor AKS-clusters op basis van virtuele-machineschaalsets. Wanneer u knooppuntgroepen op basis van virtuele machines gebruikt, kunt u de VM-grootten in een bestaande knooppuntgroep eenvoudig bijwerken met één Azure CLI-opdracht en meerdere VM-grootten in dezelfde knooppuntgroep hebben. Zie de documentatie voor knooppuntgroepen voor virtuele machines voor meer informatie.

Het formaat van een VMSS-knooppuntgroep direct wijzigen (preview)

Belangrijk

AKS preview-functies zijn beschikbaar op selfservice, opt-in basis. Previews worden geleverd 'zoals het is' en 'voor zover beschikbaar' en zijn uitgesloten van de serviceovereenkomsten en beperkte garantie. AKS-previews worden gedeeltelijk gedekt door klantondersteuning naar best vermogen. Zodoende zijn deze functies niet bedoeld voor productiegebruik. Zie de volgende ondersteuningsartikelen voor meer informatie:

U kunt nu het formaat van de VM-grootte (SKU) van een bestaande VMSS-knooppuntgroep wijzigen in één opdracht met behulp van az aks nodepool update --node-vm-size <new-size>. Wanneer u deze update activeert, voert de AKS-resourceprovider een rolling upgrade uit door:

  1. Nieuwe knooppunten toevoegen met de doel-VM-grootte.
  2. Cordoneren en de oude knooppunten leegmaken.
  3. De oude knooppunten verwijderen.

Dit voorkomt de handmatige werkstroom voor maken/cordon/afvoeren/verwijderen die in de rest van dit artikel wordt beschreven.

Hoe het uitrollen van formaatwijzigingen werkt

Voor de uitrol van het wijzigen van de grootte wordt dezelfde engine voor rolling upgrades gebruikt als voor een upgrade van de node-installatiekopie en een upgrade van de Kubernetes-versie, dus houdt deze rekening met de volgende upgradegerelateerde instellingen die al zijn geconfigureerd voor de nodegroep. Met name wordt bij het aanpassen van de grootte rekening gehouden met:

  • Maximale piek (--max-surge): bepaalt hoeveel extra knooppunten met de grootte van de doel-VM worden toegevoegd tijdens de implementatie. Een hogere waarde wijzigt de grootte van de pool sneller, maar verbruikt meer reken- en IP-quotum; een lagere waarde is langzamer, maar minder verstorend. De standaard AKS is 1en 33% wordt aanbevolen voor productieknooppuntgroepen.
  • Time-out voor leegmaken van knooppunt (--drain-timeout): Hoelang AKS wacht op de uitzetting van pods op elk oud knooppunt voordat het knooppunt geforceerd wordt verwijderd. De standaardwaarde is 30 minuten. Combineer dit met de juiste PodDisruptionBudgets, zodat workloads veilig kunnen worden leeggemaakt.
  • Inweektijd van knooppunten (--node-soak-duration): Hoe lang AKS wacht nadat een nieuw knooppunt Ready is geworden voordat AKS doorgaat naar de volgende batch. Handig voor het stabiliseren van workloads op de nieuwe VM-grootte voordat u doorgaat met de implementatie.

Omdat resize de upgradepijplijn opnieuw gebruikt, gelden dezelfde vereisten: zorg ervoor dat uw abonnement voldoende vervangingscapaciteit heeft voor de doel-VM-grootte en voldoende beschikbare subnet-IP's voor surgeknooppunten, en dat uw PodDisruptionBudgets toestaan dat ten minste één replica tegelijk wordt uitgezet; anders kan resize tijdens het leegmaken worden geblokkeerd. Zie Best practices voor upgrades van AKS-knooppuntgroepen voor volledige aanbevelingen.

Vereiste voorwaarden

Het formaat van de knooppuntgroep wijzigen

Gebruik de az aks nodepool update opdracht met de --node-vm-size parameter om de VM-grootte van een bestaande OP VMSS gebaseerde knooppuntgroep te wijzigen:

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

Validatie en niet-ondersteunde combinaties

De AKS-resourceprovider valideert de aanvraag voor het wijzigen van de VM-grootte en blokkeert incompatibele wijzigingen van VM-grootte. De volgende wijzigingen worden niet ondersteund tijdens een in-place wijziging van de grootte van een VMSS:

  • Het type schijfcontroller wijzigen (bijvoorbeeld SCSI naar NVMe).
  • De CPU-architectuur wijzigen (bijvoorbeeld x64 in ARM64).
  • Ondersteuning voor confidential computing wijzigen (bijvoorbeeld SNP in- of uitschakelen).
  • De hypervisorgeneratie wijzigen (bijvoorbeeld V1 naar V2).
  • Het wijzigen van de grootte combineren met een upgrade van de Kubernetes-versie of een wijziging van het aantal knooppunten tijdens dezelfde bewerking.

Als uw beoogde VM-grootte een van de bovenstaande wijzigingen vereist, gebruik dan in plaats daarvan de handmatige cordon-and-drain-procedure die in de volgende secties wordt beschreven.

Notitie

Voor een in-place formaatwijziging is extra capaciteit vereist om nieuwe knooppunten met de doel-VM-grootte te provisioneren voordat de oude worden leeggemaakt. Als de knooppuntgroep is geconfigureerd met --max-surge 0 (dat wil gezegd, --max-unavailable is van kracht), wordt de aanvraag voor het wijzigen van de grootte geweigerd met een 400 Bad Request. Als u wilt doorgaan, stelt u --max-surge in op ten minste 1 bij het aanpassen van het formaat met

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

en u kunt de oorspronkelijke --max-surge waarde en --max-unavailable waarden desgewenst herstellen nadat het formaat is gewijzigd.

Een nieuwe knooppuntgroep maken met de gewenste SKU

Notitie

Elk AKS-cluster moet ten minste één systeemknooppuntgroep met ten minste één knooppunt bevatten. In dit voorbeeld gebruiken we een --mode van System om een systeemknooppuntgroep toe te voegen ter vervanging van de systeemknooppuntgroep die we willen herformateren. U kunt de modus van een knooppuntgroep op elk gewenst moment bijwerken. U kunt ook een gebruikersknooppuntgroep toevoegen door deze in te stellen --mode op User.

Zorg er bij het wijzigen van de grootte voor dat u rekening houdt met alle workloadvereisten, zoals beschikbaarheidszones, en configureer uw VMSS-knooppuntgroep dienovereenkomstig. Mogelijk moet u de volgende opdracht aanpassen aan uw behoeften. Zie de az aks nodepool add referentiepagina voor een volledige lijst met configuratieopties.

  1. Maak een nieuwe knooppuntgroep met behulp van de az aks nodepool add opdracht. In dit voorbeeld maken we een nieuwe knooppuntgroep, mynodepoolmet drie knooppunten en de Standard_DS3_v2 VM-SKU om een bestaande knooppuntgroep te vervangen, nodepool1die de Standard_DS2_v2 VM-SKU bevat.

    az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 3 \
    --node-vm-size Standard_DS3_v2 \
    --mode System \
    --no-wait

    Het duurt enkele minuten voordat de nieuwe knooppuntgroep is gemaakt.

  2. Haal de status van de nieuwe knooppuntgroep op met behulp van de kubectl get nodes opdracht.

    kubectl get nodes

    De uitvoer moet lijken op de volgende voorbeelduitvoer, met zowel de nieuwe knooppuntgroep mynodepool als de bestaande knooppuntgroep nodepool1:

    NAME                                 STATUS   ROLES   AGE   VERSION
aks-mynodepool-98765432-vmss000000   Ready    agent   23m   v1.21.9
aks-mynodepool-98765432-vmss000001   Ready    agent   23m   v1.21.9
aks-mynodepool-98765432-vmss000002   Ready    agent   23m   v1.21.9
aks-nodepool1-12345678-vmss000000    Ready    agent   10d   v1.21.9
aks-nodepool1-12345678-vmss000001    Ready    agent   10d   v1.21.9
aks-nodepool1-12345678-vmss000002    Ready    agent   10d   v1.21.9

Cordon de bestaande knooppunten

Cordoning markeert opgegeven knooppunten als niet planbaar en voorkomt dat er nog meer pods op de knooppunten worden geplaatst.

  1. Haal de namen op van de knooppunten die u wilt snoeren met behulp van de kubectl get nodes opdracht.

    kubectl get nodes

    De uitvoer moet eruitzien zoals in de volgende voorbeelduitvoer, met de knooppunten in de bestaande knooppuntgroep nodepool1 die u wilt cordoneren:

    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. Cordon de bestaande knooppunten met behulp van de kubectl cordon opdracht, waarbij de gewenste knooppunten in een door spaties gescheiden lijst worden opgegeven. Voorbeeld:

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

    Uw uitvoer moet er ongeveer uitzien als in de volgende voorbeelduitvoer, waarin wordt weergegeven dat de knooppunten zijn gekoppeld:

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

De bestaande knooppunten leegmaken

Belangrijk

Als u knooppunten wilt verwijderen en actieve pods wilt verwijderen, moet u ervoor zorgen dat podDisruptionBudgets (PDBs) ervoor zorgen dat ten minste één podreplica tegelijk kan worden verplaatst. Anders mislukt de afvoer-/verwijderingsbewerking. U kunt dit controleren door kubectl get pdb -A uit te voeren en te bevestigen dat ALLOWED DISRUPTIONS ten minste 1 of hoger is.

Wanneer u knooppunten leegt, worden de pods die erop draaien afgevoerd en opnieuw gecreëerd op de andere inplanbare knooppunten.

  1. Maak de bestaande knooppunten leeg met behulp van de kubectl drain opdracht en --ignore-daemonsets--delete-emptydir-data vlaggen, waarbij de gewenste knooppunten in een door spaties gescheiden lijst worden opgegeven. Voorbeeld:

    Belangrijk

    Het gebruik van --delete-emptydir-data is vereist om de door AKS aangemaakte coredns- en metrics-server-pods te verwijderen. Als u deze vlag niet gebruikt, krijgt u een foutmelding. Zie de documentatie over emptydir voor meer informatie.

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

  2. Nadat de afvoerbewerking is voltooid, moeten alle pods (met uitzondering van de pods die worden beheerd door daemonsets) draaien in de nieuwe knooppuntgroep. U kunt dit controleren met behulp van de kubectl get pods opdracht.

    kubectl get pods -o wide -A

Pod-verwijderingsproblemen oplossen

Mogelijk treedt de volgende fout op bij het leegmaken van knooppunten:

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

Standaard bevat uw cluster door AKS beheerde onderbrekingsbudgetten voor pods (zoals coredns-pdb of konnectivity-agent) met een MinAvailable van 1. Als er bijvoorbeeld twee coredns pods actief zijn, kan er slechts één tegelijk worden onderbroken. Hoewel een van deze opnieuw wordt gemaakt en niet beschikbaar is, kan de andere coredns pod niet worden verwijderd vanwege het budget voor podonderbreking. Dit probleem lost automatisch op nadat de eerste coredns pod is ingepland en draait, waardoor de tweede pod correct kan worden verwijderd en opnieuw kan worden aangemaakt.

Tip:

Overweeg om knooppunten één voor één leeg te maken voor een soepelere evacuatie en om vertraging te voorkomen. Zie voor meer informatie:

De bestaande knooppuntgroep verwijderen

Belangrijk

Wanneer u een knooppuntgroep verwijdert, voert AKS geen cordon en afvoer uit. Om de verstoring van het herschikken van pods die momenteel actief zijn op de knooppuntgroep die u van plan bent te verwijderen te minimaliseren, voert u een cordon en drain uit op alle knooppunten in de knooppuntgroep voordat u deze verwijdert.

  1. Verwijder de oorspronkelijke knooppuntgroep met behulp van de az aks nodepool delete opdracht.

    az aks nodepool delete \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name nodepool1

  2. Controleer of uw AKS-cluster alleen de nieuwe knooppuntgroep heeft met de toepassingen en pods die correct worden uitgevoerd met behulp van de kubectl get nodes opdracht.

    kubectl get nodes

    De uitvoer moet eruitzien zoals in de volgende voorbeelduitvoer, met alleen de nieuwe knooppuntgroep mynodepool:

    NAME                                 STATUS   ROLES   AGE   VERSION
aks-mynodepool-98765432-vmss000000   Ready    agent   63m   v1.21.9
aks-mynodepool-98765432-vmss000001   Ready    agent   63m   v1.21.9
aks-mynodepool-98765432-vmss000002   Ready    agent   63m   v1.21.9

Volgende stappen

Nadat u het formaat van een knooppuntgroep hebt gewijzigd door deze af te bakenen en leeg te laten lopen, leest u meer over het gebruik van meerdere knooppuntgroepen.

  • Last updated on