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 dem Cluster zusätzliche Funktionen und Fehlerkorrekturen hinzugefügt. Außerdem wird Ihr Cluster auch dann noch unterstützt. Mit dem Befehl bmctl upgrade cluster können Sie Administrator-, Hybrid-, eigenständige oder Nutzercluster aktualisieren. Alternativ können Sie auch kubectl verwenden.

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-Nutzerrollen und -Aufgaben.

Hinweis :Wenn Sie ein Upgrade von Google Distributed Cloud von einer Version mit einem Sicherheitspatch auf die nächste Nebenversion durchführen, empfehlen wir Ihnen, auf die höchste verfügbare Patchversion zu aktualisieren, damit Sie die neuesten Sicherheitspatches haben. Lesen Sie immer die Versionshinweise vor dem Upgrade, damit Sie wissen, was sich geändert hat, einschließlich Sicherheitsupdates und bekannter Probleme. Ein Downgrade auf eine niedrigere Clusterversion wird nicht unterstützt.

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 der Versionsverwaltungsregeln für Cluster und Knotenpools, finden Sie unter Lebenszyklus und Phasen von Clusterupgrades.

Best Practices

Informationen zur Vorbereitung auf ein Cluster-Upgrade 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 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 dort die Problemkategorie Upgrades und Updates aus.

Upgrade-Optionen konfigurieren

Bevor Sie ein Cluster-Upgrade starten, können Sie die folgenden Upgradeoptionen konfigurieren, die steuern, wie der Upgradevorgang abläuft:

• Selektive Upgrades von Worker-Knotenpools: Sie können bestimmte Worker-Knotenpools separat vom Rest des Clusters upgraden.

• Parallele Upgrades: Konfigurieren Sie den Upgradevorgang so, dass Gruppen von Knoten oder Knotenpools gleichzeitig aktualisiert werden.

Diese Optionen können das Risiko von Unterbrechungen kritischer Anwendungen und Dienste verringern und die gesamte Upgradezeit 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 dazu, was diese Optionen bewirken und wie Sie sie verwenden, finden Sie in den folgenden Abschnitten.

Upgrades überspringen

Ab Version 1.33 unterstützt Google Distributed Cloud Skip-Upgrades für alle Clustertypen. So können Sie einen Cluster in einem einzigen Vorgang auf eine Zielversion (1.33 oder höher) aktualisieren, die zwei Nebenversionen vor der aktuellen Version liegt. Sie können beispielsweise mit einem einzigen Vorgang ein Upgrade von Version 1.N.X direkt auf Version 1.N+2.Z durchführen.

In der folgenden Liste sehen Sie die Einführungsphase für diese Funktion pro Version, wobei die Version die Zielversion für das Upgrade ist:

• 1.34 und höher: GA
• 1.33: Vorschau
• 1.32 und niedriger: Nicht verfügbar

Durch das Überspringen von Upgrades können Sie schneller auf die neuesten Funktionen und Fehlerkorrekturen zugreifen als bei inkrementellen Upgrades. Durch das Überspringen von Upgrades kann auch die Zeit zwischen erforderlichen Upgradevorgängen verlängert werden, wodurch potenzielle Unterbrechungen reduziert werden. Sie können das Überspringen von Upgrades zusammen mit anderen Upgradeoptionen verwenden, z. B. selektive Worker-Knotenpool-Upgrades und parallele Upgrades.

Bei einem Skip-Upgrade wird der Cluster auf eine Zwischenversion aktualisiert und dann sofort auf die Zielversion. Diese Zwischenversion hat Auswirkungen, wenn Sie einen Registry-Spiegel verwenden. Weitere Informationen finden Sie unter Zusätzliche Anforderung für Registry-Spiegel.

Das Überspringen von Upgrades für Cluster befindet sich in der Vorschau für Version 1.33. Wir empfehlen, bei Produktionsclustern keine Skip-Upgrades von 1.31 auf 1.33 durchzuführen.

