Version 1.15 Diese Version wird nicht mehr unterstützt. Informationen zum Upgrade auf Version 1.16 finden Sie in der aktuellen Dokumentation unter Cluster upgraden. Weitere Informationen zu unterstützten und nicht unterstützten Versionen finden Sie in der aktuellen Dokumentation auf der Seite Versionsverlauf.

Cluster aktualisieren

Wenn Sie eine neue Version von bmctl installieren, können Sie Ihre vorhandenen Cluster aktualisieren, die mit einer früheren Version erstellt wurden. Durch ein Upgrade eines Clusters auf die neueste GKE on Bare Metal-Version werden zusätzliche Features und Fehlerkorrekturen für den Cluster bereitgestellt. Außerdem wird dadurch sichergestellt, dass Ihr Cluster weiterhin unterstützt wird. Sie können Administrator-, Hybrid-, eigenständige oder Nutzercluster mit dem Befehl bmctl upgrade cluster oder mit kubectl upgraden.

Ab GKE on Bare Metal Version 1.15.0 ist das Standardverhalten für Upgrades für selbstverwaltete (Administrator-, Hybrid- oder eigenständige) Cluster ein direktes Upgrade. Direkte Upgrades verwenden Lebenszyklus-Controller anstelle eines Bootstrap-Clusters, um den gesamten Upgradeprozess zu verwalten. Diese Änderung vereinfacht den Prozess und verringert den Ressourcenbedarf, wodurch Clusterupgrades zuverlässiger und skalierbarer werden.

Weitere Informationen zum Upgradeprozess finden Sie unter Lebenszyklus und Phasen von Clusterupgrades.

Überlegungen zum Upgrade

Dieser Abschnitt enthält Informationen und Links zu Informationen, die Sie vor dem Upgrade eines Clusters berücksichtigen sollten.

Best Practices

Informationen zur Vorbereitung auf ein Clusterupgrade finden Sie unter Best Practices für Clusterupgrades von Anthos Clusters on Bare Metal.

Preflight-Prüfungen upgraden

Preflight-Prüfungen werden als Teil des Clusterupgrades ausgeführt, um den Clusterstatus und den Knotenzustand zu validieren. Das Clusterupgrade wird nicht fortgesetzt, wenn die Preflight-Prüfungen fehlschlagen. Weitere Informationen zu Preflight-Prüfungen finden Sie unter Preflight-Prüfungen verstehen.

Sie können prüfen, ob die Cluster für ein Upgrade bereit sind. Führen Sie dazu vor dem Upgrade die Preflight-Prüfung aus. Weitere Informationen finden Sie unter Preflight-Prüfungen auf Upgrades.

Bekannte Probleme

Informationen zu potenziellen Problemen im Zusammenhang mit Clusterupgrades finden Sie unter Bekannte Probleme bei Anthos Clusters on Bare Metal. Wählen Sie in diesem Fall die Problemkategorie Upgrades und Updates aus.

Administrator-, eigenständige, Hybrid- oder Nutzercluster aktualisieren

In diesem Abschnitt finden Sie eine Anleitung zum Upgraden von Clustern.

`bmctl`

Wenn Sie eine neue Version von bmctl herunterladen und installieren, können Sie Ihre Administrator-, Hybrid-, eigenständigen und Nutzer-Cluster aktualisieren, die mit einer früheren Version erstellt wurden. Bei einer bestimmten Version von bmctl können Cluster nur auf die gleiche Version aktualisiert werden.

Laden Sie die neueste bmctl wie unter GKE on Bare Metal-Downloads beschrieben herunter.
Aktualisieren Sie anthosBareMetalVersion in der Clusterkonfigurationsdatei auf die Upgrade-Zielversion.

Die Upgrade-Zielversion muss mit der Version der heruntergeladenen Datei bmctl übereinstimmen. Das folgende Snippet der Clusterkonfigurationsdatei zeigt das Feld anthosBareMetalVersion, das auf die neueste Version aktualisiert wurde:
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  type: admin
  # Anthos cluster version.
  anthosBareMetalVersion: 1.15.11
