Delen via

Upgradeopties en aanbevelingen voor AKS-clusters (Azure Kubernetes Service)

Dit artikel behandelt upgradeopties voor AKS-clusters en biedt aanbevelingen op basis van scenario's voor veelvoorkomende upgradeproblemen.

Upgrade opties

Handmatige upgrades uitvoeren

Met handmatige upgrades kunt u bepalen wanneer uw cluster wordt bijgewerkt naar een nieuwe Kubernetes-versie. Handig voor het testen of afstemmen op een specifieke versie.

Automatische upgrades configureren

Automatische upgrades houden uw cluster op een ondersteunde versie en up-to-date. Dit is wanneer u wilt instellen en vergeten.

Speciale overwegingen voor knooppuntgroepen die meerdere beschikbaarheidszones omvatten

AKS maakt gebruik van best-effort zonebalancering in knooppuntgroepen. Tijdens een upgrade-piek zijn de zones voor piekknooppunten in virtuele-machineschaalsets van tevoren onbekend, wat tijdelijk een niet-evenwichtige zoneconfiguratie kan veroorzaken. AKS verwijdert piekknooppunten na de upgrade en herstelt de oorspronkelijke zonebalans. Als u zones evenwichtig wilt houden, stelt u een piek in op een veelvoud van drie knooppunten. PVC's die azure LRS-schijven gebruiken, zijn zonegebonden en kunnen downtime veroorzaken als piekknooppunten zich in een andere zone bevinden. Gebruik een Pod Disruption Budget om hoge beschikbaarheid te behouden tijdens draineeracties.

Het optimaliseren van upgrades om de prestaties te verbeteren en onderbrekingen te minimaliseren

Combineer gepland onderhoudsvenster, maximale belasting, budget voor podonderbreking, timeout voor knooppuntafvoer en knoppuntinweektijd om de kans op succesvolle upgrades met minimale verstoringen te vergroten.

Upgrade-instellingen Hoe extra knooppunten worden gebruikt Verwacht gedrag
maxSurge=5, maxUnavailable=0 5 piekknooppunten 5 knooppunten zijn overgesprongen voor de upgrade
maxSurge=5, maxUnavailable=0 0-4 piekknooppunten Upgrade mislukt vanwege onvoldoende piekknooppunten
maxSurge=0, maxUnavailable=5 Niet van toepassing. 5 bestaande knooppunten zijn leeggezogen voor de upgrade

Opmerking

Controleer voordat u een upgrade uitvoert op wijzigingen die fouten veroorzaken in de API en bekijk de opmerkingen bij de AKS-release om onderbrekingen te voorkomen.

Validaties die worden gebruikt in het upgradeproces

AKS voert pre-upgradevalidaties uit om de clusterstatus te garanderen:

  • Breken wijzigingen in de API: Detecteert verouderde API's.
  • Upgradeversie van Kubernetes: Zorgt voor een geldig upgradepad.
  • PDB-configuratie: Controleert op onjuist geconfigureerde PDBs (bijvoorbeeld maxUnavailable=0).
  • Quotum: Bevestigt voldoende quotum voor piekknooppunten.
  • Subnet: Controleert voldoende IP-adressen.
  • Certificaten/Service Principals: Detecteert verlopen inloggegevens.

Deze controles helpen bij het minimaliseren van upgradefouten en bieden vroegtijdig inzicht in problemen.

Algemene upgradescenario's en aanbevelingen

Scenario 1: Capaciteitsbeperkingen

Als uw cluster wordt beperkt door SKU of regionale capaciteit, kunnen upgrades mislukken wanneer piekknooppunten niet kunnen worden ingericht. Dit is gebruikelijk bij gespecialiseerde SKU's (zoals GPU-knooppunten) of in regio's met beperkte resources. Fouten zoals SKUNotAvailable, AllocationFailedof OverconstrainedAllocationRequest kunnen optreden als maxSurge deze te hoog is ingesteld voor de beschikbare capaciteit.

