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

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

Diese Seite richtet sich an Administratoren, Architekten und Betreiber, die den Lebenszyklus der zugrunde liegenden technischen Infrastruktur verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

Upgrade planen

Dieser Abschnitt enthält Informationen und Links zu Informationen, die Sie vor dem Upgrade eines Clusters berücksichtigen sollten. Weitere Informationen zu Upgrades, einschließlich Versionsverwaltungsregeln für Cluster und Knotenpools, finden Sie unter Lebenszyklus und Phasen von Clusterupgrades.

Best Practices

Informationen zur Vorbereitung auf ein Clusterupgrade finden Sie unter Best Practices für Cluster-Upgrades in Google Distributed Cloud.

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 Beginn des Upgrades 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 mit Google Distributed Cloud für Bare Metal in der Problemkategorie Upgrades und Updates.

Upgradeoptionen konfigurieren

Bevor Sie ein Cluster-Upgrade starten, können Sie die folgenden Upgradeoptionen konfigurieren, mit denen Sie den Ablauf des Upgrades steuern:

Selektive Worker-Knotenpool-Upgrades: Bestimmte Worker-Knotenpools können separat vom Rest des Clusters aktualisiert werden.
Parallele Upgrades: Sie können den Upgradevorgang so konfigurieren, dass Gruppen von Knoten oder Knotenpools gleichzeitig aktualisiert werden.

Mit diesen Optionen lässt sich das Risiko von Unterbrechungen bei kritischen Anwendungen und Diensten verringern und die Gesamtzeit für das Upgrade erheblich verkürzen. 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 zu den Funktionen und zur Verwendung dieser Optionen finden Sie in den folgenden Abschnitten.

Selektive Worker-Knotenpool-Upgrades

Standardmäßig werden beim Cluster-Upgrade alle Knoten und Knotenpools im Cluster aktualisiert. Ein Cluster-Upgrade kann störend und zeitaufwendig sein, da jeder Knoten geräumt 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 können, um Arbeitslastunterbrechungen zu minimieren. Diese Funktion gilt nur für Nutzer-, Hybrid- und eigenständige Cluster, da in Administratorclustern keine Worker-Knotenpools zulässig sind.

Sie können selektive Knotenpool-Upgrades in folgenden Situationen verwenden:

Sicherheitsfixes anwenden, ohne Arbeitslasten zu beeinträchtigen:Sie können nur die Knoten der Steuerungsebene (und die Load Balancer-Knoten) aktualisieren, um Kubernetes-Sicherheitsfixes anzuwenden, ohne Ihre Worker-Knotenpools zu beeinträchtigen.
Prüfen, ob eine aktualisierte Teilmenge der Worker-Knoten ordnungsgemäß funktioniert, bevor alle Worker-Knoten aktualisiert werden:Sie können Ihre Worker-Knotenpools selektiv aktualisieren, um sicherzustellen, dass Arbeitslasten in einem aktualisierten Knotenpool ordnungsgemäß ausgeführt werden, bevor Sie einen anderen Knotenpool aktualisieren.
Wartungsfenster verkürzen:Das Upgrade eines großen Clusters kann zeitaufwendig sein und es ist schwierig, genau vorherzusagen, wann es abgeschlossen ist. Die Zeit für das Cluster-Upgrade ist proportional zur Anzahl der Knoten, die aktualisiert werden. Wenn Sie die Anzahl der Knoten, die aktualisiert werden, durch Ausschließen von Knotenpools reduzieren, verkürzt sich die Upgradezeit. Sie führen mehrmals ein Upgrade durch, aber die kleineren, besser planbaren Wartungsfenster können bei der Planung helfen.

Abweichung zwischen den Versionen des Knotenpools von zwei Nebenversionen

Bei Clustern mit 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 der n-2-Versionsabweichung können Sie auch eine Nebenversion überspringen, wenn Sie einen Worker-Knotenpool von zwei Nebenversionen hinter dem Cluster auf dieselbe Nebenversion wie der Cluster aktualisieren.

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

Wenn Sie beispielsweise einen Cluster der Version 1.31 haben, können Sie Worker-Knotenpools mit den Versionen 1.31, 1.30 und 1.29 auswählen.