Voraussetzungen für das Upgrade überspringen

Das Verfahren für ein Skip-Upgrade unterscheidet sich nicht von dem für ein sequenzielles Upgrade, es gibt jedoch einige zusätzliche Voraussetzungen:

1. Prüfen Sie, ob der Cluster sich in einem Zustand befindet, in dem ein Skip-Upgrade nicht gegen die Regeln für Cluster- und Knotenpoolversionen verstößt:

   • Bevor Sie ein Skip-Upgrade für einen Administrator- oder Hybridcluster starten, müssen alle verwalteten Nutzercluster dieselbe Nebenversion wie der verwaltende Cluster haben.

   • Bevor Sie ein Skip-Upgrade für einen Nutzercluster starten, müssen Ihre Cluster die folgenden Kriterien erfüllen:

     • Der zugehörige verwaltende Administrator- oder Hybrid-Cluster ist zwei Nebenversionen höher als der Nutzercluster.

     • Alle Worker-Knotenpools für den Nutzercluster haben dieselbe Nebenversion wie der Nutzercluster.

2. Fügen Sie der Clusterkonfigurationsdatei die Annotation preview.baremetal.cluster.gke.io/skip-minor-version-cluster-upgrade hinzu:

   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: baremetal-demo
     namespace: cluster-baremetal-demo
     annotations:
       preview.baremetal.cluster.gke.io/skip-minor-version-cluster-upgrade: "enable"
   spec:
     type: user
     profile: default
     anthosBareMetalVersion:   1.36.100-gke.144
     ...
   

3. Aktualisieren Sie anthosBareMetalVersion in der Clusterkonfigurationsdatei auf die Zielversion des Upgrades, das übersprungen werden soll.

Wie bei sequenziellen Upgrades können Sie das Skip-Upgrade entweder mit bmctl upgrade cluster oder kubectl apply starten.

Zusätzliche Anforderung für Registry-Spiegel

Wenn Sie Container-Images von einer Registry-Spiegelung abrufen, um Ihren Cluster zu aktualisieren, muss Ihre Registry-Spiegelung die Images für die Zielversion und die Zwischenversion des Skip-Upgrades enthalten.

So bereiten Sie Ihren Registry-Mirror für ein Skip-Upgrade vor:

1. Ermitteln Sie mit der Version von bmctl, die der Zielversion des Skip-Upgrades entspricht, die Zwischenversion für das Skip-Upgrade:

   bmctl upgrade intermediate-version
   

   Die Befehlsantwort besteht aus der spezifischen Google Distributed Cloud-Patchversion, die das System als Zwischenversion während des Skip-Upgrades verwendet. Für bmctl-Version 1.33.0-gke.799 sieht die Antwort beispielsweise so aus:

   1.32.200-gke.104
   

2. Laden Sie die Image-Pakete für die Zielversion und die Zwischenversion herunter.

   Weitere Informationen finden Sie unter Bildpaket herunterladen.

3. Pushen Sie die Bildpakete für die Zielversion und die Zwischenversion in den Registrierungsspiegel, bevor Sie das Überspringen des Upgrades starten.

   Das Hosten von Container-Images für die Ziel- und Zwischenversionen erfordert zusätzlichen Speicherplatz für Ihren Registry-Spiegel.

Wie bei sequenziellen Upgrades können Sie das Skip-Upgrade entweder mit bmctl upgrade cluster oder kubectl apply starten.

Selektive Upgrades von Worker-Knotenpools

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 per Drain beendet und alle zugehörigen Pods neu gestartet und neu geplant werden. In diesem Abschnitt wird beschrieben, wie Sie bestimmte Worker-Knotenpools für ein Cluster-Upgrade ein- oder ausschließen können, um Unterbrechungen der Arbeitslast 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 den folgenden Situationen verwenden:

