Upgradeopties voor AKS-clusters (Azure Kubernetes Service)
In dit artikel worden de verschillende upgradeopties voor AKS-clusters behandeld. Zie Een AKS-cluster upgraden om een eenvoudige Kubernetes-versie-upgrade uit te voeren.
Zie Een knooppuntgroep upgraden in AKS voor AKS-clusters die gebruikmaken van meerdere knooppuntgroepen of Windows Server-knooppunten. Als u een specifieke knooppuntgroep wilt upgraden zonder een Upgrade van een Kubernetes-cluster uit te voeren, raadpleegt u Een specifieke knooppuntgroep upgraden.
Handmatige upgrades uitvoeren
U kunt handmatige upgrades uitvoeren om te bepalen wanneer uw cluster wordt bijgewerkt naar een nieuwe Kubernetes-versie. Handmatige upgrades zijn handig wanneer u een nieuwe Kubernetes-versie wilt testen voordat u uw productiecluster bijwerkt. U kunt ook handmatige upgrades gebruiken om uw cluster te upgraden naar een specifieke Kubernetes-versie die niet de meest recente beschikbare versie is.
Als u handmatige upgrades wilt uitvoeren, raadpleegt u de volgende artikelen:
- Een AKS-cluster upgraden
- De knooppuntinstallatiekopieën upgraden
- Upgrade van knooppuntpieken aanpassen
- Updates van het besturingssysteem van het procesknooppunt
- Meerdere AKS-clusters upgraden via Azure Kubernetes Fleet Manager
Automatische upgrades configureren
U kunt automatische upgrades configureren om uw cluster automatisch te upgraden naar de meest recente beschikbare Kubernetes-versie. Automatische upgrades zijn handig als u ervoor wilt zorgen dat uw cluster altijd de meest recente Kubernetes-versie uitvoert. U kunt ook automatische upgrades gebruiken om ervoor te zorgen dat uw cluster altijd een ondersteunde Kubernetes-versie uitvoert.
Zie de volgende artikelen voor het configureren van automatische upgrades:
- Automatisch een upgrade uitvoeren van een AKS-cluster
- Gepland onderhoud gebruiken om upgrades voor uw AKS-cluster te plannen en beheren
- AKS-clusterupgrades automatisch stoppen bij api-belangrijke wijzigingen (preview)
- Installatiekopieën van AKS-clusterknooppunten automatisch upgraden
- Beveiligingsupdates automatisch toepassen op AKS-knooppunten met behulp van GitHub Actions
Speciale overwegingen voor knooppuntgroepen die meerdere beschikbaarheidszones omvatten
AKS maakt gebruik van best effort zone balancing in knooppuntgroepen. Tijdens een upgrade-piek zijn de zones voor de piekknooppunten in virtuele-machineschaalsets van tevoren onbekend, wat tijdelijk een ongebalanceerde zoneconfiguratie kan veroorzaken tijdens een upgrade. AKS verwijdert echter piekknooppunten zodra de upgrade is voltooid en behoudt de oorspronkelijke zonebalans. Als u uw zones gelijkmatig wilt houden tijdens upgrades, kunt u de piek verhogen naar een veelvoud van drie knooppunten en worden uw knooppunten verdeeld over beschikbaarheidszones met zoneverdeling met best-effort zoneverdeling. Met de best effort zone balance probeert de schaalset in en uit te schalen terwijl de balans behouden blijft. Als dit om een of andere reden echter niet mogelijk is (bijvoorbeeld als één zone uitvalt, kan de schaalset geen nieuwe VIRTUELE machine in die zone maken), kan de schaalset tijdelijk onevenwichtig in- of uitschalen.
Permanente volumeclaims (PVC's) die worden ondersteund door lokaal redundante Azure-opslagschijven (LRS) zijn gebonden aan een bepaalde zone en kunnen mogelijk niet direct worden hersteld als het piekknooppunt niet overeenkomt met de zone van het PVC. Als de zones niet overeenkomen, kan dit downtime veroorzaken voor uw toepassing wanneer de upgradebewerking knooppunten blijft leegmaken, maar de TV's zijn gebonden aan een zone. Als u dit geval wilt afhandelen en hoge beschikbaarheid wilt behouden, configureert u een budget voor podonderbreking voor uw toepassing, zodat Kubernetes uw beschikbaarheidsvereisten tijdens de afvoerbewerking kan respecteren.
Optimaliseren voor oningestoord knooppuntgedrag (preview)
U kunt het gedrag van het upgradeproces configureren voor leegloopfouten. Het standaardgedrag van de upgrade is Schedule
, dat bestaat uit een storing bij het leegmaken van knooppunten, waardoor de upgradebewerking mislukt, waardoor de niet-ingesleten knooppunten in een schedulbare status blijven. U kunt ook het Cordon
gedrag selecteren, waarmee knooppunten die niet kunnen worden verwijderd, worden overgeslagen door ze in quarantaine te plaatsen, ze kubernetes.azure.com/upgrade-status:Quarantined
te labelen en de resterende knooppunten te upgraden. Dit gedrag zorgt ervoor dat alle knooppunten worden bijgewerkt of in quarantaine worden geplaatst. Met deze aanpak kunt u afvoerfouten oplossen en de in quarantaine geplaatste knooppunten probleemloos beheren.
Hoe kan ik het nieuwe Cordon-gedrag instellen?
Gebruik cli preview en installeer aks-preview
extensie 9.0.0b3 of hoger.
U kunt de volgende opdrachten gebruiken om de extensie bij te werken of te installeren aks-preview
:
az extension update --name aks-preview
az extension add --name aks-preview
Werk het gedrag van de knooppuntgroep bij naar Cordon
:
az aks nodepool update --cluster-name $CLUSTER_NAME --name $NODE_POOL_NAME --resource-group $RESOURCE_GROUP --max-surge 1 --undrainable-node-behavior Cordon
In de volgende voorbeelduitvoer ziet u het onverwerkbare gedrag van het knooppunt bijgewerkt:
"upgradeSettings": {
"drainTimeoutInMinutes": null,
"maxSurge": "1",
"nodeSoakDurationInMinutes": null,
"undrainableNodeBehavior": "Cordon"
}
Controleer het label op geblokkeerde knooppunten. Wanneer er een storing op het knooppunt is opgetreden bij de upgrade met behulp van de volgende opdracht:
kubectl get nodes --show-labels=true
De geblokkeerde knooppunten zijn niet gepland voor pods en gemarkeerd met het label "kubernetes.azure.com/upgrade-status: Quarantined"
. Het maximum aantal knooppunten dat kan worden geblokkeerd, mag niet meer zijn dan de Max-Surge
waarde.
Hoe kan ik de geblokkeerde knooppunten verwijderen?
Los eerst het probleem op dat de afvoer veroorzaakt. In het volgende voorbeeld wordt de verantwoordelijke PDB verwijderd:
kubectl delete pdb nginx-pdb
poddisruptionbudget.policy "nginx-pdb" deleted.
Verwijder vervolgens het geblokkeerde knooppunt met behulp van de az aks nodepool delete-machines
opdracht. Deze opdracht is handig als u de footprint van de knooppuntgroep wilt verminderen door knooppunten te verwijderen die in oudere versies achterblijven.
az aks nodepool delete-machines --cluster-name MyCluster --machine-names aks-nodepool1-test123-vmss000000 --name nodepool1 --resource-group TestRG
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.
Voorbeeldopdracht:
az aks update --resource-group TestRG --name MyCluster
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 2
voorbeeld is het totale aantal bijgewerkte knooppunten.
az aks nodepool scale --resource-group TestRG --cluster-name MyCluster --name nodepool1 --node-count 2
Upgrades optimaliseren om de prestaties te verbeteren en onderbrekingen te minimaliseren
De combinatie van gepland onderhoudvenster, maximale piek, budget voor podonderbreking, time-out voor knooppuntafvoer en knooppuntweektijd kan de kans op knooppuntupgrades aanzienlijk verhogen aan het einde van het onderhoudsvenster, terwijl ook onderbrekingen worden geminimaliseerd.
- Met het venster Gepland onderhoud kunnen serviceteams automatische upgrade plannen tijdens een vooraf gedefinieerd venster, meestal een periode met weinig verkeer, om de impact van de werkbelasting te minimaliseren. U wordt aangeraden een vensterduur van ten minste vier uur te gebruiken.
- Maximale piek in de knooppuntgroep maakt het mogelijk extra quotum aan te vragen tijdens het upgradeproces en beperkt het aantal knooppunten dat voor de upgrade tegelijk is geselecteerd. Een hogere maximale piek resulteert in een sneller upgradeproces. Het is niet raadzaam om deze op 100% in te stellen, omdat alle knooppunten tegelijkertijd worden bijgewerkt, wat kan leiden tot onderbrekingen van actieve toepassingen. U wordt aangeraden een maximaal piekquotum van 33% te gebruiken voor productieknooppuntgroepen.
- Het budget voor podonderbreking is ingesteld voor servicetoepassingen en beperkt het aantal pods dat kan worden uitgeschakeld tijdens vrijwillige onderbrekingen, zoals door AKS beheerde knooppuntupgrades. Het kan worden geconfigureerd als
minAvailable
replica's, waarmee het minimum aantal toepassingspods wordt aangegeven dat actief moet zijn ofmaxUnavailable
replica's, waarmee het maximum aantal toepassingspods wordt aangegeven dat kan worden beëindigd, waardoor hoge beschikbaarheid voor de toepassing wordt gegarandeerd. Raadpleeg de richtlijnen voor het configureren van podonderbrekingsbudgetten (PDBs). PDB-waarden moeten worden gevalideerd om te bepalen welke instellingen het meest geschikt zijn voor uw specifieke service. - Met een time-out voor het leegmaken van knooppunten in de knooppuntgroep kunt u de wachttijd configureren voor verwijdering van pods en respijtloze beëindiging per knooppunt tijdens een upgrade. Deze optie is handig wanneer u te maken hebt met langlopende workloads. Wanneer de time-out van het knooppunt wordt opgegeven (in minuten), respecteert AKS het wachten op budgetten voor podonderbreking. Als dit niet is opgegeven, is de standaardtime-out 30 minuten.
- Knooppuntweektijd helpt om knooppuntupgrades op een gecontroleerde manier te verspringen en kan de downtime van toepassingen tijdens een upgrade minimaliseren. U kunt een wachttijd opgeven, bij voorkeur zo dicht mogelijk bij 0 minuten, om de gereedheid van toepassingen tussen knooppuntupgrades te controleren. Als dit niet is opgegeven, is de standaardwaarde 0 minuten. Knooppuntweektijd werkt samen met de maximale time-outeigenschappen voor piek- en knooppuntafvoer die beschikbaar zijn in de knooppuntgroep om de juiste resultaten te leveren in termen van upgradesnelheid en beschikbaarheid van toepassingen.
Volgende stappen
Dit artikel bevat verschillende upgradeopties voor AKS-clusters. Zie AKS-patch- en upgraderichtlijnen voor een gedetailleerde bespreking van best practices en andere overwegingen voor upgrades.
Azure Kubernetes Service