Leitfaden zu Patches und Upgrades in Azure Kubernetes Service

In diesem Abschnitt des Leitfadens zu Day-2-Vorgängen in Azure Kubernetes Service (AKS) werden Patch- und Upgrade-Strategien für AKS-Workerknoten und Kubernetes-Versionen erläutert. Als Clusteroperator brauchen Sie einen Plan, um Ihre Cluster auf dem neuesten Stand zu halten und auf im Verlauf der Zeit geänderte oder veraltete Kubernetes-APIs zu überwachen.

Hintergrund und Arten von Updates

Es gibt drei Arten von Updates für AKS, und jede baut auf dem vorherigen Update auf:

Arten von Updates

• Node OS-Sicherheitspatches (nur Linux): Für Linux-Knoten stellen canonical Ubuntu und Azure Linux Betriebssystemsicherheitspatches einmal täglich zur Verfügung. Microsoft testet und bündelt diese Patches in den wöchentlichen Updates für Knoten-Images.

• Wöchentliche Updates für Knotenimages: AKS stellt wöchentliche Updates für Knotenimages bereit. Diese Updates beinhalten die neuesten Betriebssystem- und AKS-Sicherheitsupdates, Programmfehlerbehebungen und Verbesserungen. Durch Node-Updates ändert sich die Kubernetes-Version nicht. Versionen werden für Linux nach Datum (z. B. 202311.07.0) und für Windows nach Windows Server-Betriebssystembuild und Datum (z. B. 20348.2113.231115) formatiert. Weitere Informationen finden Sie unter AKS-Versionsstatus.

• Vierteljährliche Kubernetes-Versionen: AKS stellt vierteljährliche Updates für Kubernetes-Versionen bereit. Mit diesen Updates können AKS-Benutzer die neuesten Kubernetes-Features und Verbesserungen verwenden, z. B. Sicherheitspatches und Knotenimageupdates. Weitere Informationen finden Sie unter Unterstützte Kubernetes-Versionen in AKS.

Überlegungen zu Upgrades

Bevor Sie Ihre AKS-Workerknoten und Kubernetes-Versionen aktualisieren, sollten Sie die folgenden Effekte und bewährten Methoden berücksichtigen.

Gesamtauswirkungen auf Cluster

• In-Place-Upgrades für Nodes und Cluster wirken sich auf die Leistung Ihrer Kubernetes-Umgebung aus, während ihrer Durchführung. Durch ordnungsgemäße Konfiguration von Budgets für die Unterbrechung von Pods, Konfiguration von Surge-Nodes und richtige Planung lässt sich dieser Effekt minimieren.

• Blaugrüne Updatestrategien wirken sich nicht auf die Clusterleistung aus, erhöhen aber die Kosten und Komplexität.

• Unabhängig von Ihrer Upgrade- und Patch-Strategie brauchen Sie einen robusten Test- und Validierungsprozess für Ihren Cluster. Nehmen Sie zuerst Patchs und Upgrades für untergeordnete Umgebungen vor und überprüfen Sie mit einer Validierung nach der Wartung die Integrität von Cluster, Node, Bereitstellung und Anwendung.

Bewährte Methoden für AKS-Workloads

Um sicherzustellen, dass Ihr AKS-Cluster während der Wartung reibungslos funktioniert, befolgen Sie die folgenden bewährten Methoden:

• Legen Sie Budgets für die Unterbrechung von Pods (Pod Disruption Budgets, PDBs) fest. Das Einrichten von PBDs für Ihre Implementierungen ist unerlässlich. PDBs erzwingen eine minimale Anzahl verfügbarer Anwendungsreplikate, um eine durchgängige Funktionsfähigkeit während Unterbrechungsereignissen sicherzustellen. Mit PDBs lässt sich die Stabilität Ihres Clusters während der Wartung oder bei Node-Fehlern wahren.

  Warnung

  Falsch konfigurierte PDBs können den Upgrade-Prozess blockieren, da die Kubernetes-API das erforderliche Sperren und Leeren verhindert, das mit einem parallelen Upgrade von Node-Images einhergeht. Wenn zu viele Pods gleichzeitig verlagert werden, ist ein Ausfall der Anwendung möglich. Die richtige PDB-Konfiguration verringert dieses Risiko.

