Hoe upgrades van Azure Kubernetes Service (AKS)-clusters werken

Azure Kubernetes Service (AKS) voert rolling upgrades uit om onderbreking van actieve workloads te minimaliseren.

Voor de meeste productieworkloads is AKS Automatic de aanbevolen standaardinstelling, indien van toepassing. AKS Automatic omvat productierijpe standaardinstellingen voor upgradebewerkingen, zoals automatische upgrades van Kubernetes-versies, automatische updates van installatiekopieën van het besturingssysteem (OS) van knooppunten, beheerde bewerkingen voor systeemknooppunten en ingebouwde waarborgen die de handmatige inspanning verminderen. Zie Inleiding tot AKS Automatic voor meer informatie.

In dit artikel wordt uitgelegd wat de AKS-upgrademechanica is en waar AKS Automatic en AKS Standard verschillen.

Vereiste voorwaarden

Upgrademodel: AKS Automatic en AKS Standard

De AKS Automatic- en AKS Standard-clustermodi maken gebruik van dezelfde basisprincipes van Kubernetes-upgrades, maar ze verschillen in standaardinstellingen en operationeel eigendom.

Probleem met upgraden AKS Automatisch AKS Standard
Productiepositie Aanbevolen standaard voor de meeste productieworkloads, indien van toepassing Flexibel model met meer handmatige configuratie standaard
Kubernetes-minorversie-upgrades Vooraf geconfigureerd kanaal voor automatische upgrade Standaard handmatig, met optioneel automatisch kanaal
Upgrades van installatiekopieën van knooppuntbesturingssystemen Vooraf geconfigureerd automatisch kanaal voor OS-images van de node Standaard handmatig, met optioneel automatisch kanaal
Bewerkingen van systeemknooppuntgroepen Beheerd door AKS Beheerd door de klant
Geplande onderhoudsvensters Standaard beschikbaar Optionele configuratie
Beheeropties voor workloadverstoringen Eigendom van de klant, inclusief replicastrategie, gereedheidsgedrag en onderbrekingsbeleid Eigendom van de klant, inclusief replicastrategie, gereedheidsgedrag en onderbrekingsbeleid

Note

AKS Automatic vereenvoudigt platformbewerkingen, maar gedeelde verantwoordelijkheid is nog steeds van toepassing. Het beschikbaarheidsontwerp en het uitzettingsbeleid op workloadniveau blijven de verantwoordelijkheid van de klant.

Werking van rolling-upgrades in AKS

AKS werkt knooppuntgroepen bij met behulp van een rollend patroon dat capaciteit behoudt terwijl knooppunten worden vervangen of opnieuw worden hersteld. Dit gedrag is hetzelfde voor alle AKS-clustermodi.

In grote lijnen, AKS:

  1. Voegt tijdelijke piekcapaciteit toe op basis van upgrade-instellingen.
  2. Cordons en leegmaken van knooppunten om workloads te verplaatsen.
  3. Maakt de knooppunten opnieuw aan met de doelversie of vervangt ze ermee.
  4. Verwijdert de tijdelijke piekcapaciteit na afronding.

Voorbeeld van rolling upgrade

In dit voorbeeld ziet u hoe u een cluster met twee knooppunten bijwerkt van Kubernetes 1.30 naar 1.31 en is maxSurge ingesteld op 1.

Stap 1: Eerste installatie

Het cluster begint met twee knooppunten waarop versie 1.30 wordt uitgevoerd, waarbij elk toepassingspods host.

Diagram dat de initiële clusterconfiguratie toont met twee knooppunten waarop versie 1.30 wordt uitgevoerd, die elk applicatiepods hosten, en een nieuw aangemaakt surge-knooppunt.

  • Knooppunt 1: Pod A, Pod B
  • Knooppunt 2: Pod C, Pod D
  • Piekknooppunt: Leeg (met uitzondering van DaemonSets en nieuwe pods)

Stap 2: Cordon en afvoer eerste knooppunt

