Anthos Clusters on Bare Metal sind jetzt Google Distributed Cloud (nur Software) für Bare Metal. Weitere Informationen finden Sie in der Produktübersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

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 Version von Google Distributed Cloud erhalten Sie zusätzliche Funktionen und Fehlerkorrekturen für Ihren Cluster. Außerdem wird Ihr Cluster weiterhin unterstützt. Mit dem Befehl bmctl upgrade cluster oder kubectl können Sie Administrator-, Hybrid-, eigenständige oder Nutzercluster upgraden.

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

Upgrade planen

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 Google Distributed Cloud-Clusterupgrades.

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 Informationen zu Preflight-Prüfungen.

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

Bekannte Probleme

Informationen zu potenziellen Problemen im Zusammenhang mit Clusterupgrades finden Sie unter Bekannte Probleme bei Google Distributed Cloud for Bare Metal. Wählen Sie die Problemkategorie Upgrades und Updates aus.

Upgradeoptionen konfigurieren

Bevor Sie ein Clusterupgrade starten, können Sie die folgenden Upgradeoptionen konfigurieren, die die Funktionsweise des Upgrades steuern:

Selektive Upgrades von Worker-Knotenpools: Führen Sie ein Upgrade bestimmter Worker-Knotenpools getrennt vom Rest des Clusters durch.
Parallele Upgrades: Konfigurieren Sie den Upgradeprozess so, dass Gruppen von Knoten oder Knotenpools gleichzeitig aktualisiert werden.

Diese Optionen können das Risiko von Unterbrechungen kritischer Anwendungen und Dienste reduzieren und die Upgradezeit insgesamt erheblich reduzieren. Diese Optionen sind besonders nützlich für große Cluster mit zahlreichen Knoten und Knotenpools, auf denen wichtige Arbeitslasten ausgeführt werden. Weitere Informationen zur Funktion und Verwendung dieser Optionen finden Sie in den folgenden Abschnitten.

Selektive Upgrades von Worker-Knotenpools

Standardmäßig aktualisiert der Vorgang des Clusterupgrades jeden Knoten und Knotenpool im Cluster. Ein Clusterupgrade kann störend und zeitaufwendig sein, da jeder Knoten per Drain beendet und alle zugehörigen Pods neu gestartet und neu geplant werden. In diesem Abschnitt wird beschrieben, wie Sie ausgewählte Worker-Knotenpools für ein Clusterupgrade ein- oder ausschließen, um Unterbrechungen der Arbeitslast zu minimieren. Dieses Feature gilt nur für Nutzer-, Hybrid- und eigenständige Cluster, da Administratorcluster keine Worker-Knotenpools zulassen.

Sie können selektive Knotenpoolupgrades in den folgenden Situationen verwenden:

So nehmen Sie Sicherheitsupdates vor, ohne Arbeitslasten zu unterbrechen: Sie können nur für die Knoten der Steuerungsebene (und die Load-Balancer-Knoten) ein Upgrade durchführen, um Fehlerkorrekturen für Kubernetes-Sicherheitslücken anzuwenden, ohne Ihre Worker-Knotenpools zu beeinträchtigen.
So prüfen Sie vor dem Upgrade aller Worker-Knoten den ordnungsgemäßen Betrieb einer aktualisierten Teilmenge von Worker-Knoten: Sie können Ihre Worker-Knotenpools gezielt upgraden, um sicherzustellen, dass Arbeitslasten in einem aktualisierten Knotenpool ordnungsgemäß ausgeführt werden, bevor Sie ein Upgrade eines weiteren Knotenpools durchführen.
Wartungsfenster verkürzen: Das Upgrade eines großen Clusters kann zeitaufwendig sein und es lässt sich nur schwer genau vorhersagen, wann ein Upgrade abgeschlossen ist. Die Zeit für das Clusterupgrade ist proportional zur Anzahl der aktualisierten Knoten. Wenn Sie die Anzahl der zu aktualisierenden Knoten reduzieren, indem Sie Knotenpools ausschließen, verkürzt sich die Zeit für das Upgrade. Sie führen mehrmals ein Upgrade durch, aber die kleineren, besser vorhersehbaren Wartungsfenster können bei der Planung helfen.