• Sicherheitskorrekturen ohne Unterbrechung von Arbeitslasten anwenden:Sie können nur Ihre Steuerungsebenenknoten (und Load-Balancer-Knoten) aktualisieren, um Kubernetes-Sicherheitslücken zu beheben, ohne Ihre Worker-Knotenpools zu unterbrechen.

• Ordnungsgemäßen Betrieb einer aktualisierten Teilmenge von Worker-Knoten bestätigen, 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 Upgraden eines großen Clusters kann zeitaufwendig sein und es ist schwierig, genau vorherzusagen, wann ein Upgrade abgeschlossen sein wird. Die Zeit für das Cluster-Upgrade ist proportional zur Anzahl der Knoten, für die ein Upgrade durchgeführt wird. Wenn Sie die Anzahl der Knoten, für die ein Upgrade durchgeführt wird, reduzieren, indem Sie Knotenpools ausschließen, verkürzt sich die Upgrade-Zeit. Sie führen mehrere Upgrades durch, aber die kleineren, besser planbaren Wartungsfenster können bei der Terminplanung helfen.

Versionsabweichung von Knotenpools um zwei Nebenversionen

Bei Clustern mit Version 1.28 und höher kann die Version eines Worker-Knotenpools bis zu zwei Nebenversionen hinter der Clusterversion (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.36 haben, können Sie Worker-Knotenpools mit ausgewählten Versionen 1.36, 1.35 und 1.34 haben.

Bevor Sie ein Upgrade für einen Cluster durchführen 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 unterstützten Worker-Knotenpoolversionen, die von einer bestimmten Clusterversion unterstützt werden (gilt für Version 1.29 und früher), finden Sie unter Regeln für die Versionsverwaltung von Knotenpools.

1.30 und höher

In Version 1.30 ist die Unterstützung für Versionsabweichungen vom Typ n-2 für Worker-Knotenpools für alle Clustertypen allgemein verfügbar. Dieses Feature 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 identisch oder niedriger ist.

1,29

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

Da wir diese Funktion von der öffentlichen Vorschau zur allgemeinen Verfügbarkeit überführen, ist für Hybridcluster in der folgenden Situation weiterhin die Vorschau-Annotation 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 Annotation preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable hinzufügen, bevor Sie ihn auf Version 1.29.z aktualisieren:

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

Vorschau

Dieses Produkt oder Feature unterliegt den „Bedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Features sind "im Ist-Zustand" verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Startphase.

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 Vorabfunktion aktivieren möchten, fügen Sie die Annotation preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable in Ihre Clusterkonfigurationsdatei ein:

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 Worker-Knotenpools finden Sie unter Regeln für die Versionsverwaltung von Knotenpools im Abschnitt „Lebenszyklus und Phasen von Cluster-Upgrades“.

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

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

1. 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 Ziel-Upgradeversion des Clusters fest.
   • Lassen Sie das Feld anthosBareMetalVersion in der NodePool-Spezifikation weg oder legen Sie es auf den leeren String fest. Standardmäßig sind Worker-Knotenpools in Cluster-Upgrades enthalten.

2. Legen Sie für die Worker-Knotenpools, die Sie aus dem Upgrade ausschließen möchten, anthosBareMetalVersion auf die aktuelle Version (vor dem Upgrade) des Clusters fest:

3. Fahren Sie mit dem Upgrade fort, wie unter Clusterupgrade starten beschrieben.

   Beim Clusterupgrade werden die folgenden Knoten aktualisiert:

   • Knoten der Cluster-Steuerungsebene
   • Load-Balancer-Knotenpool, falls Ihr Cluster einen verwendet (spec.loadBalancer.nodePoolSpec). Standardmäßig können auf Load-Balancer-Knoten reguläre Arbeitslasten ausgeführt werden. Sie können einen Load-Balancer-Knotenpool nicht selektiv upgraden. Er ist immer im ursprünglichen Clusterupgrade enthalten.
   • Worker-Knotenpools, die Sie nicht vom Upgrade ausgeschlossen haben.

Angenommen, Ihr Cluster hat die Version 1.35.0 und zwei Worker-Knotenpools: wpool01 und wpool02. Angenommen, Sie möchten die Steuerungsebene und wpool01 auf 1.36.100-gke.144 aktualisieren, wpool02 soll aber auf Version 1.35.0 bleiben.

Der folgende Auszug aus einer 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.36.100-gke.144
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.36.100-gke.144
  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.35.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, mit dem die Knotenpools auf die Zielclusterversion aktualisiert werden. Bei Worker-Knotenpools, die von einem Clusterupgrade ausgeschlossen wurden, ist das Feld anthosBareMetalVersion in der NodePool-Spezifikation auf die vorherige (vor dem Upgrade) Clusterversion festgelegt.

So aktualisieren Sie Worker-Knotenpools auf die aktuelle, aktualisierte Clusterversion:

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

   Wenn mehrere Worker-Knotenpools für das Upgrade ausgewählt sind, bestimmt der Wert vonspec.nodePoolUpgradeStrategy.concurrentNodePools in der Clusterspezifikation, wie viele Knotenpools parallel aktualisiert werden. Wenn Sie Worker-Knotenpools nicht gleichzeitig upgraden möchten, wählen Sie jeweils einen Knotenpool für das Upgrade aus.

2. Fahren Sie mit dem Upgrade fort, wie unter Clusterupgrade starten beschrieben.

   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.36.100-gke.144 aktualisiert, aber der Knotenpool wpool02 hat immer noch die alte Clusterversion 1.35.0. Arbeitslasten werden ordnungsgemäß im aktualisierten Knotenpool wpool01 ausgeführt. Jetzt möchten Sie auch wpool02 auf die aktuelle Clusterversion aktualisieren. 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 ä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.36.100-gke.144
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.36.100-gke.144
  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. Wenn nach dem Upgrade eines Worker-Knotenpools ein Problem auftritt, können Sie ein Rollback des Knotenpools auf die vorherige Version durchführen.

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

1.30 und höher

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

1,29

Vorschau

Dieses Produkt oder Feature unterliegt den „Bedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Features sind "im Ist-Zustand" verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Startphase.

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

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

1,28

Die Funktion zum Rollback von Knotenpools ist für Cluster mit der Nebenversion 1.28 oder früher nicht verfügbar.

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

bmctl

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

1. Bearbeiten Sie die NodePool-Spezifikationen in der Clusterkonfigurationsdatei für die Worker-Knotenpools, für die Sie ein Rollback zur vorherigen Version durchführen möchten. Legen Sie anthosBareMetalVersion auf die vorherige (vor dem Upgrade) Clusterversion fest.

   ...
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: NodePool
   metadata:
     name: wpool01
     namespace: cluster-user001
   spec:
     clusterName: user001
     anthosBareMetalVersion: 1.35.500-gke.142
     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, bestimmt der Wert von spec.nodePoolUpgradeStrategy.concurrentNodePools in der Clusterspezifikation, wie viele Knotenpools parallel zurückgesetzt werden. Wenn Sie kein gleichzeitiges Rollback für Worker-Knotenpools durchführen möchten, wählen Sie jeweils einen Knotenpool für das Rollback aus oder aktualisieren Sie die nodePoolUpgradeStrategy-Einstellungen. Ebenso bestimmt der Wert von spec.upgradeStrategy.parallelUpgrade.concurrentNodes in der NodePool-Spezifikation, wie viele Knoten parallel zurückgesetzt werden.

2. 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 Standalone-Cluster).

   Das Rollback wird automatisch gestartet. Der Befehl bmctl update cluster wird sofort beendet, das Rollback wird jedoch fortgesetzt. Führen Sie keine anderen Vorgänge für den Cluster aus, während der Rollback läuft.