• Überprüfen Sie die verfügbaren Compute- und Netzwerklimits. Überprüfen Sie die verfügbaren Compute- und Netzwerklimits in Ihrem Azure-Abonnement über die Kontingentseite im Azure-Portal oder den Befehl az quota. Überprüfen Sie Compute- und Netzwerkressourcen, insbesondere VM-vCPUs für Ihre Nodes, sowie die Anzahl der VMs und VM-Skalierungsgruppen. Wenn ein Limit nahezu erreicht ist, sollten Sie vor dem Upgrade eine Kontingenterhöhung anfordern.

• Überprüfen Sie den verfügbaren IP-Adressraum in Knotensubnetzen. Während Updates werden spezielle Surge-Nodes in Ihrem Cluster erstellt, und Pods werden auf diese Nodes verlagert. Es ist wichtig, dass Sie den IP-Adressraum in Ihren Knotensubnetzen überwachen, um sicherzustellen, dass genügend Adressraum für diese Änderungen vorhanden ist. Verschiedene Kubernetes-Netzwerkkonfigurationen weisen unterschiedliche IP-Adressanforderungen auf. Überprüfen Sie zunächst die folgenden Überlegungen:

  • Während eines Upgrades erhöht sich die Anzahl der Knoten-IP-Adressen entsprechend Ihrem Zuwachswert. Der minimale Anstiegswert ist 1.
  • Cluster, die auf der Azure Container Network Interface basieren, weisen einzelnen Pods IP-Adressen zu. Daher muss genügend Adressraum für die Pod-Bewegung vorhanden sein.
  • Ihr Cluster bleibt während Upgrades funktionsfähig. Stellen Sie sicher, dass genügend IP-Adressraum bleibt, um die Knotenskalierung zuzulassen.

• Richten Sie mehrere Umgebungen ein. Richten Sie mehrere Kubernetes-Umgebungen ein, z. B. Entwicklung, Staging und Produktionsumgebungen. Diese Trennung ermöglicht es Ihnen, Änderungen vollständig zu testen und zu überprüfen, bevor Sie sie in die Produktion verschieben. Die Überprüfung ist besonders wichtig, wenn Sie zwischen mehreren Versionen von AKS wechseln, z. B. zwischen 1.28 und 1.31.

• Legen Sie Wartungsfenster fest. Upgrade-Prozesse können sich auf die Gesamtleistung Ihres Kubernetes-Clusters auswirken. Planen Sie direkte Upgrade-Prozesse außerhalb der Spitzennutzungszeiten und überwachen Sie die Clusterleistung, um eine angemessene Größenanpassung sicherzustellen, insbesondere während der Update-Prozesse.

• Optimieren Sie Cluster für das Verhalten von nicht entleerbaren Knoten. Standardmäßig schlägt das Patchen auf Ihrem Cluster fehl, wenn ein Knoten nicht erfolgreich entleert wird. Um dieses Problem zu beheben, sollten Sie Node-Drain und Cordon konfigurieren. Bei diesem Prozess werden nicht entleerbare Knoten unter Quarantäne gestellt, damit Ihr Cluster erfolgreich aktualisiert werden kann. Anschließend können Sie die Knoten, die nicht aktualisiert werden konnten, manuell beheben, indem Sie sie patchen oder löschen.

• Optimieren sie die Surge-Werte für das Upgrade. Standardmäßig hat AKS einen Surge-Wert von 1, was bedeutet, dass im Rahmen des Upgrade-Prozesses immer nur jeweils ein zusätzlicher Node erstellt wird. Durch Erhöhen dieses Werts können Sie die Geschwindigkeit eines AKS-Upgrades steigern. Ein Anstieg um 33 % ist der empfohlene Höchstwert für Workloads, die für Unterbrechungen anfällig sind. Weitere Informationen finden Sie unter Anpassen des Knotenanstiegsupgrades.

• Optimieren Sie das Timeout der Knotenentleerung.Das Timeout der Knotenentleerung gibt die maximale Zeit an, die ein Cluster wartet, während versucht wird, Pods auf einem Knoten, der aktualisiert wird, neu zu planen. Der Standardwert ist 30 Minuten. Bei Workloads, die Schwierigkeiten haben, Pods neu zu planen, kann die Erhöhung dieses Werts hilfreich sein.