Zwei Nebenversionen des Knotenpools abweichender Versionen

Bei Clustern der Version 1.28 und höher kann die Version eines Worker-Knotenpools bis zu zwei Nebenversionen hinter der Version des Clusters (Steuerungsebene) liegen. Mit der Unterstützung für n-2-Versionsabweichungen können Sie eine Nebenversion auch überspringen, wenn Sie einen Worker-Knotenpool von zwei Nebenversionen hinter dem Cluster auf dieselbe Nebenversion wie der Cluster aktualisieren.

Diese n-2-Versionsverzerrung für Worker-Knotenpools bietet Ihnen mehr Flexibilität bei der Planung Ihrer Flottenupgrades.

Wenn Sie beispielsweise einen Cluster der Version 1.28 haben, können Sie Worker-Knotenpools mit ausgewählten Versionen der Versionen 1.28, 1.16 und 1.15 haben. Zum Upgrade Ihres Clusters auf Version 1.29 müssen Sie zuerst einen beliebigen 1.15-Worker-Knotenpool auf eine unterstützte Version für den Cluster vor dem Upgrade auf Version 1.28 aktualisieren. Sie müssen Worker-Knotenpools der Version 1.16 nicht auf Version 1.28 aktualisieren, bevor Sie Ihren Cluster auf Version 1.29 aktualisieren können. Nachdem das Upgrade des Clusters auf Version 1.29 durchgeführt wurde, können Sie bei der Entscheidung für ein Upgrade der Worker-Knotenpools der Version 1.16 auf Version 1.29 in einem einzigen Schritt ein Upgrade ausführen und Version 1.28 überspringen.

Weitere Informationen, einschließlich Listen der unterstützten Versionen von Worker-Knotenpools, die von einer bestimmten Clusterversion unterstützt werden, finden Sie unter Versionsverwaltungsregeln für Knotenpools.

1,29

In Version 1.29 ist die Unterstützung einer n-2-Versionsabweichung für Worker-Knotenpools allgemein für alle Clustertypen verfügbar. Dieses Feature ist standardmäßig für Cluster ab Version 1.29 aktiviert.

Während wir dieses Feature von der öffentlichen Vorschau auf die allgemeine Verfügbarkeit umstellen, benötigen Hybridcluster in der folgenden Situation weiterhin die Vorschauanmerkung. Wenn Sie einen Hybridcluster der Version 1.28.x mit einem Worker-Knotenpool der Version 1.16.y haben, müssen Sie dem Cluster die Annotation preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable hinzufügen, bevor Sie ein Upgrade auf Version 1.29.z durchführen:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.28.400-gke.77
  ...

1,28

Die Unterstützung einer n-2-Versionsabweichung für Worker-Knotenpools ist in Version 1.28 als Vorabversion verfügbar. Fügen Sie der Clusterkonfigurationsdatei die Annotation preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable hinzu, um diese Vorschaufunktion zu aktivieren:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
...

Wenn Sie diese Vorschaufunktion nicht aktivieren, beträgt die maximale Versionsabweichung zwischen einem Worker-Knotenpool und dem Cluster eine Nebenversion.

Weitere Informationen zu den Versionierungsregeln für das selektive Upgrade von Worker-Knotenpools finden Sie unter Versionsverwaltungsregeln für Knotenpools unter „Lebenszyklus und Phasen von Clusterupgrades“.

Upgrade der Cluster-Steuerungsebene und ausgewählter Knotenpools durchführen

So aktualisieren Sie selektiv Worker-Knotenpools beim ersten Clusterupgrade:

Nehmen Sie für die Worker-Knotenpools, die Sie in das Clusterupgrade einschließen möchten, eine der folgenden Änderungen an der Knotenpoolspezifikation vor:
- Legen Sie anthosBareMetalVersion in der Knotenpoolspezifikation auf die Upgradeversion des Clusterziels fest.
- Lassen Sie das Feld anthosBareMetalVersion in der Knotenpoolspezifikation aus oder geben Sie einen leeren String an. Standardmäßig sind Worker-Knotenpools in Clusterupgrades enthalten.
Legen Sie für die Worker-Knotenpools, die Sie vom Upgrade ausschließen möchten, für anthosBareMetalVersion die aktuelle Version (vor dem Upgrade) des Clusters fest:
Fahren Sie mit dem Upgrade fort, wie unter Clusterupgrade starten beschrieben.