```
Verwenden Sie den Befehl bmctl upgrade cluster, um das Upgrade abzuschließen:
```
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Clusters, der aktualisiert werden soll.
- ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters.
Beim Clusterupgrade werden Preflight-Prüfungen ausgeführt, um den Clusterstatus und Knotenzustand zu validieren. Das Clusterupgrade wird nicht fortgesetzt, wenn die Preflight-Prüfungen fehlschlagen. Informationen zur Fehlerbehebung finden Sie unter Probleme bei der Installation oder beim Upgrade von Clustern beheben.

Wenn alle Clusterkomponenten erfolgreich aktualisiert wurden, führt das Clusterupgrade eine Cluster-Systemdiagnose aus. Mit diesem letzten Schritt wird überprüft, ob der Cluster in einem guten Betriebszustand ist. Wenn der Cluster nicht alle Systemdiagnosen besteht, werden sie weiter ausgeführt, bis sie bestanden sind. Wenn alle Systemdiagnosen bestanden sind, wird das Upgrade erfolgreich abgeschlossen.

Weitere Informationen zur Abfolge von Ereignissen für Clusterupgrades finden Sie unter Lebenszyklus und Phasen von Clusterupgrades.

`kubectl`

Führen Sie die folgenden Schritte aus, um einen Cluster mit kubectl zu aktualisieren:

Bearbeiten Sie die Clusterkonfigurationsdatei, um anthosBareMetalVersion auf die Upgrade-Zielversion festzulegen.
Führen Sie den folgenden Befehl aus, um das Upgrade zu initiieren:
```
kubectl apply -f CLUSTER_CONFIG_PATH
```
Ersetzen Sie CLUSTER_CONFIG_PATH durch den Pfad zur bearbeiteten Clusterkonfigurationsdatei.

Wie beim Upgradeprozess mit bmctl werden Preflight-Prüfungen im Rahmen des Clusterupgrades ausgeführt, um den Clusterstatus und Knotenzustand zu validieren. Wenn die Preflight-Prüfungen fehlschlagen, wird das Clusterupgrade angehalten. Um Fehler zu beheben, prüfen Sie den Cluster und die zugehörigen Logs, da kein Bootstrap-Cluster erstellt wird. Weitere Informationen finden Sie unter Probleme bei der Installation oder beim Upgrade von Clustern beheben.

Sie benötigen nicht die neueste Version von bmctl, um ein Upgrade für Cluter mit kubectl durchzuführen. Wir empfehlen jedoch, die aktuelle Version von bmctl herunterzuladen. Sie benötigen bmctl, um andere Aufgaben wie Systemdiagnosen und Sicherungen auszuführen und dafür zu sorgen, dass Ihr Cluster in einem einwandfreien Zustand bleibt.

Parallele Upgrades

Bei einem typischen Standardclusterupgrade wird jeder Clusterknoten nacheinander und nacheinander aktualisiert. In diesem Abschnitt erfahren Sie, wie Sie Ihre Cluster- und Worker-Knotenpools so konfigurieren, dass mehrere Knoten beim Upgrade des Clusters parallel aktualisiert werden. Das parallele Upgrade von Knoten beschleunigt Cluster-Upgrades erheblich, insbesondere bei Clustern mit Hunderten von Knoten.

Es gibt zwei parallele Upgradestrategien, mit denen Sie das Clusterupgrade beschleunigen können:

Gleichzeitiges Knotenupgrade: Sie können Ihre Worker-Knotenpools so konfigurieren, dass mehrere Knoten parallel aktualisiert werden. Parallele Upgrades von Knoten werden in der Knotenpoolspezifikation (spec.upgradeStrategy.parallelUpgrade) konfiguriert und nur Knoten in einem Worker-Knotenpool können parallel aktualisiert werden. Knoten in Steuerungsebenen- oder Load-Balancer-Knotenpools können jeweils nur einzeln aktualisiert werden. Weitere Informationen finden Sie unter Knotenupgrades.
Gleichzeitiges Knotenpoolupgrade: Sie können Ihren Cluster so konfigurieren, dass mehrere Knotenpools gleichzeitig aktualisiert werden. Nur Worker-Knotenpools können parallel aktualisiert werden. Knotenpools und Load-Balancer-Knotenpools können nur einzeln aktualisiert werden. Die Möglichkeit, mehrere Knotenpools gleichzeitig zu aktualisieren, ist in der öffentlichen Vorschau verfügbar. Weitere Informationen finden Sie unter Upgradestrategie für Knotenpools.

Strategie für Knotenupgrades

Sie können Worker-Knotenpools so konfigurieren, dass mehrere Knoten gleichzeitig aktualisiert werden (concurrentNodes). Außerdem haben Sie die Möglichkeit, einen Mindestgrenzwert für die Anzahl der Knoten festzulegen, die während des Upgrades ausgeführt werden können (minimumAvailableNodes). Diese Konfiguration wird in der Knotenpoolspezifikation vorgenommen. Weitere Informationen zu diesen Feldern finden Sie in der Referenz zum Clusterkonfigurationsfeld.

Die Strategie für Knotenupgrades gilt nur für Worker-Knotenpools. Sie können keine Knotenupgrade-Strategie für Steuerungsebenen- oder Load-Balancer-Knotenpools angeben. Während eines Clusterupgrades werden Knoten in der Steuerungsebene und in Load-Balancer-Knotenpools nacheinander und nacheinander aktualisiert. Knotenpools der Steuerungsebene und Knotenpools des Load-Balancers werden in der Clusterspezifikation angegeben (controlPlane.nodePoolSpec.nodes und loadBalancer.nodePoolSpec.nodes).

Beachten Sie die folgenden Einschränkungen, wenn Sie parallele Upgrades für Knoten konfigurieren:

Der Wert von concurrentNodes darf entweder 20 % der Anzahl der Knoten im Knotenpool oder 10 nicht überschreiten, je nachdem, welcher Wert kleiner ist. Wenn Ihr Knotenpool beispielsweise 40 Knoten hat, können Sie keinen Wert größer als 8 angeben. Wenn Ihr Knotenpool 100 Knoten hat, können Sie maximal 10 angeben.
Wenn Sie concurrentNodes zusammen mit minimumAvailableNodes verwenden, dürfen die kombinierten Werte die Gesamtzahl der Knoten im Knotenpool nicht überschreiten. Wenn Ihr Knotenpool beispielsweise 20 Knoten hat und minimumAvailableNodes auf 18 festgelegt ist, darf concurrentNodes nicht größer als 2 sein. Ebenso gilt: Wenn concurrentNodes auf 10 gesetzt ist, darf minimumAvailableNodes nicht größer als 10 sein.

Das folgende Beispiel zeigt den Worker-Knotenpool np1 mit 10 Knoten. Bei einem Upgrade werden Knoten zwei auf einmal aktualisiert und es müssen mindestens fünf Knoten verfügbar bleiben, damit das Upgrade fortgesetzt werden kann:

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  - address:  10.200.0.4
  - address:  10.200.0.5
  - address:  10.200.0.6
  - address:  10.200.0.7
  - address:  10.200.0.8
  - address:  10.200.0.9
  - address:  10.200.0.10 
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 2
      minimumAvailableNodes: 5

Upgradestrategie für Knotenpools

Sie können einen Cluster so konfigurieren, dass mehrere Worker-Knotenpools parallel aktualisiert werden. Das boolesche Feld nodePoolUpgradeStrategy.concurrentNodePools in der Clusterspezifikation gibt an, ob alle Worker-Knotenpools für einen Cluster gleichzeitig aktualisiert werden sollen. Standardmäßig (1) werden Knotenpools nacheinander und nacheinander aktualisiert. Wenn Sie concurrentNodePools auf 0 festlegen, wird jeder Worker-Knotenpool im Cluster parallel aktualisiert.

