Freigeben über

Leitfaden zu Patches und Upgrades in Azure Kubernetes Service

  • Artikel

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, die jeweils aufeinander aufbauen:

Updatetyp Häufigkeit des Upgrades Geplante Wartung unterstützt Unterstützte Methoden Ziel Link zur Dokumentation
Betriebssystem-Sicherheitsupdates für Nodes Nächtlich Ja Automatisch (wöchentlich), manuell/nicht verwaltet (nachts) Node Automatische Upgrades für Knoten-Images
Upgrades der Node-Imageversion Linux: wöchentlich
Windows: monatlich		 Ja Automatisch, manuell Knotenpool Upgrade des AKS-Knotenimages
Upgrades der Kubernetes-Version (Cluster) Quartalsweise Ja Automatisch, manuell Cluster- und Node-Pool Upgrade des AKS-Clusters

Arten von Updates

  • Betriebssystem-Sicherheitsupdates für Nodes (nur Linux). Für Linux-Nodes stellen sowohl Canonical Ubuntu als auch Azure Linux Betriebssystem-Sicherheits-Udates einmal pro Tag zur Verfügung. Microsoft testet und bündelt diese Patches in den wöchentlichen Updates für Knoten-Images.

  • Wöchentliche Updates für Node-Images. AKS stellt wöchentliche Updates für Node-Images 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-Freigabestatus.

  • Vierteljährliche Kubernetes-Releases. AKS stellt vierteljährliche Updates für Kubernetes-Releases bereit. Mit diesen Updates können AKS-Benutzer die neuesten Kubernetes-Features und -Verbesserungen nutzen. Sie beinhalten Sicherheitsupdates und Updates für Node-Images. Weitere Informationen finden Sie unter Unterstützte Kubernetes-Versionen in AKS.

Überlegungen zu Upgrades

Gesamtauswirkungen auf Cluster

  • Direkte Upgrades (sowohl Nodes als auch Cluster) wirken sich während ihrer Ausführung auf die Leistung Ihrer Kubernetes-Umgebung aus. 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.
  • Bei Anwendung einer Blau/Grün-Updatestrategie anstelle eines direkten Upgrades entfallen die Auswirkungen auf die Clusterleistung, aber Kosten und Komplexität nehmen zu.
  • 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

Gehen Sie nach den folgenden bewährten Methoden vor, um den reibungslosen Betrieb Ihres AKS-Clusters während der Wartung sicherzustellen:

  • Legen Sie Budgets für die Unterbrechung von Pods (Pod Disruption Budgets, PDBs) fest. Das Einrichten von Budgets für die Unterbrechung von Pods für Ihre Bereitstellungen ist von entscheidender Bedeutung. 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 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 Virtual Machines 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-Speicherplatz in Node-Subnetzen. Während Updates werden spezielle Surge-Nodes in Ihrem Cluster erstellt, und Pods werden auf diese Nodes verlagert. Sie müssen unbedingt den IP-Adressraum in Ihren Node-Subnetzen im Auge behalten, um sicherzustellen, dass genügend Adressraum für diese Änderungen vorhanden ist. Für unterschiedliche Kubernetes-Netzwerkkonfigurationen gelten unterschiedliche IP-Anforderungen. Sehen Sie sich als Ausgangspunkt die folgenden Überlegungen an:
    • Während eines Upgrades steigt die Anzahl der Knoten-IPs entsprechend Ihrem Surge-Wert. (Der Mindest-Surge-Wert beträgt 1.)
    • Auf Azure CNI basierende Cluster weisen einzelnen Pods IP-Adressen zu. Daher muss genügend IP-Adressraum für die Pod-Verlagerung vorhanden sein.
    • Ihr Cluster bleibt während Upgrades funktionsfähig. Achten Sie darauf, dass genügend verbleibender IP-Adressraum für die Node-Skalierung (falls aktiviert) vorhanden ist.
  • Richten Sie mehrere Umgebungen ein. Es wird empfohlen, separate Umgebungen wie Entwicklung, Staging und Produktion einzurichten, damit Sie Änderungen testen und validieren können, bevor Sie sie in der Produktion bereitstellen.
  • 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 des Knotens. Das Timeout des Knotens 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 hierfür sind 30 Minuten. Bei Arbeitslasten, die Schwierigkeiten haben, Pods neu zu planen, kann es hilfreich sein, diesen Standardwert anzupassen.
  • 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.
  • Überprüfen Sie andere Abhängigkeiten in Ihrem Cluster. Kubernetes-Operatoren stellen im Rahmen der Vorgänge im Kubernetes-Cluster oft andere Tools wie KEDA-Skalierungen, Dapr und Dienstnetze bereit. Überprüfen Sie bei der Planung Ihrer Upgrade-Prozesse die Versionshinweise für alle verwendeten Komponenten, um die Kompatibilität mit der Zielversion sicherzustellen.