Der Clusterupgrade-Vorgang aktualisiert die folgenden Knoten:
- Knoten der Cluster-Steuerungsebene.
- Load-Balancer-Knotenpool, wenn Ihr Cluster einen verwendet (spec.loadBalancer.nodePoolSpec). Standardmäßig können Load-Balancer-Knoten reguläre Arbeitslasten ausführen. Ein Load-Balancer-Knotenpool kann nicht selektiv aktualisiert werden. Er ist immer im ersten Clusterupgrade enthalten.
- Worker-Knotenpools, die Sie nicht vom Upgrade ausgeschlossen haben.

Angenommen, Ihr Cluster verwendet die Version 1.28.0 und hat zwei Worker-Knotenpools: wpool01 und wpool02. Angenommen, Sie möchten die Steuerungsebene und wpool01 auf 1.29.100-gke.251 aktualisieren, aber wpool02 soll bei Version 1.28.0 bleiben.

Der folgende Auszug aus der Clusterkonfigurationsdatei zeigt, wie Sie die Clusterkonfiguration ändern können, um dieses teilweise Upgrade zu unterstützen:

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.100-gke.251
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.0
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

Knotenpools auf die aktuelle Clusterversion upgraden

Wenn Sie Knotenpools von einem Clusterupgrade ausgeschlossen haben, können Sie ein Clusterupgrade ausführen, um sie auf die Zielclusterversion zu bringen. Bei Worker-Knotenpools, die von einem Clusterupgrade ausgeschlossen wurden, ist das Feld anthosBareMetalVersion in der Spezifikation NodePool auf die vorherige Clusterversion (vor dem Upgrade) festgelegt.

So bringen Sie Worker-Knotenpools auf die aktuelle aktualisierte Clusterversion zurück:

Bearbeiten Sie die NodePool-Spezifikationen in der Clusterkonfigurationsdatei für die Worker-Knotenpools, die Sie auf die aktuelle Clusterversion umstellen möchten. Legen Sie anthosBareMetalVersion auf die aktuelle Clusterversion (nach dem Upgrade) fest.

Wenn mehrere Worker-Knotenpools für das Upgrade ausgewählt werden, bestimmt der Wert spec.nodePoolUpgradeStrategy.concurrentNodePools in der Clusterspezifikation, wie viele Knotenpools gegebenenfalls parallel aktualisiert werden. Wenn Sie Worker-Knotenpools nicht gleichzeitig aktualisieren möchten, wählen Sie jeweils nur einen Knotenpool für das Upgrade aus.
Fahren Sie mit dem Upgrade fort, wie unter Clusterupgrade starten beschrieben.

Beim Clusterupgrade werden nur die zuvor ausgeschlossenen Worker-Knotenpools, für die Sie anthosBareMetalVersion festgelegt haben, auf die aktuelle aktualisierte Clusterversion aktualisiert.

Angenommen, Sie haben den Cluster auf Version 1.29.100-gke.251 aktualisiert, aber der Knotenpool wpool02 verwendet noch die alte Clusterversion 1.28.0 vor dem Upgrade. Da Arbeitslasten auf dem aktualisierten Knotenpool wpool01 ordnungsgemäß ausgeführt werden, sollten Sie wpool02 jetzt auch auf die aktuelle Clusterversion umstellen. Zum Upgraden von wpool02 können Sie das Feld anthosBareMetalVersion entfernen oder seinen Wert auf einen leeren String festlegen.

Der folgende Auszug aus der Clusterkonfigurationsdatei zeigt, wie Sie die Clusterkonfiguration ändern können, um dieses teilweise Upgrade zu unterstützen:

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.100-gke.251
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: ""
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

Rollback für Knotenpool-Upgrade durchführen