• Eintauch-Zeitlimit des Knotens anpassen. Standardmäßig fährt die Knoten-Eintauch-Konfiguration fort, den nächsten Knoten neu zu erstellen, nachdem ein Knoten seinen Aktualisierungsprozess abgeschlossen hat. Bei bestimmten älteren oder vertraulichen Workloads kann es von Vorteil sein, eine Verzögerung hinzuzufügen, bevor Sie mit dem nächsten Knoten fortfahren. Fügen Sie eine Verzögerung hinzu, indem Sie ein Soak-Timeout für einen Knoten konfigurieren.

• Überprüfen Sie andere Abhängigkeiten in Ihrem Cluster. Kubernetes-Operatoren stellen häufig andere Tools im Kubernetes-Cluster als Teil von Vorgängen wie KEDA-Skalierungen, DAPR und Dienstgitter bereit. Wenn Sie Ihre Upgradeprozesse planen, überprüfen Sie die Versionshinweise für alle Komponenten, die Sie verwenden, um die Kompatibilität mit der Zielversion sicherzustellen.

• Optimieren der zonalen AKS-Konfigurationen. Bei zonalen AKS-Clustern kann das Upgrade vorübergehend zu einer ungleichmäßigen Verteilung von Arbeitslasten zwischen den Zonen führen. Um dieses Szenario zu verhindern, legen Sie den Anstiegwert auf ein Vielfaches von drei fest, z. B. 33 % Anstieg.

Wöchentliche Updates für Knotenimages verwalten

Microsoft erstellt ungefähr einmal pro Woche ein neues Knotenimage für AKS-Knoten. Ein Node-Image enthält aktuelle Betriebssystem-Sicherheitsupdates, Betriebssystem-Kernelupdates, Kubernetes-Sicherheitsupdates, aktualisierte Versionen von Binärdateien wie Kubelet und Updates der Komponentenversion, die in den Versionshinweisen aufgeführt sind.

Wenn ein Node-Image aktualisiert wird, wird auf den Nodes des Ziel-Node-Pools eine Aktion zum Sperren und Leeren ausgelöst:

1. Dem Node-Pool wird ein Node mit dem aktualisierten Image hinzugefügt. Der Surge-Wert steuert, wie viele Knoten gleichzeitig hinzugefügt werden.
2. Je nach Stoßwert wird eine Reihe vorhandener Knoten abschnürt und entwässert. Durch das Sperren wird sichergestellt, dass der Node keine Pods plant. Durch das Leeren werden die Pods entfernt und für andere Nodes geplant.
3. Nachdem diese Knoten vollständig entwässert wurden, werden sie aus dem Knotenpool entfernt. Sie werden durch die durch den Surge hinzugefügten aktualisierten Nodes ersetzt.
4. Dieser Vorgang wird für jeden Node-Batch wiederholt, der im Node-Pool aktualisiert werden muss.

Ein ähnlicher Prozess ergibt sich während eines Clusterupgrades.

Automatische Upgrades für Node-Images

Im Allgemeinen sollten die meisten Cluster den NodeImage Updatekanal verwenden. Dieser Kanal stellt wöchentlich ein aktualisiertes Node-Image-VHD bereit und wird entsprechend dem Wartungsfenster Ihres Clusters aktualisiert.

Die verfügbaren Kanäle sind:

• None. Es werden keine Updates automatisch ausgeführt.

• Unmanaged. Das Betriebssystem wendet Ubuntu- und Azure Linux-Updates nachts an. Neustarts müssen separat verwaltet werden. AKS kann die Häufigkeit dieser Updates nicht testen oder steuern.

• SecurityPatch. Das Betriebssystem stellt Sicherheitspatches bereit, die AKS getestet werden, vollständig verwaltet werden und sichere Bereitstellungsmethoden verwenden. Dieser Patch enthält keine Betriebssystemfehlerbehebungen. Es enthält nur Sicherheitsupdates.