Bevor Sie einen Cluster aktualisieren können, müssen alle Worker-Knotenpools eine Version haben, die sowohl mit der aktuellen Clusterversion als auch mit der Zielclusterversion kompatibel ist.

Wenn Sie beispielsweise einen Cluster der Version 1.29 und Worker-Knotenpools der Versionen 1.29, 1.28 und 1.16 haben, müssen Sie die Knotenpools der Version 1.16 auf Version 1.28 oder 1.29 aktualisieren, bevor Sie den Cluster auf Version 1.30 aktualisieren können.

Weitere Informationen, einschließlich Listen der von einer bestimmten Clusterversion unterstützten Worker-Knotenpool-Versionen (gilt für Version 1.29 und älter), finden Sie unter Regeln für die Versionsverwaltung von Knotenpools.

1,30

In Version 1.30 ist die Unterstützung von n-2-Versionsabweichungen für Worker-Knotenpools für alle Clustertypen allgemein verfügbar. Diese Funktion ist für Cluster mit Version 1.30 standardmäßig aktiviert.

Knotenpools mit einer beliebigen Patchversion der Nebenversionen 1.28 und 1.29 können auf eine beliebige Patchversion von 1.30 aktualisiert werden, wenn die Knotenpoolversion mit der Clusterversion übereinstimmt oder niedriger ist.

1,29

In Version 1.29 ist die Unterstützung von Versionsabweichungen vom Typ n-2 für Worker-Knotenpools für alle Clustertypen allgemein verfügbar. Diese Funktion ist für Cluster mit Version 1.29 standardmäßig aktiviert.

Während wir diese Funktion von der öffentlichen Vorschau in die allgemeine Verfügbarkeit überführen, ist für Hybridcluster in der folgenden Situation weiterhin die Vorschauanmerkung erforderlich. 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 Anmerkung preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable vor dem Upgrade auf Version 1.29.z hinzufügen:

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 für Versionsabweichungen vom Typ „n-2“ für Worker-Knotenpools ist in Version 1.28 als Vorabversion verfügbar. Wenn Sie diese Vorabversion aktivieren möchten, fügen Sie der Clusterkonfigurationsdatei die Anmerkung preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable hinzu:

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 Vorabversion nicht aktivieren, beträgt die maximale Versionsabweichung zwischen einem Worker-Knotenpool und dem Cluster eine Nebenversion.

Weitere Informationen zu den Versionsverwaltungsregeln für das selektive Upgrade von Arbeitsknotenpools finden Sie unter Regeln für die Versionsverwaltung von Knotenpools im Abschnitt „Lebenszyklus und Phasen von Clusterupgrades“.

Cluster-Steuerungsebene und ausgewählte Knotenpools aktualisieren

So führen Sie ein selektives Upgrade der Worker-Knotenpools beim ersten Cluster-Upgrade durch:

Nehmen Sie für die Worker-Knotenpools, die Sie in das Cluster-Upgrade einbeziehen möchten, eine der folgenden Änderungen an der NodePool-Spezifikation vor:
- Legen Sie anthosBareMetalVersion in der NodePool-Spezifikation auf die Zielversion des Cluster-Upgrades fest.
- Lassen Sie das Feld anthosBareMetalVersion aus der NodePool-Spezifikation weg oder setzen Sie es auf den leeren String. Worker-Knotenpools sind standardmäßig in Cluster-Upgrades enthalten.
Legen Sie für die Worker-Knotenpools, die Sie vom Upgrade ausschließen möchten, anthosBareMetalVersion auf die aktuelle Version (vor dem Upgrade) des Clusters fest:
Fahren Sie mit dem Upgrade wie unter Clusterupgrade starten beschrieben fort.

Beim Clusterupgrade werden die folgenden Knoten aktualisiert:
- Knoten der Cluster-Steuerungsebene
- Load Balancer-Knotenpool, falls für Ihren Cluster einer verwendet wird (spec.loadBalancer.nodePoolSpec). Standardmäßig können Load Balancer-Knoten reguläre Arbeitslasten ausführen. Sie können einen Load Balancer-Knotenpool nicht selektiv aktualisieren. Er ist immer im ersten Clusterupgrade enthalten.
- Worker-Knotenpools, die Sie nicht vom Upgrade ausgeschlossen haben

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