AKS cordoniert Node 1 om te voorkomen dat nieuwe pods worden gepland en vervolgens bestaande pods draineren.

Diagram met knooppunt 1 dat wordt vastgezet en leeggemaakt, waarbij pods worden verwijderd en vervangen op andere beschikbare knooppunten.

  • Pod A → verwijderd en vervangen op piekknooppunt
  • Pod B → verwijderd en vervangen op Node 2

Stap 3: Eerste knooppunt upgraden

Knooppunt 1 wordt hergeïnstalleerd met Kubernetes versie 1.31, terwijl pods op andere knooppunten blijven draaien.

Diagram waarop te zien is dat knooppunt 1 opnieuw is ingericht naar versie 1.31, terwijl applicatiepods blijven draaien op knooppunt 2 en het surgeknooppunt.

  • Knooppunt 1: Bijgewerkt naar v1.31
  • Knooppunt 2: Pod B, Pod C, Pod D
  • Piekknooppunt: Pod A

Stap 4: Tweede knooppunt afzetten en leeg laten lopen

AKS herhaalt het proces voor Node 2, pods worden verwijderd en de scheduler herdistribueert deze naar de juiste beschikbare knooppunten.

Diagram waarin te zien is dat knooppunt 2 wordt afgeschermd en leeggehaald, waarbij pods worden verwijderd en opnieuw geplaatst op het bijgewerkte knooppunt 1 en het surgeknooppunt.

  • Pod C, B → verwijderd en vervangen op Node 1
  • Pod D → verwijderd en vervangen op piekknooppunt
  • Knooppunt 2: Afgegrensd en opnieuw geïmageerd naar v1.31

Stap 5: Piekknooppunt verwijderen

Nadat alle permanente knooppunten zijn bijgewerkt, wordt het piekknooppunt vastgezet, leeggezogen en verwijderd.

Diagram waarin het piekknooppunt wordt leeggemaakt en verwijderd, waarbij pods worden verwijderd en vervangen op de bijgewerkte permanente knooppunten.

  • Pod A → verwijderd en vervangen op Node 1
  • Pod D → verwijderd en vervangen op Node 2
  • Piekknooppunt: verwijderd

Uiteindelijke status

Op alle knooppunten wordt nu Kubernetes versie 1.31 uitgevoerd met pods die zijn gepland in het cluster.

  • Node 1 (v1.31): Pod A, Pod C
  • Node 2 (v1.31): Pod B, Pod D

Restrictief gedrag van Pod Disruption Budget (PDB)

Als een beperkende PDB verwijdering blokkeert, kan het leegmaken van knooppunten worden vertraagd of voorkomen. AKS kan het Cordon oninbare knooppuntgedrag gebruiken om andere in aanmerking komende knooppunten te blijven upgraden, afhankelijk van het geconfigureerde gedrag. Geblokkeerde knooppunten blijven mogelijk op een oudere versie staan totdat de blokkeringsvoorwaarde is opgelost.

Beperkend PDB-voorbeeld

In dit voorbeeld wordt getoond hoe u een cluster met twee knooppunten bijwerkt van Kubernetes 1.30 naar 1.31, waarbij maxSurge is ingesteld op 2 en een PDB de drainbewerking van het eerste knooppunt blokkeert.

Stap 1: Eerste installatie met beperkende PDB

Het cluster begint met twee knooppunten met versie 1.30, met een PDB die Pod A beschermt tegen verwijdering.

Diagram waarop de oorspronkelijke cluster met twee knooppunten, een Surge Node en een Pod Disruption Budget te zien zijn dat pod A tegen uitzetting beschermt.

  • Knooppunt 1: Pod A (beveiligd door PDB), Pod B
  • Knooppunt 2: Pod C, Pod D
  • Piekknooppunten: nieuw gemaakte 2 knooppunten
  • PDB: Voorkomt verwijderen van pod A

Stap 2: Het eerste knooppunt leegmaken (geblokkeerd)