• NodeImage. AKS aktualisiert die Knoten auf wöchentlicher Basis mit einer neu gepatchten VHD, die Sicherheitskorrekturen und Fehlerbehebungen enthält. Diese Updates werden vollständig getestet und mithilfe sicherer Bereitstellungsmethoden bereitgestellt. Echtzeitinformationen zu derzeit bereitgestellten Knotenimages finden Sie unter Updates zu AKS-Knotenimages.

Informationen zu den Standardintervallen ohne Anwendung eines geplanten Wartungsfensters finden Sie unter Aktualisieren des Eigentums und des Zeitplans.

Wenn Sie den Updatekanal Unmanaged wählen, müssen Sie den Neustartvorgang mithilfe eines Tools wie kured verwalten. Der Unmanaged-Kanal enthält keine AKS-bereitgestellten sicheren Bereitstellungspraktiken und funktioniert nicht während der Wartungszeiträume.

Wenn Sie den SecurityPatch Updatekanal auswählen, können Sie Updates so häufig wie wöchentlich anwenden. Für diese Patch-Ebene müssen die VHDs in Ihrer Ressourcengruppe gespeichert werden, wofür eine Gebühr anfällt. Um zu steuern, wann SecurityPatch angewendet wird, legen Sie einen aksManagedNodeOSUpgradeSchedule Takt fest, der für Ihre Workload am besten geeignet ist. Wenn Sie auch Fehlerkorrektur-Features benötigen, die in der Regel mit neuen Knotenimages (VHD) bereitgestellt werden, müssen Sie den NodeImage-Kanal wählen, und nicht SecurityPatch.

Weitere Informationen finden Sie unter Verwenden der geplanten Wartung zum Planen und Steuern von Upgrades für Ihren AKS-Cluster.

Als bewährte Methode empfiehlt sich die Verwendung des Updatekanals NodeImage und das Konfigurieren eines aksManagedNodeOSUpgradeSchedule-Wartungsfensters außerhalb der Spitzennutzungszeit des Clusters. Attribute, die Sie zum Konfigurieren des Clusterwartungsfensters verwenden können, finden Sie unter Erstellen eines Wartungsfensters. Die Schlüsselattribute sind:

• name. aksManagedNodeOSUpgradeSchedule für Betriebssystemupdates für Nodes verwenden.

• utcOffset. Konfigurieren der Zeitzone.

• startTime. Festlegen der Startzeit des Wartungsfensters.

• dayofWeek. Festlegen der Wochentage für das Fenster. Beispiel: Saturday.

• schedule. Festlegen der Häufigkeit des Fensters. Für NodeImage-Updates empfehlen wir weekly.

• durationHours. Legen Sie dieses Attribut auf mindestens vier Stunden fest.

Im folgenden Beispiel wird ein wöchentliches Wartungsfenster auf 18:00 Uhr Ostzeit am Samstag festgelegt:

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utc-offset=-05:00 --start-time 20:00 --day-of-week Saturday --schedule-type weekly --duration 4

Idealerweise wird diese Konfiguration als Teil der Infrastructure-as-Code-Bereitstellung des Clusters implementiert.

Weitere Beispiele finden Sie unter Hinzufügen einer Wartungsfensterkonfiguration.

Die konfigurierten Wartungsfenster können Sie über die Azure CLI prüfen:

az aks maintenanceconfiguration list -g <ResourceGroupName> --cluster-name <AKSClusterName>

Über die CLI können Sie auch die Details eines bestimmten Wartungsfensters prüfen:

az aks maintenanceconfiguration show -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule

Wenn kein Cluster-Wartungsfenster konfiguriert ist, werden Updates für Node-Images alle zwei Wochen ausgeführt. Die AKS-Wartung erfolgt innerhalb des konfigurierten Fensters so weit wie möglich, aber die Wartungszeit wird nicht garantiert.

Um den Status von Updates automatisch zu überwachen, können Sie den AKS-Kommunikations-Manager verwenden, um automatische Warnungen für geplante Wartungsaktivitäten bereitzustellen. Alternativ können Sie direkt über Azure Monitor-Aktivitätsprotokolle überwachen oder die Ressourcenprotokolle im Cluster über kubectl get eventsüberprüfen.