Der folgende Auszug aus einer Clusterkonfigurationsdatei zeigt, wie Sie die Clusterkonfiguration so ändern können, dass dieses teilweise Upgrade unterstützt wird:

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.31.200-gke.58
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.31.200-gke.58
  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.30.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 aktualisieren

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

So führen Sie ein Upgrade der Worker-Knotenpools auf die aktuelle Clusterversion durch:

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

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

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

Angenommen, Sie haben Ihren Cluster auf Version 1.31.200-gke.58 aktualisiert, aber Knotenpool wpool02 hat immer noch die alte Clusterversion 1.30.0 vor dem Upgrade. Die Arbeitslasten werden im aktualisierten Knotenpool wpool01 ordnungsgemäß ausgeführt. Sie möchten jetzt auch wpool02 auf die aktuelle Clusterversion umstellen. Wenn Sie wpool02 aktualisieren möchten, können Sie das Feld anthosBareMetalVersion entfernen oder seinen Wert auf den leeren String festlegen.

Der folgende Auszug aus einer Clusterkonfigurationsdatei zeigt, wie Sie die Clusterkonfiguration so ändern können, dass dieses teilweise Upgrade unterstützt wird:

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.31.200-gke.58
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.31.200-gke.58
  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, z. B. die Kompatibilität mit kubelet oder Plug-ins, die sich auf die Leistung Ihrer Arbeitslasten auswirken können. Falls nach dem Upgrade eines Worker-Knotenpools ein Problem auftritt, können Sie den Knotenpool auf die vorherige Version zurücksetzen.

Diese Funktion ist nicht in derselben Markteinführungsphase für alle unterstützten Clusterversionen:

1,30

Für Cluster der Version 1.30 (Cluster mit Steuerungsebenenknoten der Version 1.30) ist die Rollback-Funktion für Knotenpools allgemein verfügbar und standardmäßig aktiviert.

1,29

Die Rollback-Funktion für Knotenpools ist als Vorabversion für Cluster der Version 1.29 verfügbar (Cluster mit Knoten der Steuerungsebene der Version 1.29). Solange sich diese Funktion im Vorschaumodus befindet, müssen Sie der Cluster-Ressource die folgende Anmerkung hinzufügen, um sie zu aktivieren:

preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable

1,28

Die Rollback-Funktion für Knotenpools ist für Cluster mit der Nebenversion 1.28 oder niedriger nicht verfügbar.

So führen Sie ein Rollback für ein Knotenpool-Upgrade durch:

`bmctl`

Wenn Sie ein Knotenpool-Upgrade mit bmctl rückgängig machen, bearbeiten Sie die Clusterkonfigurationsdatei und wenden die Änderungen mit dem Befehl bmctl update an:

Bearbeiten Sie die NodePool-Spezifikationen in der Clusterkonfigurationsdatei für die Worker-Knotenpools, die Sie auf die vorherige Version zurücksetzen möchten. 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.30.500-gke.126
  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 sind, wird durch den Wert von spec.nodePoolUpgradeStrategy.concurrentNodePools in der Clusterspezifikation festgelegt, wie viele Knotenpools parallel rückgängig gemacht werden. Wenn Sie Worker-Knotenpools nicht gleichzeitig zurücksetzen möchten, wählen Sie für das Rollback jeweils einen Knotenpool aus oder aktualisieren Sie die nodePoolUpgradeStrategy-Einstellungen. Ebenso gibt der Wert von spec.upgradeStrategy.parallelUpgrade.concurrentNodes in der NodePool-Spezifikation an, wie viele Knoten parallel rückgängig gemacht werden.