Es gibt viele Abhängigkeiten, die die Leistung Ihrer Arbeitslasten beeinflussen können, z. B. die Kompatibilität mit Kubelet oder Plug-ins. Falls nach dem Upgrade eines Worker-Knotenpools ein Problem auftritt, können Sie ein Rollback des Knotenpools auf seine vorherige Version durchführen.

Die Knotenpool-Rollback-Funktion ist in der Vorabversion für Cluster der Version 1.29 (Cluster mit Knoten der Steuerungsebene ab Version 1.29) verfügbar. Solange sich dieses Feature in der Vorabversion befindet, müssen Sie der Ressource Cluster die Annotation preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable hinzufügen, um das Feature zu aktivieren.

Führen Sie die folgenden Schritte aus, um ein Rollback für ein Knotenpoolupgrade durchzuführen:

`bmctl`

Wenn Sie bmctl für das Rollback eines Knotenpoolupgrades verwenden, bearbeiten Sie die Clusterkonfigurationsdatei und wenden Ihre Änderungen mit dem Befehl bmctl update an:

Bearbeiten Sie die NodePool-Spezifikationen in der Clusterkonfigurationsdatei für die Worker-Knotenpools, die auf die vorherige Version zurückgesetzt werden sollen. Legen Sie für anthosBareMetalVersion die vorherige Clusterversion (vor dem Upgrade) fest.
```
...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.600-gke.163
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
```
Wenn mehrere Worker-Knotenpools für das Rollback ausgewählt werden, bestimmt der Wert von spec.nodePoolUpgradeStrategy.concurrentNodePools in der Clusterspezifikation, für wie viele Knotenpools parallel ein Rollback durchgeführt wird. Wenn Sie nicht gleichzeitig ein Rollback für Worker-Knotenpools ausführen möchten, wählen Sie für das Rollback jeweils einen Knotenpool aus oder aktualisieren Sie die Einstellungen für nodePoolUpgradeStrategy. Ebenso bestimmt der Wert von spec.upgradeStrategy.parallelUpgrade.concurrentNodes in der Spezifikation NodePool, wie viele Knoten parallel zurückgesetzt werden.
Verwenden Sie bmctl update, um Ihre NodePool-Spezifikationsänderungen zu übernehmen:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Clusters, den Sie aktualisieren möchten.
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des verwaltenden Clusters (Administrator, Hybrid oder eigenständig).
Das Rollback beginnt automatisch.
Während des Rollbacks führt Google Distributed Cloud die folgenden Aktivitäten für jeden Knoten aus:
- Versetzen Sie den Knoten in den Wartungsmodus.
- Führen Sie einen Zurücksetzen-Job auf dem Knoten aus, um ihn in einen bereinigten Zustand zu versetzen.
- Führen Sie Maschinen-Preflight-Prüfungen auf dem Knoten aus.
- Führen Sie einen Maschinen-init-Job auf dem Knoten aus, um ihn mit der Ziel-Rollback-Version (vor dem Upgrade) neu zu installieren.
- Entfernen Sie den Knoten aus dem Wartungsmodus.
Am Ende eines erfolgreichen Rollbacks wird der Wert von nodePool.status.anthosBareMetalVersion in der Ressource NodePool auf die Ziel-Rollback-Version gesetzt.

Verwenden Sie bmctl update und kubectl apply -f beim Bearbeiten der Clusterkonfigurationsdatei nicht synonym. Werden diese Befehle austauschbar verwendet, können Inhalte, die im Header der Clusterspezifikation eingetragen sind, unbeabsichtigt entfernt werden. Sie können beispielsweise bmctl update verwenden, um die Clusterkonfigurationsdatei zum Konfigurieren einer Registry-Spiegelung zu aktualisieren. Im Cluster ist dann nach dem Abgleich spec.nodeConfig.registryMirrors ausgefüllt.

Wenn Sie dann versuchen, mithilfe der Clusterkonfiguration und dem Befehl kubectl apply -f Änderungen am Cluster vorzunehmen, wird die vom Abgleich auf dem Cluster ausgefüllte spec.nodeConfig.registryMirrors entfernt. Dieses Verhalten ist darauf zurückzuführen, dass die Konfiguration nicht in der Clusterkonfigurationsspezifikation vorhanden ist, im Cluster jedoch schon.