Aanbevelingen om te voorkomen of op te lossen

  • Gebruik maxUnavailable om een upgrade uit te voeren met bestaande knooppunten in plaats van nieuwe te maken. Meer informatie.
  • Verlaag maxSurge om extra capaciteitsbehoeften te verminderen. Meer informatie.
  • Gebruik voor alleen beveiligingsupdates installatiekopies die geen piekknooppunten vereisen. Meer informatie.

Scenario 2: Knooppuntleegmaakfouten en PDBs

Voor upgrades moeten knooppunten worden leeggemaakt (pods worden ontruimd). Afvoeren kunnen mislukken als:

  • Pods zijn langzaam te beëindigen (lange afsluithaken of permanente verbindingen).
  • Strict Pod Disruption Budgets (PDBs) blokkeren pod ontheffingen.

Voorbeeld van foutbericht:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... failed with Too Many Requests error. This is often caused by a restrictive Pod Disruption Budget (PDB) policy. See https://aka.ms/aks/debugdrainfailures. Original error: Cannot evict pod as it would violate the pod's disruption budget. PDB debug info: ... blocked by pdb ... with 0 unready pods.

Aanbevelingen om te voorkomen of op te lossen

  • Stel maxUnavailable in PDBs zodanig in dat ten minste één pod kan worden verwijderd.
  • Verhoog de podreplica's zodat het verstoringsbudget verwijderingen kan tolereren.
  • Gebruik undrainableNodeBehavior dit om upgrades toe te staan om door te gaan, zelfs als sommige knooppunten niet kunnen worden leeggemaakt:
    • Planning (standaard): Vervanging van knooppunten en stuwdruk kan mogelijk worden achterwege gelaten, wat kan leiden tot verminderde capaciteit.
    • Cordon (aanbevolen): Knooppunt is gesnoerd en gelabeld als kubernetes.azure.com/upgrade-status=Quarantined.

      • Voorbeeldopdracht:

        az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon

        In de volgende voorbeelduitvoer wordt het onuitputtelijke gedrag van het knooppunt bijgewerkt weergegeven:

        "upgradeSettings": {
"drainTimeoutInMinutes": null,
"maxSurge": "1",
"nodeSoakDurationInMinutes": null,
"undrainableNodeBehavior": "Cordon"
}

Maximaal toegestane geblokkeerde knooppunten (preview)

  • [Preview] De functie Maximaal toegestane geblokkeerde knooppunten stelt u in staat om op te geven hoeveel knooppunten die niet succesvol kunnen worden leeggelopen (geblokkeerde knooppunten) tijdens upgrades of soortgelijke bewerkingen acceptabel zijn. Deze functie werkt alleen als de eigenschap van onafgebroken knooppuntgedrag is ingesteld; anders zal de opdracht een fout retourneren.

Opmerking

Als u 'Maximaal Toegestane Geblokkeerde Knooppunten' niet expliciet instelt, wordt dit standaard ingesteld op de waarde van Maximale Toevoeging. Als max. piek niet is ingesteld, is de standaardwaarde doorgaans 10%, dus max geblokkeerde knooppunten toegestaan, wordt standaard ingesteld op 10%.

Voorwaarden

  • Azure CLI-extensie aks-preview versie 18.0.0b9 of hoger is vereist voor het gebruik van deze functie.

    Voorbeeldopdracht:

    az aks nodepool update \
  --cluster-name jizenMC1 \
  --name nodepool1 \
  --resource-group jizenTestMaxBlockedNodesRG \
  --max-surge 1 \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 5
  • Breid de time-out van de afvoer uit als workloads meer tijd nodig hebben (de standaardwaarde is 30 minuten).
  • Test PDBs in de stagingomgeving, bewaak upgrade-events en gebruik blue-green deployments voor kritieke workloads. Meer informatie.

Ondraineerbare knooppunten verifiëren

  • De geblokkeerde knooppunten zijn niet ingepland voor pods en gemarkeerd met het label "kubernetes.azure.com/upgrade-status: Quarantined".

  • Controleer de labels van geblokkeerde knooppunten wanneer er een drainknooppuntstoring is tijdens de upgrade.

    kubectl get nodes --show-labels=true