Wenden Sie die Änderungen an der NodePool-Spezifikation mit bmctl update an:
```
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ändiger Cluster).
Das Rollback wird automatisch gestartet. Der Befehl bmctl update cluster wird sofort beendet, der Rollback wird jedoch fortgesetzt. Führen Sie während des Rollbacks keine weiteren Vorgänge auf dem Cluster aus.
Während des Rollbacks führt Google Distributed Cloud für jeden Knoten die folgenden Aktivitäten aus:
- Versetzen Sie den Knoten in den Wartungsmodus.
- Führen Sie einen Zurücksetzungsjob auf dem Knoten aus, um ihn in den Ausgangszustand zu versetzen.
- Führen Sie Preflight-Prüfungen für den Computer auf dem Knoten aus.
- Führen Sie einen Machine-Init-Job auf dem Knoten aus, um ihn mit der Rollabck-Zielversion 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 NodePool-Ressource auf die Zielversion des Rollbacks festgelegt.

Verwenden Sie bmctl update und kubectl apply -f nicht synonym, wenn Sie die Clusterkonfigurationsdatei bearbeiten. Wenn diese Befehle synonym verwendet werden, werden Inhalte, die über den Header der Clusterspezifikation eingefügt wurden, möglicherweise versehentlich entfernt. Sie können beispielsweise bmctl update verwenden, um die Clusterkonfigurationsdatei zu aktualisieren und eine Registry-Spiegelung zu konfigurieren. Nach dem Abgleich hat der Cluster dann spec.nodeConfig.registryMirrors.

Wenn Sie dann versuchen, mit der Clusterkonfiguration und dem Befehl kubectl apply -f Änderungen am Cluster vorzunehmen, wird die vom Abgleich im Cluster befüllte spec.nodeConfig.registryMirrors entfernt. Dieses Verhalten tritt auf, weil die Konfiguration nicht in der Clusterkonfigurationsspezifikation, aber im Cluster vorhanden ist.

`kubectl`

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

Wenn Sie einen Worker-Knotenpool rückgängig machen möchten, öffnen Sie die NodePool-Ressource zur Bearbeitung:
```
kubectl edit nodepool NODE_POOL_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- NODE_POOL_NAME ist der Name des Knotenpools, für den ein Rollback durchgeführt werden soll.
- 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ändiger Cluster).

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

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

Speichern und schließen Sie die NodePool-Ressource in Ihrem Editor.

Das Rollback wird automatisch gestartet. Führen Sie während des Rollbacks keine weiteren Vorgänge auf dem Cluster aus.
Während des Rollbacks führt Google Distributed Cloud für jeden Knoten die folgenden Aktivitäten aus:
- Versetzen Sie den Knoten in den Wartungsmodus.
- Führen Sie einen Zurücksetzungsjob auf dem Knoten aus, um ihn in den Ausgangszustand zu versetzen.
- Führen Sie Preflight-Prüfungen für den Computer auf dem Knoten aus.
- Führen Sie einen Machine-Init-Job auf dem Knoten aus, um ihn mit der Rollabck-Zielversion 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 NodePool-Ressource auf die Zielversion des Rollbacks festgelegt.

Parallele Upgrades

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

Es gibt zwei parallele Upgradestrategien, mit denen Sie das Cluster-Upgrade beschleunigen können:

Paralleles Knotenupgrade:Sie können Ihre Worker-Knotenpools so konfigurieren, dass mehrere Knoten gleichzeitig aktualisiert werden. Parallele Upgrades von Knoten werden in der NodePool-Spezifikation (spec.upgradeStrategy.parallelUpgrade) konfiguriert. Nur Knoten in einem Worker-Knotenpool können parallel aktualisiert werden. Knoten in Knotenpools der Steuerungsebene oder Load Balancer-Knotenpools können nur einzeln aktualisiert werden. Weitere Informationen finden Sie unter Strategie für das Knotenupgrade.
Paralleles Knotenpool-Upgrade:Sie können Ihren Cluster so konfigurieren, dass mehrere Knotenpools parallel aktualisiert werden. Nur Worker-Knotenpools können parallel aktualisiert werden. Knotenpools der Steuerungsebene und des Load Balancers können nur einzeln aktualisiert 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, auf denen während des Upgrade-Prozesses Arbeitslasten ausgeführt werden können (minimumAvailableNodes). Diese Konfiguration erfolgt in der NodePool-Spezifikation. Weitere Informationen zu diesen Feldern finden Sie in der Referenz zu Clusterkonfigurationsfeldern.

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

Beachten Sie beim Konfigurieren paralleler Upgrades für Knoten die folgenden Einschränkungen:

Der Wert von concurrentNodes darf 50 Prozent der Anzahl der Knoten im Knotenpool oder die feste Zahl 15 nicht überschreiten, je nachdem, welcher Wert kleiner ist. Wenn Ihr Knotenpool beispielsweise 20 Knoten hat, können Sie keinen Wert über 10 angeben. Wenn Ihr Knotenpool 100 Knoten hat, ist 15 der maximale Wert, den Sie angeben können.
Wenn Sie concurrentNodes zusammen mit minimumAvailableNodes verwenden, darf die Gesamtzahl der Knoten im Knotenpool nicht überschritten werden. Wenn Ihr Knotenpool beispielsweise 20 Knoten hat und minimumAvailableNodes auf 18 gesetzt ist, darf concurrentNodes nicht größer als 2 sein. Wenn concurrentNodes auf 10 festgelegt ist, darf minimumAvailableNodes nicht größer als 10 sein.

Das folgende Beispiel zeigt einen Worker-Knotenpool np1 mit 10 Knoten. Bei einem Upgrade werden jeweils fünf Knoten gleichzeitig aktualisiert. Damit das Upgrade fortgesetzt werden kann, müssen mindestens vier Knoten verfügbar sein:

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. Im booleschen Feld nodePoolUpgradeStrategy.concurrentNodePools in der Clusterspezifikation wird angegeben, ob alle Worker-Knotenpools für einen Cluster gleichzeitig aktualisiert werden sollen. Standardmäßig (1) werden Knotenpools 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 aktualisiert. Knotenpools der Steuerungsebene und Load Balancer-Knotenpools werden in der Clusterspezifikation (controlPlane.nodePoolSpec.nodes und loadBalancer.nodePoolSpec.nodes) angegeben.

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 durch:

Fügen Sie der NodePool-Spezifikation einen upgradeStrategy-Abschnitt hinzu.

