Freigeben über

Durchführen eines Upgrades für einen Azure Kubernetes Service-Cluster (AKS)

Im Rahmen des AKS-Clusterlebenszyklus müssen regelmäßige Upgrades auf die aktuelle Kubernetes-Version ausgeführt werden. Es ist wichtig, jeweils die aktuellen Sicherheitsversionen und Upgrades anzuwenden, um die neuesten Features zu erhalten. In diesem Artikel erfahren Sie, wie Sie auf Upgrades für Ihren AKS-Cluster überprüfen und diese anwenden.

Upgrades von Kubernetes-Versionen

Wichtig

Beim Upgrade eines unterstützten AKS-Clusters können Sie Nebenversionen von Kubernetes nicht überspringen. Sie müssen alle Upgrades in der Reihenfolge der Unterversionsnummer ausführen. Upgrades zwischen 1.14.x und >1.15.x oder 1.15.x und >1.16.x sind beispielsweise zulässig. 1.14.x und >1.16.x ist nicht zulässig. Sie können nur dann mehrere Versionen überspringen, wenn Sie ein Upgrade von einer nicht unterstützten Version auf eine unterstützte Version vornehmen. Sie können z. B. ein Upgrade von einer nicht unterstützten 1.10.x auf eine unterstützte 1.12.x durchführen, falls verfügbar.

Wenn Sie ein Upgrade von einer nicht unterstützten Version durchführen, das zwei oder mehr Nebenversionen überspringt, hat das Upgrade keine Garantie hinsichtlich der Funktionalität und ist von den Vereinbarungen zum Servicelevel und der eingeschränkten Garantie ausgeschlossen. Wenn Ihre Version nicht mehr aktuell ist, empfiehlt es sich, stattdessen den Cluster neu zu erstellen.

Bevor Sie beginnen

  • Bei Verwendung der Azure CLI ist für diesen Artikel Azure CLI-Version 2.34.1 oder höher erforderlich. Führen Sie az --version aus, um die Version zu ermitteln. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.
  • Wenn Sie Azure PowerShell verwenden, erfordert dieser Artikel die Azure PowerShell-Version 5.9.0 oder höher. Führen Sie Get-InstalledModule -Name Az aus, um die Version zu ermitteln. Falls Sie eine Installation oder ein Upgrade ausführen müssen, finden Sie unter Installieren von Azure PowerShell weitere Informationen.
  • Das Ausführen von Upgradevorgängen erfordert die RBAC-Rolle Microsoft.ContainerService/managedClusters/agentPools/write. Weitere Informationen zu Azure RBAC-Rollen finden Sie unter Vorgänge mit dem Azure-Ressourcenanbieter.
  • Ab Version 1.30 von Kubernetes und 1.27 LTS-Versionen werden die Beta-APIs standardmäßig deaktiviert, wenn Sie ein Upgrade auf sie durchführen.

Warnung

Durch ein Upgrade des AKS-Clusters werden Ihre Knoten gesperrt und geleert. Wenn Sie nur über ein geringes Computekontingent verfügen, kann das Upgrade möglicherweise nicht durchgeführt werden. Weitere Informationen finden Sie unter Kontingenterhöhung.

Suchen nach verfügbaren AKS-Cluster-Upgrades

Hinweis

Wenn Sie über AKS-Fixes, -Versionen und -Updates auf dem neuesten Stand bleiben möchten, ziehen Sie den AKS Release-Tracker zu Rate.

  • Überprüfen Sie, welche Kubernetes-Releases für Ihren Cluster verfügbar sind, indem Sie den Befehl az aks get-upgrades verwenden.

    az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

    Die folgende Beispielausgabe zeigt die aktuelle Version als 1.26.6 an und führt die verfügbaren Versionen unter upgrades auf:

    {
  "agentPoolProfiles": null,
  "controlPlaneProfile": {
    "kubernetesVersion": "1.26.6",
    ...
    "upgrades": [
      {
        "isPreview": null,
        "kubernetesVersion": "1.27.1"
      },
      {
        "isPreview": null,
        "kubernetesVersion": "1.27.3"
      }
    ]
  },
  ...
}

Problembehandlung bei Fehlermeldungen zu AKS-Clusterupgrades

Die folgende Beispielausgabe bedeutet, dass die Erweiterung appservice-kube nicht mit Ihrer Azure CLI-Version kompatibel ist (mindestens Version 2.34.1 ist erforderlich):

