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

Van toepassing op: ✔️ AKS Automatic ✔️ AKS Standard

Voor de meeste productieworkloads is AKS Automatic de aanbevolen standaardclusterervaring. Het biedt productierijpe standaardinstellingen voor levenscyclusbewerkingen van clusters en knooppunten, waaronder gedrag bij beheerde upgrades, ingebouwde beveiligingen en minder operationele overhead.

AKS Standard blijft beschikbaar voor scenario's waarbij u uitgebreidere handmatige controle nodig hebt over upgrademechanica, netwerkkeuzes of gedrag van knooppuntgroepen.

Dit artikel biedt u een technische basis voor AKS-upgrades door upgradeopties, algemene scenario's en aanbevelingen voor zowel AKS Automatic als AKS Standard te behandelen.

Wat in dit artikel wordt behandeld

In deze technische naslaginformatie wordt het volgende behandeld:

  • Waarom AKS Automatic de aanbevolen standaardinstelling voor productie is voor de meeste workloads.
  • Hoe het upgradegedrag verschilt tussen AKS Automatic en AKS Standard.
  • Handmatige versus geautomatiseerde upgradepaden en wanneer u deze wilt gebruiken.
  • Algemene upgradescenario's met specifieke aanbevelingen.
  • Optimalisatietechnieken voor prestaties en minimale onderbrekingen.
  • Validatieprocessen en controles vóór de upgrade.

Voor gerelateerde richtlijnen:

Snelle navigatie

Uw situatie Aanbevolen pad
Nieuwe of bestaande productieworkload zonder speciale aanpassingsvereisten Een automatisch AKS-cluster maken
Productiecluster met strikte aangepaste upgradebeheeropties Strategieën voor productie-upgrades
Database- of statusvolle workloads Stateful workloadpatronen
Eerste AKS Standard-upgrade Upgrade van AKS-basiscluster
Meerdere omgevingen of vlootbeheer Hub voor upgradescenario's
Knooppuntgroepen of Windows knooppunten in AKS Standard Upgrades van knooppuntgroepen
Alleen specifieke knooppuntgroep Upgrade van pool met één knooppunt

Operationele modellen upgraden

AKS Automatic is standaard ontworpen voor productieklare bewerkingen. Voor upgrades biedt AKS Automatic het volgende:

  • Beheerde systeemknooppuntgroepen.
  • Gedrag van automatische clusterupgrades met standaardinstellingen die door het platform worden beheerd.
  • Gedrag van automatische upgrades van OS-installatiekopieën van knooppunten met een beveiligingsgerichte cadans.
  • Ingebouwde controles voor afgeschafte Kubernetes-API's.
  • Ondersteuning voor gepland onderhoud.

Gebruik AKS Automatic als u handmatige upgrade-indeling wilt minimaliseren en productieclusters met minder inspanning wilt afstemmen op ondersteunde versies.

AKS Standard (geavanceerd besturingsmodel)

AKS Standard biedt u directe controle over het sequentiëren en afstemmen van upgrades. U kiest en beheert het volgende:

  • Configuratie voor handmatige of automatische upgrades.
  • Kanaalselectie upgraden.
  • Gedrag van knooppuntgroepen en pieken.
  • Operationele procedures voor onderhoudsvensters en budgetten voor werkbelastingonderbreking.

Gebruik AKS Standard wanneer uw omgeving aanpassingen vereist die verder gaan dan de automatische standaardinstellingen van AKS.

Upgrade opties

Handmatige upgrades uitvoeren

Is voornamelijk van toepassing op AKS Standard of op gespecialiseerde operationele werkstromen.

Met handmatige upgrades kunt u bepalen wanneer uw cluster wordt bijgewerkt naar een nieuwe Kubernetes-versie. Deze upgrades zijn nuttig voor tests, gefaseerde uitrol en gerichte adoptie van versies.

Automatische upgrades configureren

Voor AKS Standard helpen automatische upgrades clusters op ondersteunde versies te behouden, terwijl de controle over beleid en planning behouden blijft. In AKS Automatic maken automatisering en kaders voor upgrades al deel uit van het standaardbedrijfsmodel.

Speciale overwegingen voor knooppuntgroepen die meerdere beschikbaarheidszones omvatten

AKS maakt gebruik van zoneverdeling met best effort 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. Permanente volumeclaims die lokaal redundante opslagschijven van Azure gebruiken, zijn zonegebonden en kunnen downtime veroorzaken als piekknooppunten zich in een andere zone bevinden. Gebruik een budget voor podonderbreking (PDB) om hoge beschikbaarheid te behouden tijdens afvoeren.

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