Verwalten wöchentlicher Updates für Node-Images

Microsoft erstellt etwa einmal pro Woche ein neues Node-Image 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:

  • Dem Node-Pool wird ein Node mit dem aktualisierten Image hinzugefügt. Die Anzahl der gleichzeitig hinzugefügten Nodes richtet sich nach dem Surge-Wert.
  • Abhängig vom Surge-Wert wird ein Batch von vorhandenen Nodes gesperrt und geleert. Durch das Sperren wird sichergestellt, dass der Node keine Pods plant. Durch das Leeren werden die Pods entfernt und für andere Nodes geplant.
  • Nachdem diese Nodes vollständig geleert wurden, werden sie aus dem Node-Pool entfernt. Sie werden durch die durch den Surge hinzugefügten aktualisierten Nodes ersetzt.
  • 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 Updatekanal NodeImage verwenden. Dieser Kanal stellt wöchentlich ein aktualisiertes Node-Image-VHD bereit und wird entsprechend dem Wartungsfenster Ihres Clusters aktualisiert.

Zu den verfügbaren Kanälen gehören:

  • None. Es werden keine Updates automatisch ausgeführt.
  • Unmanaged. Ubuntu- und Azure Linux-Updates werden vom Betriebssystem jede Nacht ausgeführt. Neustarts müssen separat verwaltet werden. AKS ist weder in der Lage, dies zu testen noch die Intervalle zu steuern.
  • SecurityPatch. Betriebssystem-Sicherheitspatches, die von AKS getestet und vollständig verwaltet werden und sich nach sicheren Bereitstellungsverfahren richten. Umfasst keine Betriebssystem-Fehlerkorrekturen, sondern lediglich Sicherheitsupdates.
  • NodeImage. AKS aktualisiert die Knoten im wöchentlichen Rhythmus mit einer neu gepatchten VHD, die Sicherheits- und Fehlerkorrekturen enthält. Dies wird vollständig getestet und mit sicheren 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. Die Option Unmanaged umfasst keine von AKS bereitgestellten, sicheren Bereitstellungsmethoden und funktioniert nicht nach Wartungsfenstern. Wenn Sie den Updatekanal SecurityPatch wählen, können Updates wöchentlich ausgeführt werden. Für diese Patch-Ebene müssen die VHDs in Ihrer Ressourcengruppe gespeichert werden, wofür eine Gebühr anfällt. Entscheiden Sie, wann SecurityPatch angewandt wird, indem Sie einen geeigneten aksManagedNodeOSUpgradeSchedule festlegen, der sich an einer für Ihre Workload am besten geeigneten Häufigkeit richtet. Weitere Informationen finden Sie unter Erstellen eines Wartungsfensters. 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.

Als bewährte Methode empfiehlt sich die Verwendung des Updatekanals NodeImage und das Konfigurieren eines aksManagedNodeOSUpgradeSchedule-Wartungsfensters außerhalb der Spitzennutzungszeit des Clusters. Weitere Informationen zu den Attributen zum Konfigurieren des Wartungsfensters für den Cluster 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.

In diesem Beispiel wird ein wöchentliches Wartungsfenster auf 8:00 PM Eastern Time an Samstagen 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

Weitere Beispiele finden Sie unter Hinzufügen einer Wartungsfensterkonfiguration mithilfe der Azure CLI.

Diese Konfiguration würde im Idealfall im Rahmen der Infrastructure-as-Code-Bereitstellung des Clusters bereitgestellt.

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 wird nach Möglichkeit innerhalb des konfigurierten Fensters vorgenommen, aber der Zeitpunkt der Wartung ist nicht garantiert.

Wichtig