AKS cordons Node 1, maar kan Pod A niet leegmaken vanwege PDB-beperkingen.

Diagram waarin knooppunt 1 is afgeschermd, maar drainen wordt geblokkeerd door een Pod Disruption Budget, waarbij Pod A vastzit en Pod B is verplaatst naar het Surge-knooppunt.

  • Knooppunt 1: Afgezet en gemarkeerd als in quarantaine (Pod A vastgelopen)
  • Pod B → verwijderd en vervangen op piekknooppunt 1, terwijl piekknooppunt 2 tijdelijk niet wordt gebruikt
  • Status: Upgrade van knooppunt 1 geblokkeerd

Stap 3: Doorgaan naar het tweede knooppunt

Met knooppunt 1 in quarantaine blijft AKS knooppunt 2 bijwerken.

Diagram waarin knooppunt 1 in quarantaine blijft, terwijl knooppunt 2 succesvol is afgeschermd en leeggemaakt, waarbij pods naar het surgeknooppunt zijn verplaatst.

  • Knooppunt 1: blijft in quarantaine (v1.30)
  • Knooppunt 2: Afgesloten en afgetapt
  • Pod C → verwijderd en vervangen op piekknooppunt 2
  • Pod D → verwijderd en vervangen op piekknooppunt 2

Stap 4: tweede knooppunt upgraden

Knooppunt 2 is met succes opnieuw geïnstalleerd naar Kubernetes versie 1.31.

Diagram waarin wordt weergegeven dat Node 2 is geüpgraded naar versie 1.31, terwijl Node 1 in quarantaine blijft met Pod A.

  • Knooppunt 1: Nog steeds in quarantaine geplaatst (v1.30) met Pod A
  • Knooppunt 2: bijgewerkt naar v1.31
  • Piekknooppunt 1: Pod B
  • Piekknooppunt 2: Pod C, Pod D

Stap 5: Het ene piekknooppunt wordt permanent vervangen wanneer een ander knooppunt wordt verwijderd

Omdat knooppunt 1 in quarantaine blijft, wordt Surge Node 1 de permanente vervanger die op v1.31 draait en wordt Surge Node 2 verwijderd.

Diagram waarin te zien is dat de Surge Node de permanente vervanging wordt die versie 1.31 uitvoert, terwijl Node 1 in quarantaine blijft.

  • Knooppunt 1: In quarantaine (v1.30): handmatige interventie vereist
  • Pod C, Pod D → verwijderd uit piekknooppunt 2 en vervangen op knooppunt 2
  • Piekknooppunt 1 (v1.31): Pod B (nu permanent)
  • Piekknooppunt 2 (v1.31): verwijderd

Uiteindelijke status

De upgrade wordt voltooid met één in quarantaine geplaatst knooppunt waarvoor handmatige tussenkomst is vereist.

  • Knooppunt 1: In quarantaine geplaatst (v1.30) met Pod A - De klant moet handmatig oplossen (zie oninbare knooppunten oplossen)
  • Node 2 (v1.31): normaal wordt uitgevoerd
  • Voormalig piekknooppunt (v1.31): nu permanente vervanging

Belangrijk

Het in quarantaine geplaatste knooppunt (Node 1) blijft de verantwoordelijkheid van de klant om mee om te gaan. U moet een van de volgende dingen doen:

  • Pas de PDB aan om verwijdering van Pod A toe te staan.
  • Verwijder Pod A handmatig.
  • Verwijder het knooppunt en maak het opnieuw nadat de blokkeringsvoorwaarde is opgelost.

Belangrijke overwegingen voor door PDB geblokkeerde upgrades

  • Oninbaar gedrag van knooppunten: ingesteld op Cordon voor de knooppuntgroep om dit quarantainegedrag in te schakelen.
  • Verantwoordelijkheid van de klant: In quarantaine geplaatste knooppunten vereisen handmatig ingrijpen om het probleem op te lossen.
  • Clustercapaciteit: het piekknooppunt wordt permanent, mogelijk van invloed op de planning van clustercapaciteit.
  • Bewaking: houd in quarantaine geplaatste knooppunten bij via Azure Monitor of kubectl om een tijdige oplossing te garanderen.

