Upgradeoptionen für AKS-Cluster (Azure Kubernetes Service)

In diesem Artikel wurden verschiedene Upgradeoptionen für AKS-Cluster behandelt. Informationen zu einfachen Kubernetes-Versionsupgrades finden Sie unter Upgraden eines AKS-Clusters.

Informationen zu AKS-Clustern, für die mehrere Knotenpools oder Windows Server-Knoten verwendet werden, finden Sie unter Durchführen eines Upgrades für einen Knotenpool in AKS. Informationen zum Upgrade eines bestimmten Knotenpools, ohne ein Upgrade des Kubernetes-Clusters durchzuführen, finden Sie unter Upgrade eines bestimmten Knotenpools.

Durchführen manueller Upgrades

Sie können manuelle Upgrades durchführen, um zu steuern, wann Ihr Cluster auf eine neue Kubernetes-Version upgegradet wird. Manuelle Upgrades sind hilfreich, wenn Sie eine neue Kubernetes-Version testen möchten, bevor Sie Ihren Produktionscluster upgraden. Sie können auch manuelle Upgrades verwenden, um Ihr Cluster auf eine bestimmte Kubernetes-Version upzugraden, die nicht die neueste verfügbare Version ist.

Informationen zu manuellen Upgrades finden Sie in den folgenden Artikeln:

• Aktualisieren eines AKS-Clusters
• Aktualisieren des Knotenimages
• Anpassen des Upgrades für Knotenanstiege
• Verarbeiten von Betriebssystemupdates für Knoten

Konfigurieren automatischer Upgrades

Sie können automatische Upgrades so konfigurieren, dass Ihr Cluster automatisch auf die neueste verfügbare Kubernetes-Version upgegradet wird. Automatische Upgrades sind nützlich, wenn Sie sicherstellen möchten, dass Ihr Cluster immer die neueste Kubernetes-Version ausführt. Sie können automatische Upgrades auch verwenden, um sicherzustellen, dass Ihr Cluster immer eine unterstützte Kubernetes-Version ausführt.

Informationen zum Konfigurieren von automatischen Upgrades finden Sie in den folgenden Artikeln:

• Automatisches Upgraden eines AKS-Clusters
• Verwenden der geplanten Wartung zum Planen und Steuern von Upgrades für Ihren AKS-Cluster
• Automatisches Beenden von AKS-Clusterupgrades bei Breaking Changes bei der API (Vorschau)
• Automatisches Upgraden von Betriebssystemimages für AKS-Clusterknoten
• Automatisches Anwenden von Sicherheitsupdates auf AKS-Knoten mithilfe von GitHub Actions

Besondere Überlegungen für Knotenpools, die sich über mehrere Verfügbarkeitszonen erstrecken

AKS verwendet Best-Effort-Zonenausgleich in Knotengruppen. Während eines Upgradeanstiegs sind die Zonen für die Surge-Knoten in Virtual Machine Scale Sets im Vorfeld unbekannt. Dies kann während eines Upgrades vorübergehend zu einer unausgewogenen Zonenkonfiguration führen. AKS löscht jedoch die Surge-Knoten, sobald das Upgrade abgeschlossen ist, und wahrt das ursprüngliche Zonengleichgewicht. Wenn Ihre Zonen bei Upgrades ausgeglichen bleiben sollen, können Sie den Anstieg auf ein Vielfaches von drei Knoten erhöhen. Virtual Machine Scale Sets gleicht dann Ihre Knoten über Verfügbarkeitszonen hinweg mit dem bestmöglichen Zonenausgleich aus. Beim bestmöglichen Zonengleichgewicht versucht die Skalierungsgruppe, das horizontale Herunter- und Hochskalieren durchzuführen, während das Gleichgewicht beibehalten wird. Falls dies aus bestimmten Gründen nicht möglich ist (wenn beispielsweise eine Zone ausfällt und die Skalierungsgruppe in dieser Zone keine neue VM erstellen kann), lässt die Skalierungsgruppe ein vorübergehendes Ungleichgewicht zu, um das erfolgreiche Ab- und Aufskalieren zu ermöglichen.

Persistent Volume Claims (PVCs), die von lokal redundanten Azure-Speicherdatenträgern (LRS) unterstützt werden, sind an eine bestimmte Zone gebunden und können möglicherweise nicht sofort wiederhergestellt werden, wenn der Anstiegsknoten nicht mit der PVC-Zone übereinstimmt. Wenn die Zonen nicht übereinstimmen, kann dies zu einer Downtime Ihrer Anwendung führen, wenn der Upgradevorgang weiterhin Knoten ausgleicht, die PVs jedoch an eine Zone gebunden sind. Um diesen Fall zu bewältigen und hohe Verfügbarkeit aufrechtzuerhalten, konfigurieren Sie für Ihre Anwendung ein Budget für die Unterbrechung von Pods, damit Kubernetes Ihre Verfügbarkeitsanforderungen während des Entleerungsvorgangs berücksichtigen kann.