Wenn Sie über einen Knotenpool mit einer großen Anzahl von Knoten verfügen, der jedoch nicht mit Knotenanstiegen konfiguriert sind, wird das automatische Upgradeereignis möglicherweise nicht ausgelöst. Für Knotenimages in einem Knotenpool wird ein Upgrade nur dann durchgeführt, wenn die geschätzte Gesamtupgradezeit maximal 24 Stunden beträgt.

In dieser Situation können Sie eine der folgenden Möglichkeiten in Betracht ziehen:

  • Aufteilen der Knoten in verschiedene Knotenpools, wenn Ihr vCPU-Kontingent fast erschöpft ist und Sie das vCPU-Kontingent nicht erhöhen können
  • Konfigurieren von Knotenanstiegen, um die geschätzte Upgradezeit zu verringern, wenn Ihr vCPU-Kontingent ausreichend ist

Sie können den Status von Upgrade-Ereignissen über Ihre Azure-Aktivitätsprotokolle überprüfen oder die Ressourcenprotokolle in Ihrem Cluster überprüfen.

Sie können Azure Kubernetes Service(AKS)-Ereignisse mit Azure Event Grid abonnieren, die AKS-Upgrade-Ereignisse umfassen. Diese Ereignisse können Sie benachrichtigen, wenn eine neue Version von Kubernetes verfügbar ist, und beim Nachverfolgen von Knotenstatusänderungen bei Upgrade-Prozessen helfen.

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.0-1041-azure
  OS Image:                   Ubuntu 22.04.2 LTS
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.1+azure-1
  Kubelet Version:            v1.26.6
  Kube-Proxy Version:         v1.26.6

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 az aks nodepool get-upgrades, um die neueste verfügbare Node-Image-Version für einen bestimmten Node-Pool zu ermitteln:

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

Beispielausgabe:

KubernetesVersion    LatestNodeImageVersion                         Name     OsType
-------------------  ---------------------------------------------  -------  --------
1.26.6               AKSUbuntu-2204gen2arm64containerd-202308.10.0  default  Linux

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 hält sich an eine N - 2-Supportrichtlinie, was bedeutet, dass der vollständige Support für das neueste Release (N) und die zwei letzten Nebenversionen erbracht wird. Ein eingeschränkter Plattformsupport wird für die drittletzte Nebenversion angeboten. Weitere Informationen finden Sie unter AKS-Supportrichtlinie.

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. Diese Vorgehensweise kann die Vorhersehbarkeit in Ihrem Upgrade-Prozess wahren und Unterbrechungen von Anwendungen minimieren. Weitere Informationen finden Sie unter Aktualisieren eines AKS-Clusters.

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 beinhaltet ein Node-Upgrade und verwendet einen ähnlichen Sperr- und Leerprozess.

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 Ihnen beim Upgrade-Prozess behilflich sein:

  • AKS-Arbeitsmappe für veraltete APIs. Auf der Clusterübersichtsseite im Azure-Portal können Sie Diagnose und Problembehandlung auswählen, zur Kategorie Erstellen, Aktualisieren, Löschen und Skalieren gehen und dann Veraltete Kubernetes-APIs auswählen. Dadurch wird eine Arbeitsmappe ausgeführt, die nach veralteten API-Versionen sucht, die in Ihrem Cluster verwendet werden. Weitere Informationen finden Sie unter Entfernung der Verwendung veralteter APIs.
  • Seite mit 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.
  • Seite mit Kubernetes-Versionshinweisen. Diese Seite enthält detaillierte Einblicke in die neuesten Kubernetes-Versionen. Achten Sie besonders auf dringende Upgrade-Hinweise, die wichtige Informationen hervorheben, 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 diese Anleitung heranziehen, können Sie potenzielle Kompatibilitätsprobleme vor dem Upgrade-Prozess proaktiv 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

Sie können überprüfen, ob Ihr Cluster ein Upgrade benötigt, indem Sie mit az aks get-upgrades eine Liste der verfügbaren Upgradeversionen für Ihren AKS-Cluster abrufen. Ermitteln Sie die Zielversion für Ihren Cluster aus den Ergebnissen.

Hier sehen Sie ein Beispiel:

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

Beispielausgabe:

MasterVersion  Upgrades
-------------  ---------------------------------
1.26.6         1.27.1, 1.27.3

Überprüfen Sie die Kubernetes-Versionen der Nodes in Ihren Node-Pools, um die Pools zu ermitteln, bei denen ein Upgrade nötig ist:

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

Beispielausgabe:

Name          K8version
------------  ------------
systempool    1.26.6
usernodepool  1.26.6