The 'appservice-kube' extension is not compatible with this version of the CLI.
You have CLI core version 2.0.81 and this extension requires a min of 2.34.1.
Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.

Wenn Sie diese Ausgabe erhalten, müssen Sie Ihre Azure CLI-Version aktualisieren. Der Befehl az upgrade wurde in Version 2.11.0 hinzugefügt und funktioniert nicht mit Versionen vor 2.11.0. Sie können ältere Versionen durch eine Neuinstallation der Azure CLI aktualisieren (siehe Installieren der Azure CLI). Wenn Ihre Azure CLI-Version 2.11.0 oder höher ist, führen Sie az upgrade aus, um Azure CLI auf die neueste Version zu aktualisieren.

Wenn Ihre Azure CLI aktualisiert wird und Sie die folgende Beispielausgabe erhalten, bedeutet dies, dass keine Upgrades verfügbar sind:

ERROR: Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.

Wenn kein Upgrade verfügbar ist, erstellen Sie einen neuen Cluster mit einer unterstützten Version von Kubernetes, und migrieren Sie Ihre Workloads vom vorhandenen Cluster zum neuen Cluster. AKS unterstützt das Upgrade eines Clusters auf eine neuere Kubernetes-Version nicht, wenn az aks get-upgrades angezeigt wird, dass keine Upgrades verfügbar sind.

Aktualisieren eines AKS-Clusters

Während des Clusterupgradeprozesses führt AKS die folgenden Vorgänge aus:

  • AKS fügt dem Cluster, auf dem die angegebene Kubernetes-Version ausgeführt wird, einen neuen Pufferknoten (oder die in max surge konfigurierte Anzahl von Knoten) hinzu.
  • Führen Sie eine Absperrung und einen Ausgleich eines der alten Knotenpunkte durch, um die Unterbrechung der ausgeführten Anwendungen zu minimieren. Wenn Sie max surge verwenden, werden so viele Knoten gleichzeitig abgesperrt und entleert, wie die Anzahl der angegebenen Pufferknoten beträgt.
  • Für zeitintensive Pods können Sie das Timeout für den Knotenausgleich konfigurieren, wodurch benutzerdefinierte Wartezeiten für die Entfernung von Pods und eine ordnungsgemäße Beendigung pro Knoten möglich sind. Sofern nicht angegeben, wird der Wert standardmäßig auf 30 Minuten festgelegt. Der Minimale zulässige Timeoutwert beträgt 5 Minuten. Der maximale Grenzwert für den Entwässerungstimeout beträgt 24 Stunden.
  • Wenn der alte Knoten vollständig ausgeglichen wurde, wird für diesen ein Reimaging durchgeführt, damit er die neue Version erhält. Er wird dann zum Pufferknoten, damit der folgende Knoten aktualisiert werden kann.
  • Optional können Sie eine Zeitspanne festlegen, die zwischen der Entleerung eines Knotens und dem erneuten Aufspielen des Knotens und dem Übergang zum nächsten Knoten vergehen soll. Ein kurzes Intervall ermöglicht es Ihnen, während des Upgrade-Prozesses andere Aufgaben zu erledigen, wie z. B. die Überprüfung des Anwendungsstatus über ein Grafana-Dashboard. Wir empfehlen einen kurzen Zeitrahmen für den Upgrade-Prozess, der so nah wie möglich an 0 Minuten liegt. Andernfalls wirkt sich eine höhere Knotendurchlaufzeit darauf aus, wie lange es dauert, bis Sie ein Problem entdecken. Der Mindestwert für die Durchlaufzeit liegt bei 0 Minuten, der Höchstwert bei 30 Minuten. Wenn Sie hier nichts angeben, lautet der Standardwert 0 Minuten.
  • Dieser Prozess wird wiederholt, bis alle Knoten im Cluster aktualisiert sind.
  • Am Ende des Vorgangs wird der letzte Pufferknoten gelöscht, sodass die Anzahl der vorhandenen Agent-Knoten und der Zonensaldo beibehalten werden.

Hinweis

Ist kein Patch angegeben, wird der Cluster automatisch auf den neuesten GA-Patch der angegebenen Nebenversion aktualisiert. Wenn Sie beispielsweise --kubernetes-version auf 1.28 festlegen, wird ein Upgrade des Clusters auf 1.28.9 durchgeführt.