3. 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 Reset-Job auf dem Knoten aus, um ihn in einen sauberen Zustand zu versetzen.
   • Führen Sie Preflight-Prüfungen für den Knoten aus.
   • Führen Sie einen Machine-Init-Job auf dem Knoten aus, um ihn mit der Rollback-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 Ziel-Rollback-Version festgelegt.

Verwenden Sie bmctl update und kubectl apply -f nicht austauschbar, wenn Sie die Clusterkonfigurationsdatei bearbeiten. Wenn diese Befehle abwechselnd verwendet werden, werden möglicherweise Inhalte entfernt, die durch den Header der Clusterspezifikation eingefügt wurden. 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 Clusterspezifikation, aber im Cluster vorhanden ist.

kubectl

Sie können ein Rollback für ein Knotenpool-Upgrade durchführen, indem Sie die NodePool-Ressource direkt mit kubectl bearbeiten:

1. Um ein Rollback für einen Worker-Knotenpool durchzuführen, ö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: der Name des Knotenpools, für den Sie das 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 Standalone-Cluster).

2. Ä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.35.500-gke.142
     nodes:
     - address:  10.200.0.1
     - address:  10.200.0.2
     - address:  10.200.0.3
     ...
   

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

   Das Rollback wird automatisch gestartet. Führen Sie keine anderen Vorgänge für den Cluster aus, während der Rollback läuft.