Manuelles Upgrade

Um Unterbrechungen zu minimieren und ein reibungsloses Upgrade für Ihren AKS-Cluster sicherzustellen, sollten Sie wie folgt vorgehen:

  1. Nehmen Sie ein Upgrade der AKS-Steuerungsebene vor. Beginnen Sie mit dem Upgrade der AKS-Steuerungsebene. Dieser Schritt umfasst das Upgrade der Komponenten der Steuerungsebene, die für die Verwaltung und Orchestrierung Ihres Clusters verantwortlich sind. Das Upgrade der Steuerungsebene sorgt dafür, dass vor dem Upgrade der einzelnen Node-Pools erst einmal die Kompatibilität und Stabilität sichergestellt werden.
  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. Node-Pools bestehen aus den Instanzen der virtuellen Maschine, 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. Ausführliche Erläuterung der Schritte:

  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 az aks nodepool upgrade aus, um die Knotenpools auf die Zielversion upzugraden:

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

    Während des Upgrades des Node-Pools erstellt AKS einen Surge-Node, sperrt und leert Pods in dem zu aktualisierenden Nodes, führt ein Reimaging des Nodes durch und entsperrt dann die Pods. Dieser Vorgang wird dann für alle anderen Nodes im Node-Pool 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.

Registrieren von Clustern in Releasekanälen für automatisches Upgrade

AKS bietet auch eine Lösung für automatische Clusterupgrades, 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 Clusterupgrade bietet verschiedene Optionen für den Release-Kanal. Hier ist eine empfohlene Umgebungs- und Release-Kanal-Konfiguration:

Environment Upgrade-Kanal BESCHREIBUNG
Produktion stable Im Hinblick auf Stabilität und Versionsreife verwenden Sie für Workloads in der Produktion den stabilen bzw. regulären Kanal.
Staging, Test, Entwicklung Identisch mit Produktion Um sicherzustellen, dass Ihre Tests aussagekräftig sind für die Version, auf die Ihre Produktionsumgebung aktualisiert wird, müssen Sie denselben Release-Kanal wie für die Produktion verwenden.
Canary rapid Verwenden Sie zum Testen der neuesten Kubernetes-Releases und neuen AKS-Features oder APIs den Kanal rapid. Sie können die Markteinführung beschleunigen, wenn die Version in rapid auf den Kanal heraufgestuft wird, den Sie in der Produktion verwenden.

Überlegungen

In der folgenden Tabelle werden die Merkmale verschiedener Upgrade- und Patch-Szenarien für AKS beschrieben:

Szenario Vom Benutzer initiiert Kubernetes-Upgrades Betriebssystem-Kernelupgrade Node-Image-Upgrade
Sicherheitspatches Nein No Ja, nach dem Neustart Ja
Erstellen von Linux-basierten Clustern in HDInsight mit dem .NET-SDK Ja Vielleicht Ja, wenn ein aktualisiertes Node-Image einen aktualisierten Kernel verwendet Ja, relativ zu einem vorhandenen Cluster, wenn ein neues Release verfügbar ist
Kubernetes-Upgrade der Steuerungsebene Ja Ja Nr. No
Kubernetes-Upgrade des Node-Pools Ja Ja Ja, wenn ein aktualisiertes Node-Image einen aktualisierten Kernel verwendet Ja, wenn ein neues Release verfügbar ist
Hochskalierung des Node-Pools Ja Nr. Nr. Nein
Node-Image-Upgrade Ja No Ja, wenn ein aktualisiertes Node-Image einen aktualisierten Kernel verwendet Ja
Automatisches Clusterupgrade No Ja Ja, wenn ein aktualisiertes Node-Image einen aktualisierten Kernel verwendet Ja, wenn ein neues Release verfügbar ist
  • Ein Sicherheitsupdate für das Betriebssystem, das im Rahmen eines Node-Image-Upgrades ausgeführt wird, kann eine höhere Version des Kernels installieren als bei der Erstellung eines neuen Clusters.
  • Beim Hochskalieren des Node-Pools wird das Modell verwendet, das derzeit der VM-Skalierungsgruppe zugeordnet ist. Für die Betriebssystemkernels erfolgt das Upgrade, wenn Sicherheitsupdates ausgeführt und die Nodes neu gestartet werden.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Andere Mitwirkende:

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

Nächste Schritte