Knotenpools der Steuerungsebene und des Load-Balancings sind von dieser Einstellung nicht betroffen. Diese Knotenpools werden immer nacheinander und nacheinander aktualisiert. Knotenpools der Steuerungsebene und Knotenpools des Load-Balancers sind in der Clusterspezifikation angegeben (controlPlane.nodePoolSpec.nodes und loadBalancer.nodePoolSpec.nodes).

Die Möglichkeit, alle Worker-Knotenpools gleichzeitig zu aktualisieren, ist nur für die Vorabversion verfügbar. Verwenden Sie dieses Feature nicht in Ihren Produktionsclustern.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

Paralleles Upgrade durchführen

In diesem Abschnitt wird beschrieben, wie Sie einen Cluster und einen Worker-Knotenpool für parallele Upgrades konfigurieren.

So führen Sie ein paralleles Upgrade von Worker-Knotenpools und -knoten in einem Worker-Knotenpool aus:

Fügen Sie der Knotenpoolspezifikation einen Abschnitt upgradeStrategy hinzu.

Sie können dieses Manifest separat oder als Teil der Clusterkonfigurationsdatei anwenden, wenn Sie ein Clusterupdate ausführen.

Beispiel:
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-ci-bf8b9aa43c16c47
spec:
  clusterName: ci-bf8b9aa43c16c47
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.30
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 10
```
In diesem Beispiel ist der Wert des Felds concurrentNodes 5. Dies bedeutet, dass 5 Knoten parallel aktualisiert werden. Das Feld minimumAvailableNodes ist auf 10 gesetzt. Das bedeutet, dass während des Upgrades mindestens 10 Knoten für Arbeitslasten verfügbar bleiben müssen.

Hinweis: Sie können keine Upgradestrategie für Knoten für Steuerungsebenen- oder Load-Balancer-Knotenpools angeben.
Fügen Sie der Clusterspezifikation in der Clusterkonfigurationsdatei einen nodePoolUpgradeStrategy-Abschnitt hinzu.

Achtung: Das gleichzeitige Upgrade aller Worker-Knotenpools ist nur in der Vorabversion verfügbar. Verwenden Sie dieses Feature nicht in Ihren Produktionsclustern.
```
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user001
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.15.0
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...
```
In diesem Beispiel ist das Feld concurrentNodePools auf 0 gesetzt. Das bedeutet, dass alle Worker-Knotenpools während des Clusterupgrades gleichzeitig aktualisiert werden. Die Upgradestrategie für die Knoten in den Knotenpools ist in den NodePool-Spezifikationen definiert.
Führen Sie ein Upgrade des Clusters durch, wie im vorherigen Abschnitt Administrator-, eigenständige, Hybrid- oder Nutzercluster upgraden beschrieben.

Parallele Upgrades von Knoten deaktivieren

Parallele Upgrades sind standardmäßig deaktiviert und die Felder für parallele Upgrades sind änderbar. Sie können die Felder jederzeit entfernen oder auf ihre Standardwerte zurücksetzen, um das Feature vor einem nachfolgenden Upgrade zu deaktivieren.

In der folgenden Tabelle sind die Felder für parallele Upgrades und ihre Standardwerte aufgeführt:

Feld	Standardwert	Bedeutung
`nodePoolUpgradeStrategy.concurrentNodePools` (Clusterspezifikation)	`1`	Führen Sie ein sequenzielles Upgrade der Worker-Knotenpools durch.
`upgradeStrategy.parallelUpgrade.concurrentNodes` (NodePool-Spezifikation)	`1`	Führen Sie ein sequenzielles Upgrade der Knoten nacheinander durch.
`upgradeStrategy.parallelUpgrade.minimumAvailableNodes` (NodePool-Spezifikation)	`0`	Es muss nicht sichergestellt werden, dass während eines Upgrades Knoten verfügbar sind.