`kubectl`

Sie können ein Knotenpoolupgrade rückgängig machen, indem Sie mit kubectl die Ressource NodePool direkt bearbeiten:

Wenn Sie einen Worker-Knotenpool zurücksetzen möchten, öffnen Sie die Ressource NodePool zum Bearbeiten:
```
kubectl edit nodepool NODE_POOL_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- NODE_POOL_NAME: der Name des Knotenpools, für den Sie ein Rollback durchführen.
- CLUSTER_NAMESPACE: der Name des Namespace, in dem der Knotenpool bereitgestellt wird. Dies ist der Cluster-Namespace.
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des verwaltenden Clusters (Administrator, Hybrid oder eigenständig).

Ändern Sie den Wert von spec.anthosBareMetalVersion in die vorherige Version (vor dem Upgrade).

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.600-gke.163
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...

Speichern und schließen Sie die Ressource NodePool im Editor.

Das Rollback beginnt automatisch.
Während des Rollbacks führt Google Distributed Cloud die folgenden Aktivitäten für jeden Knoten aus:
- Versetzen Sie den Knoten in den Wartungsmodus.
- Führen Sie einen Zurücksetzen-Job auf dem Knoten aus, um ihn in einen bereinigten Zustand zu versetzen.
- Führen Sie Maschinen-Preflight-Prüfungen auf dem Knoten aus.
- Führen Sie einen Maschinen-init-Job auf dem Knoten aus, um ihn mit der Ziel-Rollback-Version (vor dem Upgrade) neu zu installieren.
- Entfernen Sie den Knoten aus dem Wartungsmodus.
Am Ende eines erfolgreichen Rollbacks wird der Wert von nodePool.status.anthosBareMetalVersion in der Ressource NodePool auf die Ziel-Rollback-Version festgelegt.

Parallele Upgrades

Bei einem typischen Standardclusterupgrade wird jeder Clusterknoten sequenziell nacheinander aktualisiert. In diesem Abschnitt erfahren Sie, wie Sie Ihre Cluster- und Worker-Knotenpools so konfigurieren, dass mehrere Knoten beim Upgrade Ihres Clusters parallel aktualisiert werden. Durch paralleles Upgrade von Knoten werden Clusterupgrades erheblich beschleunigt, 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. Nur Knoten in einem Worker-Knotenpool können parallel aktualisiert werden. Für Knoten in Knotenpools der Steuerungsebene oder des Load-Balancers kann jeweils nur ein Upgrade durchgeführt werden. Weitere Informationen finden Sie unter Strategie für Knotenupgrades.
Gleichzeitiges Knotenpoolupgrade: Sie können Ihren Cluster so konfigurieren, dass mehrere Knotenpools parallel aktualisiert werden. Nur Worker-Knotenpools können parallel aktualisiert werden. Für Knotenpools der Steuerungsebene und des Load-Balancers kann jeweils nur ein Upgrade durchgeführt werden.

Strategie für Knotenupgrades

Sie können Worker-Knotenpools so konfigurieren, dass mehrere Knoten gleichzeitig aktualisiert werden (concurrentNodes). Sie können auch einen Mindestgrenzwert für die Anzahl der Knoten festlegen, die während des Upgradeprozesses Arbeitslasten ausführen können (minimumAvailableNodes). Diese Konfiguration erfolgt in der Knotenpoolspezifikation. Weitere Informationen zu diesen Feldern finden Sie in der Feldreferenz für die Clusterkonfiguration.

Die Strategie für Knotenupgrades gilt nur für Worker-Knotenpools. Sie können keine Strategie für Knotenupgrades für Knotenpools der Steuerungsebene oder des Load-Balancers angeben. Während eines Clusterupgrades werden Knoten in Knotenpools der Steuerungsebene und des Load-Balancers nacheinander aktualisiert. Knotenpools der Steuerungsebene und Load-Balancer-Knotenpools 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 50 % der Knotenanzahl im Knotenpool oder den festen Wert 15 nicht überschreiten, je nachdem, welcher Wert kleiner ist. Wenn Ihr Knotenpool beispielsweise 20 Knoten hat, können Sie keinen Wert größer als 10 angeben. Wenn Ihr Knotenpool 100 Knoten hat, ist 15 der Höchstwert, den Sie angeben können.
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 gesetzt ist, darf concurrentNodes 2 nicht überschreiten. Wenn concurrentNodes auf 10 gesetzt ist, darf minimumAvailableNodes ebenfalls 10 nicht überschreiten.

Das folgende Beispiel zeigt einen Worker-Knotenpool np1 mit 10 Knoten. Bei einem Upgrade müssen Knoten jeweils fünf und mindestens vier 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: 5
      minimumAvailableNodes: 4

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 oder nicht. Standardmäßig (1) werden Knotenpools nacheinander aktualisiert. Wenn Sie concurrentNodePools auf 0 setzen, 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 aktualisiert. Knotenpools der Steuerungsebene und Load-Balancer-Knotenpools werden in der Clusterspezifikation angegeben (controlPlane.nodePoolSpec.nodes und loadBalancer.nodePoolSpec.nodes).

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

Paralleles Upgrade ausfü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 upgradeStrategy-Abschnitt 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 hat das Feld concurrentNodes den Wert 5. Das bedeutet, dass fünf 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 sein müssen.

Hinweis: Sie können keine Strategie für Knotenupgrades für Knotenpools der Steuerungsebene oder des Load-Balancers festlegen.
Fügen Sie der Clusterspezifikation in der Clusterkonfigurationsdatei einen nodePoolUpgradeStrategy-Abschnitt hinzu.
```
---
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.29.100-gke.251
  ...
  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 wie im vorherigen Abschnitt Upgrades von Administrator-, eigenständigen, Hybrid- oder Nutzerclustern beschrieben durch.