4. 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 Reset-Job auf dem Knoten aus, um ihn in einen sauberen Zustand zu versetzen.
   • Führen Sie Preflight-Prüfungen für den Knoten aus.
   • Führen Sie einen Machine-Init-Job auf dem Knoten aus, um ihn mit der Rollback-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 Ziel-Rollback-Version festgelegt.

Parallele Upgrades

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

Achtung: Wenn Sie verwaltete Datendienste wie Portworx verwenden, um zustandsorientierte Arbeitslasten in Ihren Clustern zu verwalten, empfehlen wir, keine parallelen Upgrades durchzuführen.

Es gibt zwei parallele Upgradestrategien, mit denen Sie das Cluster-Upgrade 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 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.

• Gleichzeitiges Upgrade von Knotenpools: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 Mindestschwellenwert für die Anzahl der Knoten festlegen, auf denen während des gesamten Aktualisierungsprozesses Arbeitslasten ausgeführt werden können (minimumAvailableNodes). Diese Konfiguration erfolgt in der NodePool-Spezifikation. Weitere Informationen zu diesen Konfigurationsfeldern finden Sie in der Feldreferenz für die Clusterkonfiguration.

Wichtig :Bei parallelen Upgrades wird das Budget für Pod-Störungen (Pod Disruption Budget, PDB) nicht berücksichtigt. Wenn Ihre Arbeitslasten anfällig für Störungen sind, empfehlen wir die Verwendung des Felds minimumAvailableNodes. Sie können die Mindestanzahl von Knoten angeben, die während des gesamten Upgradeprozesses für die Ausführung von Arbeitslasten verfügbar sein müssen.

Die Knoten-Upgradestrategie gilt nur für Worker-Knotenpools. Sie können keine Knoten-Upgradestrategie für Knotenpools der Steuerungsebene oder Load-Balancer-Knotenpools angeben. Während eines Clusterupgrades werden Knoten in Knotenpools der Steuerungsebene und Load Balancer 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 entweder 50 % 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, 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. 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 5 Knoten aktualisiert. Damit das Upgrade fortgesetzt werden kann, müssen mindestens 4 Knoten verfügbar bleiben:

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 

Strategie für Knotenpoolupgrades

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 aktualisiert. Wenn Sie concurrentNodePools auf 0 festlegen, werden alle Worker-Knotenpools im Cluster parallel aktualisiert.