Tip

Om het quarantainescenario volledig te voorkomen, kunt u automatisch PDB-beheer gebruiken om implementatiereplica's automatisch op te schalen, zodat aan PDB-beperkingen wordt voldaan voordat de afvoer begint. Hierdoor kan verwijdering zonder blokkering worden voortgezet, waardoor handmatige quarantaineoplossing niet meer nodig is.

Blue-Green knooppuntgroepupgrades (handmatig beheer)

Blue-Green upgrades bieden een meer gecontroleerde upgradebenadering door handmatig een volledige set nieuwe knooppuntgroepen te maken voordat workloads worden gemigreerd. Deze handmatige benadering biedt u volledige controle over het upgradeproces en de timing.

Zie Blue-Green-upgrades van knooppuntpools in AKS voor meer informatie.

Wanneer gebruikt u Blue-Green upgrades

Handmatige Blue-Green knooppuntpoolupgrades zijn een geavanceerde strategie voor gespecialiseerde vereisten, zoals expliciete migratiecontrolepunten, aangepaste validatiepoorten of strak beheerde cutovers.

Gebruik handmatige Blue-Green wanneer u het volgende nodig hebt:

  • Operatorgestuurde migratiefasen.
  • Aangepaste validatie- en acceptatiecriteria voordat ze worden doorgevoerd.
  • Expliciete terugdraaiprocedure gekoppeld aan interne runbooks.

Voor de meeste productieworkloads, indien van toepassing, is het automatische standaardupgradegedrag van AKS het voorkeursstartpunt en is handmatige Blue-Green doorgaans gereserveerd voor uitzonderlijke gevallen.

Belangrijke concepten

  • Blauwe knooppuntgroep: uw bestaande knooppuntgroep waarop de huidige Kubernetes-versie wordt uitgevoerd.
  • Groene knooppuntgroep: nieuwe knooppuntgroep die u maakt met de kubernetes-doelversie.
  • Handmatig beheer: u beheert alle aspecten van het migratieproces.
  • Validatiecontrolepunten: u bepaalt wanneer u wilt doorgaan, onderbreken of terugdraaien.

Voordelen van Blue-Green upgrades

  • Volledig beheer: u bepaalt precies wanneer elke stap plaatsvindt.
  • Aangepaste validatie: Implementeer uw eigen validatiecriteria en -timing.
  • Geleidelijke migratie: werkbelastingen verplaatsen naar uw voorkeurstempo.
  • Eenvoudig terugdraaien: oorspronkelijke knooppunten blijven beschikbaar totdat u ze verwijdert.

Belangrijke overwegingen voor Blue-Green upgrades

  • Handmatige inspanning: vereist actief beheer tijdens het proces.
  • Quotumvereisten: vereist 2x de knooppuntcapaciteit tijdens de upgrade.
  • Planning: documenteer uw validatiecriteria en terugdraaiprocedures.

Voorbeeld van handmatig Blue-Green upgradeproces

In dit voorbeeld ziet u hoe u handmatig een cluster met twee knooppunten bijwerkt van Kubernetes 1.30 naar 1.31 met behulp van Blue-Green-implementatie.

Stap 1: Groene knooppuntgroep maken

U begint met het handmatig maken van een nieuwe knooppuntgroep met de kubernetes-doelversie naast uw bestaande knooppuntgroep.

Diagram met Blue-Green eerste installatie met blauwe knooppuntgroep met versie 1.30 en nieuw gemaakte Groene knooppuntgroep met versie 1.31.

  • Blauwe knooppuntgroep (v1.30): Pod A, Pod B, Pod C, Pod D (bestaand)
  • Groene knooppuntgroep (v1.31): Leeg (handmatig gemaakt door u)
  • Uw actie: az aks nodepool add met nieuwe Kubernetes-versie