Standardwerte für paralleles Upgrade

Parallele Upgrades sind standardmäßig deaktiviert und die mit parallelen Upgrades verbundenen Felder können geändert werden. Sie können die Felder jederzeit entfernen oder auf ihre Standardwerte setzen, 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 Upgrade der Worker-Knotenpools nacheinander durch, einer nach dem anderen.
`upgradeStrategy.parallelUpgrade.concurrentNodes` (NodePool-Spezifikation)	`1`	Führen Sie für die Knoten sequenziell ein Upgrade durch.
`upgradeStrategy.parallelUpgrade.minimumAvailableNodes` (NodePool-Spezifikation)	Der Standardwert für `minimumAvailableNodes` hängt vom Wert von `concurrentNodes` ab. Wenn Sie `concurrentNodes` nicht angeben, entspricht `minimumAvailableNodes` standardmäßig 2/3 der Knotenpoolgröße. Wenn Sie `concurrentNodes` angeben, ist `minimumAvailableNodes` standardmäßig die Knotenpoolgröße minus `concurrentNodes`.	Das Upgrade wird angehalten, wenn `minimumAvailableNodes` erreicht ist. Es wird erst fortgesetzt, wenn die Anzahl der verfügbaren Knoten mehr als `minimumAvailableNodes` beträgt.

Clusterupgrade starten

Dieser Abschnitt enthält eine Anleitung zum Aktualisieren 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 Google Distributed Cloud-Downloads beschrieben herunter.
Aktualisieren Sie anthosBareMetalVersion in der Clusterkonfigurationsdatei auf die Upgrade-Zielversion.