Weitere Informationen finden Sie unter Unterstützte Kubernetes-Nebenversionsupgrades in AKS.

  1. Führen Sie ein Upgrade Ihres Clusters mithilfe des Befehls az aks upgrade durch.

    az aks upgrade \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --kubernetes-version <KUBERNETES_VERSION>

  2. Überprüfen Sie mit dem Befehl az aks show, ob das Upgrade erfolgreich war.

    az aks show --resource-group myResourceGroup --name myAKSCluster --output table

    Die Ausgabe im folgenden Beispiel zeigt, dass im Cluster nun Version 1.27.3 ausgeführt wird:

    Name          Location    ResourceGroup    KubernetesVersion    ProvisioningState    Fqdn
------------  ----------  ---------------  -------------------  -------------------  ----------------------------------------------
myAKSCluster  eastus      myResourceGroup  1.27.3               Succeeded            myakscluster-dns-379cbbb9.hcp.eastus.azmk8s.io

Festlegen des Kanals für automatische Upgrades

Sie können einen Kanal für automatische Upgrades für Ihren Cluster festlegen. Weitere Informationen finden Sie unter Automatisches Upgraden eines AKS-Clusters.

Anpassen des Upgrades für Knotenanstiege

Wichtig

  • Knotenanstiege erfordern ein Abonnementkontingent für die angeforderte maximale Anstiegsanzahl für jeden Upgradevorgang. Beispielsweise umfasst ein Cluster mit fünf Knotenpools, von denen jeder vier Knoten enthält, insgesamt 20 Knoten. Wenn für jeden Knotenpool ein maximaler Anstiegswert von 50 % gilt, sind zusätzliche Compute- und IP-Kontingente von 10 Knoten (2 Knoten * 5 Pools) erforderlich, um das Upgrade abzuschließen.

  • Die Einstellung des maximalen Anstiegs für einen Knotenpools ist persistent. Diese Einstellung wird bei nachfolgenden Kubernetes-Upgrades oder bei Knotenversionsupgrades verwendet. Sie können den maximalen Anstiegswert für Ihre Knotenpools jederzeit ändern. Für Produktionsknotenpools wird ein maximaler Anstiegswert von 33 % empfohlen.

  • Wenn Sie Azure CNI verwenden, stellen Sie sicher, dass im Subnetz IPs verfügbar sind, um die IP-Anforderungen von Azure CNI zu erfüllen.

AKS konfiguriert Upgrades standardmäßig für einen Anstieg mit einem zusätzlichen Knoten. Ein Standardwert von 1 für die Einstellung des maximalen Anstiegs ermöglicht AKS das Minimieren von Workloadunterbrechungen, indem vor dem Absperren/Ausgleichen vorhandener Anwendungen ein zusätzlicher Knoten erstellt wird, um einen Knoten einer älteren Version zu ersetzen. Sie können den maximalen Anstiegswert pro Knotenpool anpassen. Wenn Sie den Wert für den maximalen Anstieg (max surge) erhöhen, wird der Upgradevorgang schneller abgeschlossen, und es kann zu Unterbrechungen während des Upgradevorgangs führen.

Beispielsweise ermöglicht ein max surge-Wert von 100% den schnellstmöglichen Upgradevorgang, führt aber auch dazu, dass alle Knoten im Knotenpool gleichzeitig ausgeglichen werden. Möglicherweise möchten Sie einen höheren Wert wie diesen für Testumgebungen verwenden. Für Produktionsknotenpools wird als Einstellung für max_surge33% empfohlen.

Für den maximalen Anstieg akzeptiert AKS sowohl ganzzahlige Werte als auch einen prozentualen Wert. Beispielsweise gibt ein ganzzahliger Wert von 5 fünf zusätzlichen Knoten an, die übersprungen werden sollen. Der Prozentwert 50% gibt einen Anstiegswert von der Hälfte der aktuellen Knoten im Pool an. Maximale Surge Percent-Werte können mindestens 1% und höchstens 100% betragen. Ein Prozentwert wird auf die nächste Knotenanzahl aufgerundet. Wenn der „Max Surge“-Wert höher als die erforderliche Anzahl von Knoten ist, die aktualisiert werden soll, wird die Anzahl der Knoten, die aktualisiert werden soll, für den „Max Surge“-Wert verwendet. Während eines Upgrades kann der maximale Anstiegswert mindestens 0 betragen und maximal der Anzahl von Knoten in Ihrem Knotenpool entsprechen. Sie können größere Werte festlegen, aber die maximale Anzahl von Knoten, die für den maximalen Anstieg verwendet wird, kann nicht auf einen Wert größer als die Anzahl der Knoten im Pool zum Zeitpunkt des Upgrades gesetzt werden.