Sie können dieses Manifest separat oder als Teil der Clusterkonfigurationsdatei anwenden, wenn Sie einen Cluster aktualisieren.

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. Das 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 Strategie für das Knoten-Upgrade für Knotenpools der Steuerungsebene oder Load Balancer angeben.
Fügen Sie der Clusterspezifikation in der Clusterkonfigurationsdatei den Abschnitt nodePoolUpgradeStrategy 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.31.200-gke.58
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...
```
In diesem Beispiel ist das Feld concurrentNodePools auf 0 festgelegt. Das bedeutet, dass alle Worker-Knotenpools während des Cluster-Upgrades gleichzeitig aktualisiert werden. Die Upgradestrategie für die Knoten in den Knotenpools wird in den NodePool-Spezifikationen definiert.
Aktualisieren Sie den Cluster wie im Abschnitt Administrator-, eigenständige, Hybrid- oder Nutzercluster aktualisieren beschrieben.

Standardwerte für parallele Upgrades

Parallele Upgrades sind standardmäßig deaktiviert und die zu parallelen Upgrades gehörenden Felder sind veränderbar. Sie können die Felder jederzeit entfernen oder auf die Standardwerte zurücksetzen, um die Funktion vor einem nachfolgenden Upgrade zu deaktivieren.

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

Feld	Standardwert	Bedeutung
`nodePoolUpgradeStrategy.concurrentNodePools` (Clusterspezifikation)	`1`	Aktualisieren Sie die Worker-Knotenpools nacheinander.
`upgradeStrategy.parallelUpgrade.concurrentNodes` (Knotenpoolspezifikation)	`1`	Aktualisieren Sie die Knoten nacheinander.
`upgradeStrategy.parallelUpgrade.minimumAvailableNodes` (Knotenpoolspezifikation)	Der Standardwert für `minimumAvailableNodes` hängt vom Wert von `concurrentNodes` ab. Wenn Sie `concurrentNodes` nicht angeben, entspricht `minimumAvailableNodes` standardmäßig 2/3 der Größe des Knotenpools. Wenn Sie `concurrentNodes` angeben, ist `minimumAvailableNodes` standardmäßig die Größe des Knotenpools abzüglich `concurrentNodes`.	Das Upgrade wird angehalten, sobald `minimumAvailableNodes` erreicht ist, und fortgesetzt, sobald die Anzahl der verfügbaren Knoten über `minimumAvailableNodes` liegt.

Cluster-Upgrade starten

Dieser Abschnitt enthält 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.

Legen Sie Ihre Nutzeranmeldedaten als Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) fest:
```
gcloud auth application-default login
```
Folgen Sie den Anweisungen, um Ihr Google-Konto für ADC auszuwählen. Weitere Informationen finden Sie unter Standardanmeldedaten für Anwendungen einrichten.
Laden Sie die neueste bmctl wie unter Google Distributed Cloud-Downloads beschrieben herunter.
Aktualisieren Sie anthosBareMetalVersion in der Clusterkonfigurationsdatei auf die Zielversion des Upgrades.

Die Zielversion des Upgrades muss mit der Version der heruntergeladenen bmctl-Datei übereinstimmen. Im folgenden Snippet einer Clusterkonfigurationsdatei ist das Feld anthosBareMetalVersion auf die neueste Version aktualisiert:
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  type: admin
  # Anthos cluster version.
  anthosBareMetalVersion: 1.31.200-gke.58
```
Verwenden Sie den Befehl bmctl upgrade cluster, um das Upgrade abzuschließen:
```
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Dabei gilt:
- CLUSTER_NAME: der Name des Clusters, der aktualisiert werden soll.
- ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters.
Hinweis :Mit dem Befehl bmctl upgrade werden nur der Wert anthosBareMetalVersion und die Vorschauanmerkungen in der benutzerdefinierten Clusterressource aktualisiert. Wenn Sie andere Felder der Clusterspezifikation ändern möchten, verwenden Sie den Befehl bmctl update. Weitere Informationen finden Sie unter Cluster aktualisieren.

Beim Clusterupgrade werden Preflight-Prüfungen ausgeführt, um den Clusterstatus und den Knotenzustand zu validieren. Das Clusterupgrade wird nicht fortgesetzt, wenn die Preflight-Prüfungen fehlschlagen. Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung bei Problemen mit der Clusterinstallation oder dem Clusterupgrade.

Wenn alle Clusterkomponenten erfolgreich aktualisiert wurden, führt das Cluster-Upgrade Cluster-Systemdiagnosen aus. Mit diesem letzten Schritt wird überprüft, ob der Cluster in einwandfreiem Zustand ist. Wenn der Cluster nicht alle Systemdiagnosen besteht, werden diese so lange ausgeführt, bis sie bestanden werden. Wenn alle Systemdiagnosen bestanden wurden, ist das Upgrade abgeschlossen.

Weitere Informationen zur Abfolge der Ereignisse bei Clusterupgrades finden Sie unter Lebenszyklus und Phasen von Clusterupgrades.

`kubectl`

So führen Sie ein Upgrade für einen Cluster mit kubectl durch:

Bearbeiten Sie die Cluster-Konfigurationsdatei, um anthosBareMetalVersion auf die Zielversion des Upgrades 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 Upgrade mit bmctl werden im Rahmen des Clusterupgrades Preflight-Prüfungen ausgeführt, um den Clusterstatus und den Knotenzustand zu validieren. Wenn die Preflight-Prüfungen fehlschlagen, wird das Clusterupgrade angehalten. Prüfen Sie zur Fehlerbehebung den Cluster und die zugehörigen Protokolle, da kein Bootstrap-Cluster erstellt wird. Weitere Informationen finden Sie unter Probleme bei der Installation oder Aktualisierung von Clustern beheben.

Sie benötigen zwar nicht die neueste Version von bmctl, um Cluster mit kubectl zu aktualisieren, wir empfehlen Ihnen jedoch, die neueste Version von bmctl herunterzuladen. Sie benötigen bmctl, um andere Aufgaben wie Systemdiagnosen und Sicherungen auszuführen, damit Ihr Cluster ordnungsgemäß funktioniert.

Upgrades pausieren und fortsetzen

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

Diese Funktion ist in der Vorabversion für Cluster verfügbar, bei denen alle Knoten der Steuerungsebene die Nebenversion 1.28 oder höher haben. Die Funktion ist für Cluster allgemein verfügbar, bei denen alle Knoten der Steuerungsebene die Nebenversion 1.29 oder höher haben.

Es gibt folgende Gründe, ein Upgrade zu pausieren:

Sie haben während des Upgrades ein Problem mit Clusterarbeitslasten festgestellt und möchten das Upgrade pausieren, um das Problem zu untersuchen.
Sie haben kurze Wartungsfenster und möchten das Upgrade zwischen den Fenstern pausieren.

Während ein Cluster-Upgrade pausiert ist, sind die folgenden Vorgänge möglich:

Wenn ein neuer Knoten hinzugefügt wird, während ein Upgrade pausiert ist, werden keine Jobs zur Computerüberprüfung darauf ausgeführt, bis das Upgrade fortgesetzt und abgeschlossen ist.

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

Sie können kein neues Cluster-Upgrade starten, während ein aktives Cluster-Upgrade pausiert ist.

Upgrade pausieren und fortsetzen

Google Distributed Cloud 1.31

Die Funktion zum Pausieren und Fortsetzen des Upgrades ist standardmäßig für Cluster aktiviert, bei denen alle Knoten der Steuerungsebene die Nebenversion 1.29 oder höher haben.

Google Distributed Cloud 1.30

Die Funktion zum Pausieren und Fortsetzen von Upgrades befindet sich in der Vorabversion. Sie können sie mit einer Anmerkung in der Clusterressource aktivieren.

So aktivieren Sie die Pausierung und Fortsetzung des Upgrades:

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: enable
spec:
...

Aktualisieren Sie den Cluster, um die Änderung anzuwenden:
```
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: Geben Sie für Administrator-, Hybrid- oder eigenständige Cluster den Pfad zur kubeconfig-Datei des Clusters ein. Geben Sie für einen Nutzercluster den Pfad zur kubeconfig-Datei des Administratorclusters ein.
Das Feld nodePoolUpgradeStrategy.pause kann geändert werden. Sie können sie jederzeit hinzufügen und aktualisieren.