Die Zielversion des Upgrades 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.29.100-gke.251
```
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.
Der Clusterupgrade-Vorgang führt Preflight-Prüfungen aus, 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 dem Upgrade von Clustern beheben.

Wenn alle Clusterkomponenten erfolgreich aktualisiert wurden, werden im Rahmen des Clusterupgrades die Systemdiagnosen des Clusters durchgeführt. Mit diesem letzten Schritt wird überprüft, ob der Cluster in einem einwandfreien Betriebszustand ist. Wenn der Cluster nicht alle Systemdiagnosen besteht, werden sie so lange ausgeführt, bis sie bestanden sind. Wenn alle Systemdiagnosen bestanden sind, ist das Upgrade erfolgreich abgeschlossen.

Weitere Informationen zur Reihenfolge der Ereignisse bei 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 starten:
```
kubectl apply -f CLUSTER_CONFIG_PATH
```
Ersetzen Sie CLUSTER_CONFIG_PATH durch den Pfad der bearbeiteten Clusterkonfigurationsdatei.

Wie beim Upgradeprozess bei 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 dem Upgrade von Clustern beheben.

Du benötigst nicht die aktuelle Version von bmctl, um Cluter mit kubectl zu aktualisieren. Wir empfehlen dir aber, die neueste Version von bmctl herunterzuladen. Sie benötigen bmctl, um andere Aufgaben wie Systemdiagnosen und Sicherungen auszuführen, damit Ihr Cluster in einwandfreiem Zustand bleibt.

Upgrades pausieren und fortsetzen

Mit der Funktion zum Pausieren und Fortsetzen des Upgrades können Sie ein Clusterupgrade anhalten, bevor es abgeschlossen ist. Wenn ein Clusterupgrade pausiert wird, werden keine neuen Worker-Knotenupgrades ausgelöst, bis das Upgrade fortgesetzt wird.

Dieses Feature ist in der Vorabversion für Cluster mit allen Knoten der Steuerungsebene ab Nebenversion 1.28 verfügbar. Diese Funktion ist allgemein verfügbar für Cluster mit allen Knoten der Steuerungsebene mit Nebenversion 1.29 oder höher.

Die Umstellung kann aus folgenden Gründen pausiert werden:

Sie haben während des Upgrades ein Problem mit Clusterarbeitslasten festgestellt und möchten das Upgrade anhalten, um das Problem zu untersuchen
Da Ihre Wartungsfenster nur kurz sind, sollten Sie das Upgrade zwischen den Wartungsfenstern pausieren.

Während ein Clusterupgrade pausiert ist, werden die folgenden Vorgänge unterstützt:

Wenn während eines pausierten Upgrades ein neuer Knoten hinzugefügt wird, werden Maschinenprüfjobs erst auf diesem Knoten ausgeführt, wenn das Upgrade fortgesetzt und abgeschlossen wurde.

Während das Clusterupgrade pausiert ist, werden die folgenden Clustervorgänge nicht unterstützt:

Sie können kein neues Clusterupgrade initiieren, während ein aktives Clusterupgrade pausiert ist.

Pausieren und Fortsetzen des Upgrades aktivieren

Google Distributed Cloud 1.29

Die Funktion zum Anhalten und Fortsetzen des Upgrades ist standardmäßig für Cluster mit allen Knoten der Steuerungsebene mit Nebenversion 1.29 oder höher aktiviert.

Google Distributed Cloud 1.28

Während sich die Funktion zum Anhalten und Fortsetzen des Upgrades in der Vorabversion befindet, können Sie sie mit einer Anmerkung in der Clusterressource aktivieren.

Führen Sie die folgenden Schritte aus, um das Pausieren und Fortsetzen des Upgrades zu aktivieren:

Fügen Sie der Clusterkonfigurationsdatei die Annotation preview.baremetal.cluster.gke.io/upgrade-pause-and-resume hinzu:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
spec:
...

Aktualisieren Sie Ihren Cluster, um die Änderung anzuwenden:
```
bmctl update CLUSTER_NAME
```
Das Feld nodePoolUpgradeStrategy.pause kann geändert werden. Sie können sie jederzeit hinzufügen und aktualisieren.

Upgrade pausieren

Sie halten ein Clusterupgrade an, indem Sie nodePoolUpgradeStrategy.pause in der Clusterspezifikation auf true setzen.

So pausieren Sie ein aktives Clusterupgrade:

Fügen Sie der Clusterkonfigurationsdatei nodePoolUpgradeStrategy.pause hinzu und legen Sie sie auf true fest:
```
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  ...
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: true
  ...