Abonnieren Sie AKS-Ereignisse mit Azure Event Grid , um AKS-Upgradeereignisse abzurufen. Diese Ereignisse können Sie benachrichtigen, wenn eine neue Version von Kubernetes verfügbar ist, und Sie beim Nachverfolgen von Knotenstatusänderungen während upgradeprozessen unterstützen.

Sie können den wöchentlichen Updateprozess auch über GitHub Actions verwalten. Mit dieser Methode lässt sich der Updateprozess differenzierter steuern.

Manueller Prozess für Node-Updates

Mit dem Befehl kubectl describe nodes können Sie die Betriebssystem-Kernelversion und die Betriebssystem-Imageversion der Nodes in Ihrem Cluster ermitteln:

kubectl describe nodes <NodeName>

Beispielausgabe (gekürzt):

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             5.15.173.1-1.cm2
  OS Image:                   CBL-Mariner/Linux
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.6.26
  Kubelet Version:            v1.31.3
  Kube-Proxy Version:         v1.31.3

Verwenden Sie den Azure CLI-Befehl az aks nodepool list, um die Node-Image-Versionen der Nodes in einem Cluster zu ermitteln:

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,NodeImageVersion:nodeImageVersion}" --output table

Beispielausgabe:

Name       NodeImageVersion
---------  ---------------------------------------------
systempool  AKSUbuntu-2204gen2containerd-202307.12.0
usernodepool  AKSUbuntu-2204gen2arm64containerd-202307.12.0

Verwenden Sie den Befehl "az aks nodepool get-upgrades ", um die neueste verfügbare Knotenimageversion für einen bestimmten Knotenpool zu ermitteln:

az aks nodepool get-upgrades \
   --resource-group <ResourceGroupName> \
   --cluster-name <AKSClusterName> \
   --nodepool-name <NodePoolName> --output table

Beispielausgabe:

Name    NodeImageVersion
------  -------------------------------------
system  AKSAzureLinux-V2gen2-202501.12.0
user    AKSAzureLinux-V2gen2arm64-202501.12.0

Clusterupgrades

Die Kubernetes-Community veröffentlicht etwa alle drei Monate Nebenversionen von Kubernetes. Um Sie über neue AKS-Versionen und -Releases auf dem Laufenden zu halten, wird die Seite mit AKS-Versionshinweisen regelmäßig aktualisiert. Sie können auch den GitHub AKS RSS-Feed mit Echtzeitupdates zu Änderungen und Verbesserungen abonnieren.

AKS folgt einer N - 2-Supportrichtlinie , was bedeutet, dass der vollständige Support für die neueste Version (N) und die beiden vorherigen Nebenversionen bereitgestellt wird. Ein eingeschränkter Plattformsupport wird für die drittletzte Nebenversion angeboten. Weitere Informationen finden Sie unter Supportrichtlinien für AKS.

Um sicherzustellen, dass Ihre AKS-Cluster weiterhin unterstützt werden, müssen Sie einen kontinuierlichen Cluster-Upgrade-Prozess einrichten. Dieser Prozess umfasst das Testen neuer Versionen in untergeordneten Umgebungen und die Planung des Upgrades für die Produktion, bevor die neue Version zum Standard wird. Dieser Ansatz trägt dazu bei, die Vorhersagbarkeit in Ihrem Upgradeprozess aufrechtzuerhalten und Unterbrechungen für Anwendungen zu minimieren. Weitere Informationen finden Sie unter Upgradeoptionen für AKS-Cluster.

Wenn Ihr Cluster einen längeren Upgrade-Zyklus erfordert, sollten Sie AKS-Versionen verwenden, die die Option langfristiger Support (LTS) unterstützen. Wenn Sie die LTS-Option aktivieren, erbringt Microsoft für zwei Jahre einen erweiterten Support für Kubernetes-Versionen, was einen längeren und kontrollierteren Upgrade-Zyklus ermöglicht. Weitere Informationen finden Sie unter Unterstützte Kubernetes-Versionen in AKS.

Ein Cluster-Upgrade umfasst ein Knoten-Upgrade und verwendet einen Absperr- und Entleerungsprozess.

Vor dem Upgrade