Optimieren von Upgrades zur Verbesserung der Leistung und Minimierung von Unterbrechungen

Die Kombination aus Geplantem Wartungsfenster, Maximalem Anstiegswert, Pod-Unterbrechungsbudget, Knotenablauftimeout und Knoteneinweichzeit (Vorschau) kann die Wahrscheinlichkeit eines erfolgreichen Abschlusses von Knotenupgrades bis zum Ende des Wartungsfensters erheblich erhöhen und gleichzeitig Unterbrechungen minimieren.

• Das geplante Wartungsfenster ermöglicht Serviceteams, das automatische Upgrade während eines vordefinierten Fensters, in der Regel in einem Zeitraum mit geringem Datenverkehr, zu planen, um die Auswirkungen auf die Arbeitsauslastung zu minimieren. Es wird ein Zeitfenster von mindestens vier Stunden empfohlen.

• Der maximale Anstiegswert für den Knotenpool ermöglicht das Anfordern eines zusätzlichen Kontingents während des Upgradevorgangs und schränkt die Anzahl der gleichzeitig für das Upgrade ausgewählten Knoten ein. Ein höherer maximaler Anstiegswert führt zu einem schnelleren Upgradevorgang. Es wird nicht empfohlen, diesen auf 100 % festzulegen, da dann alle Knoten gleichzeitig aktualisiert werden, was zu Unterbrechungen bei der Ausführung von Anwendungen führen kann. Es wird empfohlen, ein maximales Kontingent von 33 % für Produktionsknotenpools festzulegen.

• Das Pod-Unterbrechungsbudget wird für Dienstanwendungen festgelegt und begrenzt die Anzahl von Pods, die während freiwilliger Unterbrechungen ausfallen können, z. B. bei AKS-gesteuerte Knotenupgrades. Es kann als minAvailable-Replikate konfiguriert werden, was die Mindestanzahl von Anwendungspods angibt, die aktiv sein müssen, oder als maxUnavailable-Replikate, was die maximale Anzahl von Anwendungspods angibt, die beendet werden können, um die Hochverfügbarkeit für die Anwendung sicherzustellen. Weitere Informationen finden Sie in der bereitgestellten Anleitung zum Konfigurieren von Pod-Unterbrechungsbudgets (Pod Disruption Budgets, PDBs). PDB-Werte sollten überprüft werden, um die Einstellungen zu ermitteln, die für Ihren spezifischen Dienst am besten funktionieren.

• Mit dem Knotenablauftimeout im Knotenpool können Sie die Wartezeit für die Entfernung von Pods und eine ordnungsgemäße Beendigung pro Knoten während eines Upgrades konfigurieren. Diese Option ist hilfreich beim Umgang mit Workloads mit langer Ausführung. Wenn das Timeout des Knotens angegeben ist (in Minuten), berücksichtigt AKS das Warten auf Pod-Unterbrechungsbudgets. Sofern nicht angegeben, wird der Timeout-Wert standardmäßig auf 30 Minuten festgelegt.

• Knoteneinweichzeit (Vorschau) hilft dabei, Knotenupgrades auf kontrollierte Weise zu staffeln und Anwendungsausfallzeiten während eines Upgrades zu minimieren. Sie können eine Wartezeit angeben, vorzugsweise möglichst nahe 0 Minuten, um die Anwendungsbereitschaft zwischen Knotenupgrades zu überprüfen. Wenn Sie hier nichts angeben, ist der Standardwert 0 Minuten. Die Knoteneinweichzeit arbeitet mit den im Knotenpool verfügbaren maximalen Auf- und Knoten-Entwässerungstimeout-Eigenschaften zusammen, um die richtigen Ergebnisse in Bezug auf Upgradegeschwindigkeit und Anwendungsverfügbarkeit zu erzielen.

  Hinweis

  Um die Knoteneinlaufzeit (Vorschau) zu verwenden, muss die aks-previewAzure CLI-Erweiterung in der Version 0.5.173 oder höher installiert sein.

Nächste Schritte

In diesem Artikel wurden verschiedene Upgradeoptionen für AKS-Cluster aufgeführt. Eine ausführliche Erläuterung zu Best Practices für Upgrades und anderen Überlegungen finden Sie unter Patch- und Upgradeanleitungen für AKS.