Festlegen des maximalen Anstiegswerts

  • Legen Sie die maximalen Anstiegswerte für neue oder vorhandene Knotenpools mit dem az aks nodepool add- oder az aks nodepool update-Befehl fest.

    # Set max surge for a new node pool
az aks nodepool add --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33%

# Update max surge for an existing node pool 
az aks nodepool update --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 5

Anpassen nicht verfügbarer Knoten während des Upgrades (Vorschau)

Wichtig

  • maxSurge muss auf 0 gesetzt werden, damit maxUnavailable festgelegt werden kann. Die beiden Werte können nicht gleichzeitig aktiv sein.
  • maxUnavailable wird während des Upgradevorgangs keine Überspannungsknoten erstellen. Stattdessen sperrt die AKS jeweils nmaxUnavailable Knoten ab und verschiebt die Pods in andere Knoten im Agentpool. Dies kann zu Workloadunterbrechungen führen, wenn die Pods nicht geplant werden können.
  • maxUnavailable kann aufgrund nicht erfüllter PodDisruptionBudgets (PDBs) mehr Fehler verursachen, da weniger Ressourcen für Pods geplant werden. Sehen Sie sich die Problembehandlung für PodDisruptionBudgets für Gegenmaßnahmen an, wenn bei der Verwendung dieses Features Fehler auftreten.
  • Sie können maxUnavailable nicht für Systemknotenpools festlegen.

AKS kann auch Upgrades so konfigurieren, dass kein Überstandsknoten verwendet wird und die Knoten an Ort und Stelle aktualisiert werden. Der maxUnavailable Wert kann verwendet werden, um zu bestimmen, wie viele Knoten im vorhandenen Knotenpool abgeschottet und geleert werden können.

AKS akzeptiert sowohl ganzzahlige Werte als auch einen Prozentwert für maxUnavailable. Ein ganzzahliger Wert von 5 beispielsweise bedeutet, dass fünf Knoten von den vorhandenen Knoten im Knotenpool abgebunden werden. Ein Prozentwert von 50% gibt einen maxUnavailable Wert der Hälfte der aktuellen Knotenanzahl im Pool an. maxUnavailable Prozentwerte können mindestens 1% und höchstens 100% betragen. Ein Prozentwert wird auf die nächste Knotenanzahl aufgerundet. Während eines Upgrades kann der maxUnavailable Wert ein Minimum von 0 und ein Maximalwert sein, der der Anzahl der Knoten im Knotenpool entspricht.

MaxUnavailable-Wert festlegen

  • Legen Sie maxUnvailable Werte für neue oder vorhandene Knotenpools mithilfe des az aks nodepool add oder az aks nodepool update Befehls fest.

    # Set maxUnavailable for a new node pool
az aks nodepool add --name mynodepool --resource-group myResourceGroup --cluster-name myManagedCluster --max-surge 0 --max-unavailable 5
# Update maxUnavailable for an existing node pool 
az aks nodepool update --name mynodepool --resource-group myResourceGroup --cluster-name myManagedCluster --max-surge 0 --max-unavailable 5
# Set maxUnavailable at upgrade time for an existing node pool
az aks nodepool upgrade --name mynodepool --resource-group myResourceGroup --cluster-name myManagedCluster --max-surge 0 --max-unavailable 5

Festlegen des Timeoutwerts für den Knotenausgleich

Es kann vorkommen, dass Sie auf einem bestimmten Pod eine zeitintensive Arbeitslast haben, die während der Laufzeit nicht auf einen anderen Knoten verlagert werden kann, z. B. eine speicherintensive zustandsabhängige Arbeitslast, die fertig ausgeführt werden muss. In diesen Fällen können Sie ein Timeout für den Knotenausgleich konfigurieren, das von AKS im Upgradeworkflow berücksichtigt wird. Wenn kein Timeoutwert für den Knotenausgleich angegeben ist, beträgt der Standardwert 30 Minuten. Der minimale zulässige Entwässerungstimeout-Wert beträgt 5 Minuten, und das maximale Limit des Entwässerungstimeouts beträgt 24 Stunden.