Als bewährte Methode empfiehlt es sich, immer in untergeordneten Umgebungen ein Upgrade und Tests durchzuführen, um das Risiko von Unterbrechungen in der Produktion zu minimieren. Clusterupgrades erfordern zusätzliche Tests, da sie API-Änderungen umfassen, die sich auf Kubernetes-Bereitstellungen auswirken können. Die folgenden Ressourcen können Sie beim Upgradeprozess unterstützen.

• AKS-Arbeitsmappe für veraltete APIs: Wählen Sie auf der Seite "Clusterübersicht" im Azure-Portal "Diagnostizieren und Lösen von Problemen" aus, wechseln Sie zur Kategorie "Erstellen", "Upgrade", "Löschen" und "Skalierung ", und wählen Sie dann "Kubernetes-API-Veraltet" aus. Dieses Verfahren führt eine Arbeitsmappe aus, die nach veralteten API-Versionen sucht, die Ihr Cluster weiterhin verwendet. Weitere Informationen finden Sie unter Entfernung der Verwendung veralteter APIs.

• Seite mit den AKS-Versionshinweisen: Diese Seite enthält umfassende Informationen zu neuen AKS-Versionen und -Releases. Sehen Sie sich diese Hinweise an, um über die neuesten Updates und Änderungen auf dem Laufenden zu bleiben.

• Kubernetes– Versionshinweise: Diese Seite bietet detaillierte Einblicke in die neuesten Kubernetes-Versionen. Achten Sie besonders auf dringende Upgradenotizen. Sie heben wichtige Informationen hervor, die sich auf Ihren AKS-Cluster auswirken können.

• Breaking Changes der AKS-Komponenten nach Version. Diese Tabelle enthält eine umfassende Übersicht über grundlegende Änderungen in AKS-Komponenten nach Version. Wenn Sie sich auf dieses Handbuch beziehen, können Sie proaktiv alle potenziellen Kompatibilitätsprobleme vor dem Upgradeprozess beheben.

Zusätzlich zu diesen Microsoft-Ressourcen sollten Sie den Einsatz von OpenSource-Tools zur Optimierung ihres Cluster-Upgrade-Prozesses in Erwägung ziehen. Ein solches Tool ist Fairwinds pluto, das Ihre Bereitstellungen und Helm-Diagramme nach veralteten Kubernetes-APIs scannen kann. Mit diesen Tools können Sie sicherstellen, dass Ihre Anwendungen mit den neuesten Kubernetes-Versionen kompatibel bleiben.

Upgradeprozess

Um zu überprüfen, wann Ihr Cluster ein Upgrade erfordert, verwenden Sie den Befehl "az aks get-upgrades ", um eine Liste der verfügbaren Upgradeversionen für Ihren AKS-Cluster abzurufen. Ermitteln Sie die Zielversion für Ihren Cluster aus den Ergebnissen.

Ein Beispiel:

az aks get-upgrades \
   --resource-group <ResourceGroupName> --name <AKSClusterName> --output table

Beispielausgabe:

MasterVersion  Upgrades
-------------  ---------------------------------
1.30.7         1.31.1, 1.31.2, 1.31.3

Überprüfen Sie die Kubernetes-Versionen der Knoten in Ihren Knotenpools, um die Pools zu finden, die aktualisiert werden müssen:

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,k8version:orchestratorVersion}" --output table

Beispielausgabe:

Name          K8version
------------  ------------
systempool    1.30.7
usernodepool  1.30.7

Manuelle Aktualisierungen

Um Unterbrechungen zu minimieren und ein reibungsloses Upgrade für Ihren AKS-Cluster sicherzustellen, gehen Sie folgendermaßen vor:

1. Nehmen Sie ein Upgrade der AKS-Steuerungsebene vor. Aktualisieren Sie die Steuerungsebenenkomponenten, die für die Verwaltung und Orchestrierung Ihres Clusters verantwortlich sind. Aktualisieren Sie zuerst die Steuerebene, um Kompatibilität und Stabilität sicherzustellen, bevor Sie die einzelnen Knotenpools aktualisieren.

2. Nehmen Sie ein Upgrade des System-Node-Pools vor. Nehmen Sie nach dem Upgrade der Steuerungsebene das Upgrade des System-Node-Pools in Ihrem AKS-Cluster vor. Knotenpools bestehen aus den VM-Instanzen, die Ihre Anwendungsworkloads ausführen. Das separate Upgrade der Knotenpools ermöglicht ein kontrolliertes und systematisches Upgrade der zugrunde liegenden Infrastruktur, die Ihre Anwendungen unterstützt.