```
Wenn Sie bmctl zum Starten des Upgrades verwendet haben, benötigen Sie ein neues Terminalfenster, um den nächsten Schritt auszuführen.
Aktualisieren Sie Ihren Cluster, um die Änderung anzuwenden:
```
bmctl update CLUSTER_NAME
```
Der Upgradevorgang ist pausiert. Es werden keine neuen Knotenupgrades ausgelöst.
Wenn Sie zum Starten des Upgrades bmctl verwendet haben und eine lange Pause einplanen möchten, drücken Sie Strg+C, um bmctl zu beenden. Andernfalls lassen Sie bmctl weiter ausgeführt.

Die bmctl-Befehlszeile erkennt keine Änderungen am Pausenstatus des Upgrades und wird daher nicht automatisch beendet. Wenn Sie bmctl jedoch beenden, wird der Fortschritt des Upgrades nicht mehr in der Logdatei cluster-upgrade-TIMESTAMP im Clusterordner auf Ihrer Administratorworkstation und in Cloud Logging protokolliert. Bei kurzen Pausen empfiehlt es sich daher, bmctl weiter auszuführen. Wenn Sie bmctl über einen längeren Zeitraum ausführen, während das Upgrade pausiert ist, kommt es zu einer Zeitüberschreitung.

Pausiertes Upgrade fortsetzen

Sie setzen ein pausiertes Clusterupgrade fort, indem Sie nodePoolUpgradeStrategy.pause in der Clusterspezifikation auf false setzen oder nodePoolUpgradeStrategy.pause aus der Spezifikation entfernen.

So setzen Sie ein pausiertes Clusterupgrade fort:

Legen Sie nodePoolUpgradeStrategy.pause auf die Clusterkonfigurationsdatei und false fest:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  ...
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: false
  ...

Alternativ können Sie das Feld pause entfernen, da es standardmäßig auf false gesetzt ist.

Aktualisieren Sie Ihren Cluster, um die Änderung anzuwenden:
```
bmctl update CLUSTER_NAME
```
Der Upgradevorgang wird an der Stelle fortgesetzt, an der er unterbrochen wurde.

Um den Status des Upgrades zu prüfen, rufen Sie zuerst eine Liste der Ressourcen ab, in deren status anthosBareMetalVersion ist:

kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces

Ersetzen Sie Folgendes:

RESOURCE: der Name der Ressource, die Sie abrufen möchten. Cluster-, NodePool- und BareMetalMachine-Ressourcen enthalten alle anthosBareMetalVersion-Statusinformationen.
ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters

Das folgende Beispiel zeigt das Format der Antwort für benutzerdefinierte BareMetalMachine-Ressourcen. Jede BareMetalMachine entspricht einem Clusterknoten.

NAMESPACE              NAME         CLUSTER        READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
cluster-nuc-admin001   192.0.2.52   nuc-admin001   true    baremetal://192.0.2.52   192.0.2.52   1.28.0        1.28.0
cluster-nuc-user001    192.0.2.53   nuc-user001    true    baremetal://192.0.2.53   192.0.2.53   1.16.2        1.16.2
cluster-nuc-user001    192.0.2.54   nuc-user001    true    baremetal://192.0.2.54   192.0.2.54   1.16.2        1.16.2

Rufen Sie Details zu einzelnen Ressourcen ab, um die status.anthosBareMetalVersion (aktuelle Version der Ressource) zu prüfen:

kubectl describe RESOURCE RESOURCE_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

Im folgenden Beispiel sehen Sie die BareMetalMachine-Details für den Clusterknoten mit der IP-Adresse 192.0.2.53:

Name:         192.0.2.53
Namespace:    cluster-nuc-user001
...
API Version:  infrastructure.baremetal.cluster.gke.io/v1
Kind:         BareMetalMachine
Metadata:
  Creation Timestamp:  2023-09-22T17:52:09Z
  ...
Spec:
  Address:                    192.0.2.53
  Anthos Bare Metal Version:  1.16.2
  ...
Status:
  Anthos Bare Metal Version:  1.16.2

In diesem Beispiel befindet sich der Knoten mit der Google Distributed Cloud-Version 1.16.2.