Wenn der Timeoutwert entwässert und Pods noch ausgeführt werden, wird der Upgradevorgang beendet. Jeder nachfolgende PUT-Vorgang setzt das angehaltene Upgrade fort. Es wird auch empfohlen, für zeitintensive Pods die [terminationGracePeriodSeconds][https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/] zu konfigurieren.

  • Legen Sie den Timeout für das Entleeren von Knoten für neue oder vorhandene Knotenpools mithilfe des Befehls az aks nodepool add oder des Befehls az aks nodepool update fest.

    # Set drain time-out for a new node pool
az aks nodepool add --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster  --drain-time-out 100

# Update drain time-out for an existing node pool
az aks nodepool update --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --drain-time-out 45

Festlegen des Werts für die Knotendurchlaufzeit

Um eine Zeitdauer zuzulassen, die zwischen der Entleerung eines Knotens und dem erneuten Aufspielen des Knotens und dem Übergang zum nächsten Knoten vergehen soll, können Sie eine Knotendurchlaufzeit von 0 bis 30 Minuten festlegen. Wenn kein Wert für die Auslaufzeit des Knotens angegeben wird, beträgt der Standardwert 0 Minuten.

  • Legen Sie eine Knotendurchlaufzeit für neue oder vorhandene Knotenpools mit dem az aks nodepool add-, az aks nodepool update- oder az aks nodepool upgrade-Befehl fest.

    # Set node soak time for a new node pool
az aks nodepool add --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --node-soak-duration 10

# Update node soak time for an existing node pool
az aks nodepool update --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33% --node-soak-duration 5

# Set node soak time when upgrading an existing node pool
az aks nodepool upgrade --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33% --node-soak-duration 20

Upgrade durch erhebliche Versionsabweichungen

Beim Upgrade von einer nicht unterstützten Version von Kubernetes auf eine unterstützte Version ist es wichtig, Ihre Workloads auf der Zielversion zu testen. Während AKS alle Anstrengungen unternehmen wird, Ihre Steuerebene und Datenebene zu aktualisieren, gibt es keine Garantie dafür, dass Ihre Workloads weiterhin funktionieren. Wenn Ihre Workloads auf veraltete Kubernetes-APIs angewiesen sind und die Plattform umfassende Änderungen oder Verhaltensweisen eingeführt hat (wie in den AKS-Versionshinweisen dokumentiert), müssen diese behoben werden.

In diesen Situationen empfehlen wir, Ihre Workloads auf die neue Version zu testen und alle Versionsprobleme zu beheben, bevor Sie ein direktes Upgrade Ihres Clusters durchführen.

Ein häufiges Muster in dieser Situation besteht darin, eine blaue/grüne Bereitstellung Ihrer geänderten Workloads an einen neuen Cluster durchzuführen, der sich auf einer unterstützten Kubernetes-Version befindet, und Anforderungen an den neuen Cluster weiterzuleiten.

Anzeigen von Upgradeereignissen

  • Zeigen Sie Upgradeereignisse mithilfe des kubectl get events-Befehls an.

    kubectl get events

    Die folgende Beispielausgabe zeigt einige der oben aufgeführten Ereignisse während eines Upgrades:

    ...
default 2m1s Normal Drain node/aks-nodepool1-96663640-vmss000001 Draining node: [aks-nodepool1-96663640-vmss000001]
...
default 1m45s Normal Upgrade node/aks-nodepool1-96663640-vmss000001   Soak duration 5m0s after draining node: aks-nodepool1-96663640-vmss000001
...
default 9m22s Normal Surge node/aks-nodepool1-96663640-vmss000002 Created a surge node [aks-nodepool1-96663640-vmss000002 nodepool1] for agentpool nodepool1
...

Nächste Schritte

Informationen zum Konfigurieren von automatischen Upgrades finden Sie unter Konfigurieren automatischer Upgrades für einen AKS-Cluster.

Eine ausführliche Erläuterung zu bewährten Methoden für Upgrades und anderen Überlegungen finden Sie unter AKS Patch- und Upgradeanleitungen.