Upgrade pausieren

Sie können ein Clusterupgrade pausieren, indem Sie in der Clusterspezifikation nodePoolUpgradeStrategy.pause auf true festlegen.

So pausieren Sie ein aktives Cluster-Upgrade:

Fügen Sie der Clusterkonfigurationsdatei nodePoolUpgradeStrategy.pause hinzu und setzen Sie es auf true:
```
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  ...
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: true
  ...
```
Wenn Sie das Upgrade mit bmctl gestartet haben, benötigen Sie ein neues Terminalfenster, um den nächsten Schritt auszuführen.
Aktualisieren Sie den Cluster, um die Änderung anzuwenden:
```
bmctl update CLUSTER_NAME
```
Der Upgradevorgang ist pausiert. Es werden keine neuen Knotenupgrades ausgelöst.
Wenn Sie das Upgrade über bmctl gestartet haben und eine lange Pause einlegen möchten, drücken Sie Strg + C, um bmctl zu beenden. Andernfalls lassen Sie bmctl laufen.

Die bmctl CLI erkennt keine Änderungen am Status der Upgradeaussetzung und wird daher nicht automatisch beendet. Wenn Sie bmctl jedoch beenden, wird der Fortschritt des Upgrades nicht mehr in der Protokolldatei cluster-upgrade-TIMESTAMP im Clusterordner auf Ihrer Administrator-Workstation und in Cloud Logging protokolliert. Bei kurzen Pausen sollten Sie bmctl daher laufen lassen. Wenn Sie bmctl für einen längeren Zeitraum laufen lassen, während das Upgrade pausiert ist, kommt es irgendwann zu einem Zeitüberschreitungsfehler.

Pausiertes Upgrade fortsetzen

Sie können ein pausiertes Clusterupgrade fortsetzen, indem Sie in der Clusterspezifikation entweder nodePoolUpgradeStrategy.pause auf false festlegen oder nodePoolUpgradeStrategy.pause aus der Spezifikation entfernen.

So setzen Sie ein angehaltenes Clusterupgrade fort:

Legen Sie in der Clusterkonfigurationsdatei nodePoolUpgradeStrategy.pause auf 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 standardmäßig false verwendet wird.

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

Wenn Sie den Status des Upgrades prüfen möchten, rufen Sie zuerst eine Liste der Ressourcen ab, deren status anthosBareMetalVersion enthält:

kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces

Ersetzen Sie Folgendes:

RESOURCE: Der Name der Ressource, die Sie abrufen möchten. Die Ressourcen Cluster, NodePool und BareMetalMachine 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

Wenn Sie die status.anthosBareMetalVersion (aktuelle Version der Ressource) prüfen möchten, rufen Sie Details zu einzelnen Ressourcen ab:

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

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

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 verwendet der Knoten Google Distributed Cloud Version 1.16.2.