Combineer gepland onderhoudsvenster, maximale toename, PDB, time-out voor het leegmaken van knooppunten en inwerktijd van knooppunten om de kans op succesvolle upgrades met minimale onderbrekingen te vergroten.

AKS Automatisch

In AKS Automatic is het upgradegedrag op platformniveau vooraf geconfigureerd. Richt uw afstemming op de veerkracht van workloads en capaciteitsparaatheid:

  • Valideer budgetten voor podonderbrekingen en replicaaantallen.
  • Zorg voor quotum- en subnetcapaciteit voor verwachte groei.
  • Stel geplande onderhoudsschema's in die zijn afgestemd op perioden met weinig verkeer.
  • Bewaak upgradegebeurtenissen en de gereedheid van kritieke workloads.

AKS Standard

In AKS Standard kunt u de instellingen voor upgrades rechtstreeks aanpassen:

Upgrade-instellingen Hoe extra knooppunten worden gebruikt Verwacht gedrag
maxSurge=5, maxUnavailable=0 5 piekknooppunten Er worden vijf knooppunten ingezet voor een upgradeproces.
maxSurge=5, maxUnavailable=0 0-4 piekknooppunten Upgrade mislukt vanwege onvoldoende piekknooppunten.
maxSurge=0, maxUnavailable=5 N/A Vijf bestaande knooppunten worden leeggezogen voor de upgrade.

Opmerking

Voordat u een upgrade uitvoert, controleert u op wijzigingen die fouten veroorzaken in de API en bekijkt u 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 PDB's (bijvoorbeeld maxUnavailable=0).
  • Quotum: Bevestigt voldoende quotum voor piekknooppunten.
  • Subnet: Controleert voldoende IP-adressen.
  • Certificaten/service-principals: Detecteert verlopen inloggegevens.
  • Controle op resourcevergrendelingen voor de resourcegroep van het beheerde cluster: Controleert of er resourcevergrendelingen zijn toegepast op de resourcegroep van het beheerde cluster.

Deze controles zijn van toepassing op AKS. In AKS Automatic worden ze geïntegreerd in het beheerde upgradepad; in AKS Standard maken ze deel uit van uw operationele werkstroom.

Algemene upgradescenario's en aanbevelingen

Scenario 1: Capaciteitsbeperkingen