3. Nehmen Sie ein Upgrade der Benutzerknotenpools vor. Nehmen Sie nach dem Upgrade des System-Node-Pools das Upgrade von Benutzerknotenpools in Ihrem AKS-Cluster vor.

Mit dieser Vorgehensweise können Sie Unterbrechungen während des Upgrade-Prozesses minimieren und die Verfügbarkeit Ihrer Anwendungen wahren. Führen Sie die folgenden Schritte aus:

1. Führen Sie den Befehl az aks upgrade mit dem Flag --control-plane-only aus, um nur ein Upgrade der Steuerungsebene des Clusters und nicht der Node-Pools des Clusters vorzunehmen:

   az aks upgrade \
      --resource-group <ResourceGroupName> --name <AKSClusterName> \
      --control-plane-only \
      --kubernetes-version <KubernetesVersion>
   

2. Führen Sie den Befehl "az aks nodepool upgrade " aus, um Knotenpools auf die Zielversion zu aktualisieren:

   az aks nodepool upgrade \
      --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> --name <NodePoolName> \
      --no-wait --kubernetes-version <KubernetesVersion>
   

   Während des Upgrades des Knotenpools erstellt AKS einen Surge-Knoten, sperrt und leert Pods in dem zu aktualisierenden Knoten, führt ein Reimaging des Knotens durch und entsperrt dann die Pods. Dieser Vorgang wird für die anderen Knoten im Knotenpool wiederholt.

Sie können den Status des Upgrade-Prozesses durch Ausführen von kubectl get events überprüfen. Informationen zur Problembehandlung bei Clusterupgrades finden Sie in der Dokumentation zur Problembehandlung für AKS.

Anmeldung von Clustern in Release-Kanälen für automatische Upgrades

AKS bietet auch eine automatische Clusterupgradelösung , um Ihren Cluster auf dem neuesten Stand zu halten. Wenn Sie diese Lösung verwenden, sollten Sie sie mit einem Wartungsfenster koppeln, damit Sie den Zeitpunkt der Upgrades steuern können. Das Upgradefenster muss mindestens vier Stunden umfassen. Wenn Sie einen Cluster in einem Release-Kanal registrieren, verwaltet Microsoft automatisch die Version und Häufigkeit von Upgrades für den Cluster und seine Node-Pools.

Das automatische Upgrade des Clusters bietet verschiedene Release-Kanäle. Hier ist eine empfohlene Umgebungs- und Release-Kanal-Konfiguration:

Überlegungen

In der folgenden Tabelle werden die Merkmale verschiedener AKS-Upgrade- und Patchingszenarien beschrieben.

• Ein Sicherheitspatch des Betriebssystems, der als Teil eines Upgrades der Knotenabbild angewendet wird, kann eine neuere Version des Kernels installieren als bei der Erstellung eines neuen Clusters installiert würde.

• Beim Hochskalieren des Node-Pools wird das Modell verwendet, das derzeit der VM-Skalierungsgruppe zugeordnet ist. Die Betriebssystemkerne werden aktualisiert, wenn Sicherheitspatches angewendet werden und die Knoten neu gestartet werden.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

• Anthony Nevico | Principal Cloud Solution Architect

Andere Mitwirkende:

• Rishabh Saha | Principal Solution Architect
• Paolo Salvadori | Principal Customer Engineer, FastTrack für Azure
• Ali Yousefi | Cloud-Lösungsarchitekt

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• AKS-Produktdokumentation
• AKS-Release-Tracker
• AKS-Roadmap
• Behandeln von AKS-Problemen
• AKS-Upgrades optimieren
• Häufig gestellte Fragen zum Upgrade des Knotenbetriebssystems
• Definition von Tag-2-Operationen
• Eine praktische Anleitung für zonenredundante AKS-Cluster
• Leitfaden für das Cloud Adoption Framework für die Einführung von AKS in einer Azure-Zielzone

Zugehörige Ressourcen

• AKS: Anleitung zu „Day 2“-Vorgängen
• AKS-Selektierungsverfahren