Knotenpools der Steuerungsebene und des Load-Balancing 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:

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

   Sie können dieses Manifest separat oder als Teil der Clusterkonfigurationsdatei anwenden, wenn Sie ein Clusterupdate durchfü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. Das bedeutet, dass 5 Knoten parallel aktualisiert werden. Das Feld minimumAvailableNodes ist auf 10 festgelegt. Das bedeutet, dass während des gesamten 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 angeben.

2. 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.36.100-gke.144
     ...
     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 wird in den NodePool-Spezifikationen definiert.

3. Führen Sie ein Upgrade des Clusters durch, wie im vorherigen Abschnitt Administrator-, eigenständige, Hybrid- oder Nutzercluster aktualisieren beschrieben.

Standardwerte für parallele Upgrades

Parallele Upgrades sind standardmäßig deaktiviert und die Felder für parallele Upgrades sind veränderbar. Sie können die Felder jederzeit entfernen oder auf ihre Standardwerte zurücksetzen, um die Funktion 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.
upgradeStrategy.parallelUpgrade.concurrentNodes (NodePool-Spezifikation)	1	Führen Sie ein Upgrade der Knoten nacheinander durch.
upgradeStrategy.parallelUpgrade.minimumAvailableNodes (NodePool-Spezifikation)	Der Standardwert für minimumAvailableNodes hängt vom Wert von concurrentNodes ab. Wenn Sie concurrentNodes nicht angeben, ist 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, sobald minimumAvailableNodes erreicht ist, und erst fortgesetzt, wenn die Anzahl der verfügbaren Knoten größer als minimumAvailableNodes ist.

Clusterupgrade starten

Dieser Abschnitt enthält eine Anleitung zum Aktualisieren von Clustern.

Hinweis: Beachten Sie, dass Sie einen Administratorcluster aktualisieren sollten, bevor Sie einen zugehörigen Nutzercluster aktualisieren. Bevor Sie jedoch den Administratorcluster auf Version 1.36.100-gke.144 aktualisieren, prüfen Sie, ob die zugehörigen Nutzercluster die Version 1.35.0 oder höher haben. bmctl gibt einen Fehler aus, wenn ein Nutzercluster eine Version unter 1.35.0 hat.

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.

1. 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.

2. Laden Sie die aktuelle bmctl herunter, wie unter Google Distributed Cloud-Downloads beschrieben.

3. Aktualisieren Sie anthosBareMetalVersion in der Clusterkonfigurationsdatei auf die Zielversion für das Upgrade.

   Die Zielversion des Upgrades muss mit der Version der heruntergeladenen bmctl-Datei übereinstimmen. Das folgende Snippet aus einer 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.36.100-gke.144
   

4. 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 :Der Befehl bmctl upgrade aktualisiert nur den Wert anthosBareMetalVersion und die Vorschauanmerkungen in der benutzerdefinierten Clusterressource. 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 Knotenzustand zu validieren. Das Clusterupgrade wird nicht fortgesetzt, wenn die Preflight-Prüfungen fehlschlagen. Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung bei Problemen bei der Clusterinstallation oder beim Clusterupgrade.

   Wenn alle Clusterkomponenten erfolgreich aktualisiert wurden, werden im Rahmen des Cluster-Upgrade-Vorgangs Systemdiagnosen für den Cluster durchgeführt. Mit diesem letzten Schritt wird überprüft, ob der Cluster ordnungsgemäß funktioniert. Wenn der Cluster nicht alle Systemdiagnosen besteht, werden sie so lange ausgeführt, bis sie bestanden werden. Wenn alle Systemdiagnosen bestanden wurden, ist das Upgrade abgeschlossen.

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

kubectl

So aktualisieren Sie einen Cluster mit kubectl:

1. Bearbeiten Sie die Cluster-Konfigurationsdatei, um anthosBareMetalVersion auf die Zielversion für das Upgrade festzulegen.