Als uw cluster wordt beperkt door de productlaag of regionale capaciteit, kunnen upgrades mislukken wanneer piekknooppunten niet kunnen worden ingericht. Deze situatie is gebruikelijk bij gespecialiseerde productlagen (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.

Automatische richtlijnen voor AKS

  • Houd geplande onderhoudsvensters in stand.
  • Valideer het abonnementsquotum en de hoofdruimte van het subnet vóór de verwachte upgradeperioden.
  • Houd het schalen van workloads en onderbrekingsbudgetten afgestemd op onderhoudsvensters.

Richtlijnen voor AKS Standard

Scenario 2: Knooppuntleegmaakfouten en PDBs

Voor upgrades moeten knooppunten worden leeggemaakt (pods worden ontruimd). Afvoerprocessen kunnen mislukken wanneer pods langzaam worden beëindigd of strikte Pod-onderbrekingsbudgetten (PDBs) het verwijderen van pods blokkeren.

Voorbeeldfout:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... Cannot evict pod as it would violate the pod's disruption budget.

Automatische richtlijnen voor AKS

  • PDB- en replicastrategie behandelen als primaire betrouwbaarheidscontroles.
  • Valideer disruptiebudgetten in de stagingomgeving vóór de uitrol naar productie.
  • Houd kritieke workloads geconfigureerd voor een geslaagde verwijdering.

Richtlijnen voor AKS Standard

Optie 1: Upgrade forceren, PDB-beperkingen omzeilen

Waarschuwing

Geforceerde upgrade omzeilt PDB-beperkingen (Pod Disruption Budget) en kan serviceonderbreking veroorzaken door alle pods tegelijk leeg te maken. Voordat u deze optie gebruikt, probeert u eerst onjuiste PDB-configuraties op te lossen (controleer de PDB minAvailable/maxUnavailable-instellingen, zorg ervoor dat er voldoende podreplica's zijn, controleer of PDBs niet alle verwijderingen blokkeren).

Gebruik alleen geforceerde upgrade wanneer PDBs kritieke upgrades voorkomen en niet kunnen worden opgelost. Deze actie overschrijft PDB-beveiligingen en kan ertoe leiden dat de volledige service niet beschikbaar is tijdens de upgrade.

Vereisten: Azure CLI 2.79.0+ of AKS API versie 2025-09-01+

az aks upgrade \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --kubernetes-version $KUBERNETES_VERSION \
  --enable-force-upgrade \
  --upgrade-override-until yyyy-mm-ddT13:00:00Z

Opmerking

  • De upgrade-override-until parameter definieert wanneer de validatie-bypass eindigt (moet een toekomstige datum/tijd zijn)
  • Als dit niet is opgegeven, wordt het venster standaard ingesteld op drie dagen vanaf de huidige tijd
  • De Z geeft UTC/GMT-tijdzone aan

Waarschuwing

Wanneer geforceerde upgrade is ingeschakeld, heeft deze voorrang op alle andere drainconfiguraties. De instellingen voor het gedrag van niet-drainbare knooppunten (optie 2) worden niet toegepast wanneer een geforceerde upgrade actief is.

Optie 2: Knooppunten die niet kunnen worden leeggemaakt verwerken met inachtneming van PDB's

Gebruik deze conservatieve benadering om PDBs te respecteren en upgradefouten te voorkomen.

Configureren van gedrag van niet te drainen knooppunten:

az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 30

Gedragsopties:

  • Gepland (standaard): Verwijdert het geblokkeerde knooppunt en schaalt een vervangend knooppunt op.
  • Cordon (aanbevolen): Cordons-knooppunt en labelt het als kubernetes.azure.com/upgrade-status=Quarantined.

Maximaal aantal geblokkeerde knooppunten (preview):

  • Hiermee specificeert u hoeveel knooppunten die niet kunnen worden gedraineerd, worden getolereerd.
  • Moet undrainable-node-behavior worden ingesteld
  • Wordt standaard ingesteld op de waarde maxSurge (meestal 10%) als deze niet is opgegeven.
  • Als de berekende waarde net als de maximale piek hoger is dan het aantal knooppunten dat in de huidige bewerking moet worden bijgewerkt, wordt in plaats daarvan het aantal knooppunten gebruikt dat nog moet worden bijgewerkt
Vereisten voor maximaal geblokkeerde knooppunten

De Azure CLI-extensie aks-preview versie 18.0.0b9 of hoger is vereist voor het gebruik van de functie maximaal geblokkeerde knooppunten.

# Install or update the aks-preview extension
az extension add --name aks-preview
az extension update --name aks-preview
Voorbeeldconfiguratie met maximaal geblokkeerde knooppunten
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
Optie 3: Automatisch PDB-beheer (preview)

Gebruik de automatische PDB-beheerextensie om PDB-geblokkeerde afvoeren proactief op te lossen zonder PDB-beveiligingen te omzeilen of handmatig opschonen van in quarantaine geplaatste knooppunten te vereisen. Automatisch PDB-beheer detecteert wanneer een PDB uitzetting op een gecordond knooppunt blokkeert en schaalt de replica's van de deployment tijdelijk op, zodat aan het disruptiebudget wordt voldaan. Nadat de afvoer is voltooid, worden replica's terug geschaald naar het oorspronkelijke aantal.

Automatisch PDB-beheer kan ook automatisch PDB’s maken voor deployments die er nog geen hebben, waardoor uw workloads beschermd blijven tijdens drain-bewerkingen bij upgrades. Zie Podverstoringsbudgetten automatisch beheren tijdens AKS-upgrades voor installatie- en configuratiedetails.

Aanbevelingen om afvoerfouten te voorkomen
  • Instellen maxUnavailable in PDBs om ten minste één pod-verwijdering toe te staan
  • Podreplica's verhogen om te voldoen aan de vereisten van het storingbudget
  • Breid de time-out van de afvoer uit als workloads meer tijd nodig hebben. (De standaardwaarde is 30 minuten.)
  • Gebruik automatisch PDB-beheer om het maken en schalen van replica's van PDB te automatiseren tijdens drainbewerkingen.
  • Test PDBs in de stagingomgeving, bewaak upgrade-events en gebruik blue-green deployments voor kritieke workloads. Zie Blauwgroene implementatie van AKS-clusters voor meer informatie.
Onleegbare 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
    
Oninbare 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> kubernetes.azure.com/upgrade-status-
    
  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 beschreven in az aks. 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 volgende voorbeeld 2 is 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

Conservatieve instellingen of problemen op knooppuntniveau kunnen upgrades vertragen, 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).

Automatische richtlijnen voor AKS

  • Houd onderhoudsschema's actueel.
  • Controleer de status van de upgradegebeurtenis en de gereedheid van workloads.
  • Los problemen met het blokkeren van PDB of capaciteit snel op om langdurige vertraging te voorkomen.

Richtlijnen voor AKS Standard

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

Scenario 4: IP-uitputting

Piekknooppunten vereisen meer IP-adressen. Als het subnet bijna zijn capaciteit bereikt, kan het toewijzen van knooppunten mislukken (bijvoorbeeld Error: SubnetIsFull). Dit scenario is gebruikelijk met Azure Container Networking Interface, hoog maxPods of een groot aantal knooppunten.

Automatische richtlijnen voor AKS

  • Valideer subnet- en capaciteitsplannen vóór productie-uitbreiding.
  • Netwerkgebruik bewaken als onderdeel van routinebewerkingen.

Richtlijnen voor AKS Standard

  • Zorg ervoor dat uw subnet voldoende IP-adressen heeft voor alle knooppunten, piekknooppunten en pods. De formule is 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.

Veelgestelde vragen

Moet ik AKS Automatic of AKS Standard gebruiken voor productie-upgrades?

Gebruik AKS Automatic voor de meeste productieworkloads. Het is ontworpen als de productierijpe standaardkeuze, met een beheerd upgradeproces en ingebouwde waarborgen.

Gebruik AKS Standard wanneer u geavanceerde handmatige controle nodig hebt over upgradevolgorde, infrastructuurkeuzen of bewerkingen van knooppuntgroepen.

Kan ik opensource-hulpprogramma's gebruiken voor validatie?

Ja. Veel opensource-hulpprogramma's kunnen goed worden geïntegreerd met AKS-upgradeprocessen:

  • Trivy: Beveiligingsscans voor containerinstallatiekopieën en Kubernetes-configuraties.
  • Sonobuoy: Kubernetes conformance testen van en clustervalidatie.
  • kube-bench: Beveiligingsbenchmarkcontroles volgens de normen van het Centrum voor Internetbeveiliging.
  • Polaris: Validatie van aanbevolen procedures voor Kubernetes.
  • kubectl-neat: Kubernetes-manifesten opschonen voor validatie.

Hoe valideer ik API-compatibiliteit voordat ik een upgrade uitvoert?

Verouderingscontroles uitvoeren met behulp van hulpprogramma's zoals kubent:

# Install and run API deprecation scanner
kubectl apply -f https://github.com/doitintl/kube-no-trouble/releases/latest/download/knt-full.yaml

# Check for deprecated APIs in your cluster
kubectl run knt --image=doitintl/knt:latest --rm -it --restart=Never -- \
  -c /kubeconfig -o json > api-deprecation-report.json

# Review findings
cat api-deprecation-report.json | jq '.[] | select(.deprecated==true)'

Wat maakt AKS-upgrades anders dan andere Kubernetes-platforms?

AKS biedt verschillende unieke voordelen:

  • Beheerde operationele paden in AKS Automatisch voor lagere upgrade-overhead.
  • Systeemeigen Azure-integratie met Azure Traffic Manager, Azure Load Balancer en netwerken.
  • Azure Kubernetes Fleet Manager voor gecoördineerde upgrades voor meerdere clusters.
  • Automatische patchen van knooppunt afbeeldingen zonder handmatig knooppuntbeheer.
  • Ingebouwde validatie voor quota, netwerken en referenties.
  • Azure-ondersteuning voor problemen met betrekking tot upgrades.

Kies uw upgradepad

Dit artikel heeft u een technische basis gegeven. Selecteer nu uw pad op basis van scenario's.

Klaar om uit te voeren?

Als u... Ga vervolgens naar...
Productieworkload en geen speciale aanpassingsbeperkingen Een automatisch AKS-cluster maken
Productieomgeving met geavanceerde aangepaste upgradebehoeften Strategieën voor productie-upgrades
Databases of stateful apps Stateful workloadpatronen
Meerdere omgevingen Hub voor upgradescenario's
Eenvoudig AKS Standard-cluster Een AKS-cluster upgraden

Nog steeds beslissen?

Gebruik de hub voor upgradescenario's voor een begeleide beslissingsstructuur die rekening houdt met uw:

  • Tolerantie voor stilstandtijd
  • Omgevingscomplexiteit
  • Risicoprofiel
  • Tijdlijnbeperkingen

Definitieve aanbevelingen

  • Gebruik AKS Automatic voor de meeste productieworkloads.
  • 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 workload 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.