Stap 2: Knopen blauw maken en handmatig afzetten

Cordon de blauwe knooppunten om te voorkomen dat nieuwe pods worden gepland terwijl bestaande pods actief blijven.

  • Uw actie: kubectl cordon op elk blauw knooppunt
  • Blauwe knooppunten: Geïsoleerd, geen nieuwe pods gepland
  • Groene knooppunten: gereed voor het ontvangen van workloads

Stap 3: Blauwe knooppunten handmatig leegmaken (gecontroleerd tempo)

U bepaalt het migratietempo door knooppunten één voor één of in batches handmatig leeg te maken.

Diagram dat laat zien hoe het blauwe knooppunt wordt geleegd, waarbij pods worden uitgezet en vervangen op de groene knooppuntgroep, en hoe het tweede blauwe knooppunt wordt geleegd, waarbij de resterende pods naar de groene knooppuntgroep worden gemigreerd.

  • Uw actie: kubectl drain op geselecteerde blauwe knooppunten
  • Migratie van pods: Pods worden automatisch opnieuw gepland naar groene knooppunten
  • Validatie: Verifieer workloads op groene knooppunten voordat u doorgaat

Stap 4: Valideren en beslissen

Na het migreren van workloads valideert u de prestaties van toepassingen op groene knooppunten.

Diagram waarin de validatiefase wordt weergegeven met alle workloads die worden uitgevoerd in een groene knooppuntgroep terwijl de blauwe knooppuntgroep beschikbaar blijft voor terugdraaien.

Tijdens deze fase kunt u het volgende doen:

  • Controleren: Metrische gegevens en logboeken van toepassingen controleren
  • Test: Validatietests uitvoeren op groene knooppuntgroep
  • Beslissen: Committeren aan groen of terugdraaien naar blauw

Stap 5: Doorvoeren of terugdraaien

Op basis van uw validatie voltooit u de upgrade handmatig of rolt u terug.

Optie A - Toepassen (succes):

Diagram met geslaagde doorvoer, waarbij de blauwe knooppuntgroep is verwijderd en de groene knooppuntgroep de primaire knooppuntgroep wordt.

  • Uw actie: Blauwe knooppuntgroep verwijderen met behulp van az aks nodepool delete
  • Resultaat: Groene knooppuntgroep wordt primair

Optie B - Terugdraaien (gedetecteerde problemen):

Diagram dat een terugdraaiing toont waarbij workloads terugkeren naar de Blue-knooppuntgroep en de Green-knooppuntgroep wordt verwijderd.

  • Uw actie: Blauwe knooppunten ongedaan maken met behulp van kubectl uncordon, groene knooppunten leegmaken met behulp van kubectl drain, en groene knooppuntgroep verwijderen met behulp van az aks nodepool delete
  • Resultaat: Workloads worden geretourneerd naar blauwe knooppunten

Productieoverwegingen voor upgradeplanning

  • Surge (maxSurge)-configuratie: Hiermee wordt het aantal surgeknooppunten bepaald dat tijdens upgrades wordt aangemaakt. Hogere waarden versnellen upgrades, maar verbruiken meer resources.
  • Budgetten voor podonderbrekingen (PDBs):configureer PDBs om de beschikbaarheid van toepassingen tijdens het upgradeproces te garanderen.
  • Upgrades van knooppuntgroepen: elke knooppuntgroep wordt onafhankelijk bijgewerkt. Plan uw upgradestrategie dienovereenkomstig.
  • Capaciteit en quotum: valideer tijdelijke en gestage capaciteitsvereisten voordat upgradevensters worden uitgevoerd.
  • Bewaking en waarschuwingen: bewaking en waarschuwingen instellen voordat de upgrade wordt gestart.

In AKS Automatic worden verschillende upgradeopties op platformniveau vooraf geconfigureerd voor productiegereedheid. In AKS Standard maken teams deze keuzes doorgaans expliciet.

Verwante onderwerpen

  • Last updated on