2. 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-Vorgang mit bmctl werden Preflight-Prüfungen als Teil des Clusterupgrades ausgeführt, um den Clusterstatus und den Knotenzustand zu validieren. Wenn die Preflight-Prüfungen fehlschlagen, wird das Clusterupgrade angehalten. Zur Fehlerbehebung müssen Sie den Cluster und die zugehörigen Logs prüfen, da kein Bootstrap-Cluster erstellt wird. Weitere Informationen finden Sie unter Probleme bei der Clusterinstallation oder beim Clusterupgrade 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 allgemein verfügbar für Cluster, bei denen alle Knoten der Steuerungsebene die Nebenversion 1.29 oder höher haben.

Es gibt folgende Gründe zum Pausieren eines Upgrades:

• 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, werden die folgenden Vorgänge unterstützt:

• Knoten hinzufügen oder entfernen
• Knotenpools hinzufügen oder entfernen
• Reichweite des Servicenetzwerks erhöhen
• Cluster aus einer Sicherung wiederherstellen

Wenn ein neuer Knoten hinzugefügt wird, während ein Upgrade pausiert ist, werden keine Machine-Check-Jobs darauf ausgeführt, bis das Upgrade fortgesetzt und abgeschlossen ist.

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

• Zertifizierungsstellen rotieren
• Cluster sichern

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

Upgrade pausieren und fortsetzen aktivieren

Google Distributed Cloud 1.36

Die Funktion zum Pausieren und Fortsetzen von 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.35

Vorschau

Dieses Produkt oder Feature unterliegt den „Bedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Features sind "im Ist-Zustand" verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Startphase.

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

So aktivieren Sie das Pausieren und Fortsetzen von Upgrades:

1. Fügen Sie Ihrer 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:
   ...
   

2. So übernehmen Sie die Änderung:

   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 Standalone-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 ist änderbar. Sie können sie jederzeit hinzufügen und aktualisieren.

Upgrade pausieren

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

So pausieren Sie ein aktives Cluster-Upgrade:

1. 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 das Upgrade mit bmctl gestartet haben, benötigen Sie ein neues Terminalfenster für den nächsten Schritt.

2. So übernehmen Sie die Änderung:

   bmctl update CLUSTER_NAME
   

   Das Upgrade wurde pausiert. Es werden keine neuen Knotenupgrades ausgelöst.

3. Wenn Sie das Upgrade mit bmctl gestartet haben und eine längere Pause planen, drücken Sie Strg+C, um bmctl zu beenden. Andernfalls lassen Sie bmctl weiterlaufen.

   Die bmctl CLI erkennt keine Änderungen am Pausenstatus für das Upgrade und wird daher nicht automatisch beendet. Wenn Sie bmctl beenden, wird der Fortschritt des Upgrades nicht mehr in der Protokolldatei cluster-upgrade-TIMESTAMP im Clusterordner auf Ihrer Administratorworkstation und in Cloud Logging protokolliert. Daher solltest du bmctl bei kurzen Pausen aktiviert lassen. Wenn Sie bmctl für längere Zeit ausführen, während das Upgrade pausiert ist, tritt schließlich ein Zeitüberschreitungsfehler auf.

Angehaltenes Upgrade fortsetzen

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

So setzen Sie ein angehaltenes Cluster-Upgrade fort:

1. Legen Sie nodePoolUpgradeStrategy.pause in der Clusterkonfigurationsdatei 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 es standardmäßig auf false festgelegt ist.

2. So übernehmen Sie die Änderung:

   bmctl update CLUSTER_NAME
   

   Der Upgradevorgang wird dort fortgesetzt, wo er unterbrochen wurde.

3. Wenn Sie den Status des Upgrades prüfen möchten, rufen Sie zuerst eine Liste der Ressourcen ab, die anthosBareMetalVersion in ihrem status haben:

   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. Jedes 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
   

4. So prüfen Sie die status.anthosBareMetalVersion (aktuelle Version der Ressource):

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

   Das folgende Beispiel zeigt 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 hat der Knoten die Google Distributed Cloud-Version 1.16.2.