Niet-bewerkbare knooppunten oplossen

  1. Verwijder de verantwoordelijke PDB:

    kubectl delete pdb <pdb-name>

  2. Verwijder het kubernetes.azure.com/upgrade-status: Quarantined label:

    kubectl label nodes <node-name> <label-name>

  3. Verwijder eventueel het geblokkeerde knooppunt:

    az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>

  4. Nadat u deze stap hebt voltooid, kunt u de clusterstatus afstemmen door een updatebewerking uit te voeren zonder de optionele velden, zoals hier wordt beschreven. U kunt de knooppuntgroep ook schalen naar hetzelfde aantal knooppunten als het aantal bijgewerkte knooppunten. Deze actie zorgt ervoor dat de knooppuntgroep de beoogde oorspronkelijke grootte krijgt. AKS geeft prioriteit aan het verwijderen van de geblokkeerde knooppunten. Met deze opdracht wordt ook de inrichtingsstatus van het cluster hersteld naar Succeeded. In het gegeven voorbeeld is 2 het totale aantal bijgewerkte knooppunten.

    # Update the cluster to restore the provisioning status
az aks update --resource-group <resource-group-name> --name <cluster-name>

# Scale the node pool to restore the original size
az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2

Scenario 3: Trage upgrades

Upgrades kunnen worden vertraagd door conservatieve instellingen of problemen op knooppuntniveau, wat van invloed is op uw vermogen om op de hoogte te blijven van patches en verbeteringen.

Veelvoorkomende oorzaken van trage upgrades zijn:

  • Laag maxSurge of maxUnavailable waarden (beperkt parallellisme).
  • Hoge inweektijden (lange wachttijden tussen knooppuntupgrades).
  • Leegloopfouten (zie Knooppuntafvoerfouten]).

Aanbevelingen om te voorkomen of op te lossen

  • Voor productie: maxSurge=33%, maxUnavailable=1.
  • Voor dev/test: maxSurge=50%, maxUnavailable=2.
  • Gebruik de beveiligingspatch voor het besturingssysteem voor snelle, gerichte patches (vermijd volledige knooppunten die opnieuw worden gebruikt).
  • Schakel deze optie undrainableNodeBehavior in om upgradeblokkeringen te voorkomen.

Scenario 4: IP-uitputting

Piekknooppunten vereisen extra IP-adressen. Als het subnet bijna vol is, kan het inrichten van knooppunten mislukken (bijvoorbeeld Error: SubnetIsFull). Dit is gebruikelijk met Azure CNI, hoog maxPodsof groot aantal knooppunten.

Aanbevelingen om te voorkomen of op te lossen

  • Zorg ervoor dat uw subnet voldoende IP-adressen heeft voor alle knooppunten, piekknooppunten en pods:

    • Formule: Total IPs = (Number of nodes + maxSurge) * (1 + maxPods)

  • Maak ongebruikte IP-adressen vrij of vouw het subnet uit (bijvoorbeeld van /24 tot /22).

  • Lager maxSurge als subnetuitbreiding niet mogelijk is:

    az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --max-surge 10%

  • IP-gebruik bewaken met Azure Monitor of aangepaste waarschuwingen.

  • Verminder maxPods per knooppunt, schoon zwevende load balancer-IP's op en plan de grootte van subnetten voor grootschalige clusters.

Volgende stappen

  • Bekijk de AKS-patch- en upgraderichtlijnen voor best practices en planningstips voordat u een upgrade start.
  • Controleer altijd op wijzigingen die fouten veroorzaken in de API en valideer de compatibiliteit van uw workloads met de kubernetes-doelversie.
  • Test upgrade-instellingen (zoals maxSurge, maxUnavailableen PDBs) in een faseringsomgeving om productierisico's te minimaliseren.
  • Bewaak de upgrade-gebeurtenissen en clusterstatus gedurende het hele proces.