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 Ihrem Cluster zusätzliche Features 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 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 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 Clusterupgrades 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 die Problemkategorie Upgrades und Updates aus.

Upgrade-Optionen konfigurieren

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

• Selektive Upgrades von Worker-Knotenpools: Bestimmte Worker-Knotenpools können separat vom Rest des Clusters aktualisiert werden.

• 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 verringern und die Gesamtdauer des Upgrades 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 zu diesen Optionen und ihrer Verwendung finden Sie in den folgenden Abschnitten.

Upgrades überspringen

Ab Version 1.33 unterstützt Google Distributed Cloud Überspringen-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 ist die Einführungsphase für dieses Feature pro Version aufgeführt, wobei die Version die Zielversion des Upgrades ist:

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

Mit Skip-Upgrades können Sie schneller auf die neuesten Funktionen und Fehlerkorrekturen zugreifen als mit 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 übersprungene Upgrades zusammen mit anderen Upgradeoptionen verwenden, z. B. selektive Worker-Knotenpool-Upgrades und parallele Upgrades.

Bei einem übersprungenen Upgrade wird der Cluster auf eine Zwischenversion und dann sofort auf die Zielversion aktualisiert. 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 Vorabversion für Version 1.33. Wir empfehlen, bei Produktionsclustern keine übersprungenen Upgrades von 1.31 auf 1.33 durchzuführen.

Voraussetzungen für das Upgrade überspringen

Der Vorgang zum Ausführen eines übersprungenen Upgrades unterscheidet sich nicht von dem eines sequenziellen Upgrades, es gibt jedoch einige zusätzliche Voraussetzungen:

1. Prüfen Sie, ob der Cluster einen Status hat, in dem ein übersprungenes Upgrade nicht gegen die Versionsregeln für Cluster und Knotenpools verstößt:

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

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

     • Der zugehörige verwaltende Administrator- oder Hybridcluster 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 die Annotation preview.baremetal.cluster.gke.io/skip-minor-version-cluster-upgrade zur Clusterkonfigurationsdatei 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.200-gke.118
     ...
   

3. Aktualisieren Sie anthosBareMetalVersion in der Clusterkonfigurationsdatei auf die Zielversion des übersprungenen Upgrades.

Wie bei sequenziellen Upgrades können Sie das Überspringen des Upgrades entweder mit bmctl upgrade cluster oder kubectl apply starten.

Zusätzliche Anforderung für Registry-Spiegel

Wenn Sie Container-Images aus einer Registry-Spiegelung abrufen, um ein Upgrade Ihres Clusters durchzuführen, muss die Registry-Spiegelung die Images sowohl für die Zielversion als auch für die Zwischenversion des übersprungenen Upgrades enthalten.

So bereiten Sie Ihren Registry-Spiegel für ein Überspringen-Upgrade vor:

1. Ermitteln Sie mit der Version von bmctl, die der Zielversion des Überspringens des Upgrades entspricht, die Zwischenversion für das Überspringen des Upgrades:

   bmctl upgrade intermediate-version
   

   Die Befehlsantwort besteht aus der spezifischen Google Distributed Cloud-Patchversion, die das System als Zwischenversion während des übersprungenen Upgrades verwendet. Für die 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 Image-Paket herunterladen.

3. Übertragen Sie die Image-Pakete für die Zielversion und die Zwischenversion per Push in den Registry-Spiegel, bevor Sie das Upgrade starten.

   Für das Hosten von Container-Images für die Ziel- und Zwischenversionen ist zusätzlicher Speicherplatz für Ihren Registry-Spiegel erforderlich.

Wie bei sequenziellen Upgrades können Sie das Überspringen des Upgrades entweder mit bmctl upgrade cluster oder kubectl apply starten.

Selektive Upgrades von Worker-Knotenpools

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

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

• Sicherheitskorrekturen ohne Unterbrechung von Arbeitslasten übernehmen: Sie können nur ein Upgrade der Knoten der Steuerungsebene (und der Load-Balancer-Knoten) durchführen, um Kubernetes-Sicherheitskorrekturen anzuwenden, ohne die Worker-Knotenpools zu unterbrechen.

• So prüfen Sie, ob eine aktualisierte Teilmenge von Worker-Knoten ordnungsgemäß funktioniert, bevor Sie alle Worker-Knoten aktualisieren: Sie können Ihre Worker-Knotenpools selektiv aktualisieren, um sicherzustellen, dass Arbeitslasten auf einem aktualisierten Knotenpool ordnungsgemäß ausgeführt werden, bevor Sie einen anderen Knotenpool aktualisieren.

• Wartungsfenster reduzieren: Das Upgrade eines großen Clusters kann zeitaufwendig sein und es ist schwierig, genau vorherzusagen, wann ein Upgrade abgeschlossen sein wird. Die Dauer des Clusterupgrades ist proportional zur Anzahl der aktualisierten Knoten. Wenn Sie die Anzahl der Knoten, für die ein Upgrade durchgeführt wird, durch Ausschließen von Knotenpools reduzieren, verkürzt sich die Upgradezeit. Sie führen mehrere Upgrades durch, aber die kleineren, besser vorhersehbaren Wartungsfenster können bei der Planung helfen.

Versionsabweichung von zwei Nebenversionen für Knotenpools

Bei Clustern der 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 von 1.36, 1.35 und 1.34 haben.

Bevor Sie ein Upgrade für einen Cluster ausfü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 mit Version 1.29 und Worker-Knotenpools mit Version 1.29, Version 1.28 und Version 1.16 haben, müssen Sie die Knotenpools mit 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 übereinstimmt 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. Diese Funktion ist standardmäßig für Cluster mit Version 1.29 aktiviert.

Während wir diese Funktion von der öffentlichen Vorschau auf die allgemeine Verfügbarkeit umstellen, ist die Vorschau-Annotation für Hybridcluster in der folgenden Situation weiterhin erforderlich. Wenn Sie einen Hybridcluster der Version 1.28.x mit einem Worker-Knotenpool der Version 1.16.y haben, müssen Sie die Annotation preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable zum Cluster 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 diese Funktion unterliegt den „Pre-GA-Angebotsbedingungen“ 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 Vorschaufunktion aktivieren möchten, fügen Sie der Clusterkonfigurationsdatei die Annotation 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 Worker-Knotenpools finden Sie unter Regeln für die Versionsverwaltung von Knotenpools im Abschnitt „Lebenszyklus und Phasen von Clusterupgrades“.

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

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

1. Nehmen Sie für die Worker-Knotenpools, die Sie in das Clusterupgrade einbeziehen möchten, eine der folgenden Änderungen an der NodePool-Spezifikation vor:

   • Legen Sie anthosBareMetalVersion in der NodePool-Spezifikation auf die Zielversion des Clusterupgrades 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 Clusterupgrades enthalten.

2. Legen Sie für die Worker-Knotenpools, die Sie vom Upgrade ausschließen möchten, anthosBareMetalVersion auf die aktuelle Version des Clusters (vor dem Upgrade) 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, wenn Ihr Cluster einen verwendet (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.35.0 und zwei Worker-Knotenpools: wpool01 und wpool02. Angenommen, Sie möchten die Steuerungsebene und wpool01 auf 1.36.200-gke.118 aktualisieren, aber wpool02 soll auf Version 1.35.0 bleiben.

Der folgende Auszug aus der Clusterkonfigurationsdatei zeigt, wie Sie die Clusterkonfiguration ändern können, um dieses Teilupgrade 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.200-gke.118
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.36.200-gke.118
  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

Upgrade von Knotenpools auf die aktuelle Clusterversion durchführen

Wenn Sie Knotenpools von einem Clusterupgrade ausgeschlossen haben, können Sie ein Clusterupgrade ausführen, um sie auf die Zielclusterversion zu aktualisieren. 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 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 Clusterversion (nach dem Upgrade) fest.

   Wenn mehrere Worker-Knotenpools für das Upgrade ausgewählt sind, bestimmt der Wert von 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 einen Knotenpool für das Upgrade aus.

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

   Beim Clusterupgrade 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.200-gke.118 aktualisiert, aber der Knotenpool wpool02 hat noch die alte Clusterversion 1.35.0, die vor dem Upgrade verwendet wurde. Arbeitslasten werden im aktualisierten Knotenpool wpool01 ordnungsgemäß ausgeführt. Jetzt möchten Sie auch wpool02 auf die aktuelle Clusterversion aktualisieren. Wenn Sie ein Upgrade für wpool02 ausführen möchten, können Sie das Feld anthosBareMetalVersion entfernen oder seinen Wert auf den leeren String festlegen.

Der folgende Auszug aus der Clusterkonfigurationsdatei zeigt, wie Sie die Clusterkonfiguration ändern können, um dieses Teilupgrade 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.200-gke.118
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.36.200-gke.118
  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 Knoten der Steuerungsebene der Version 1.30) ist die Funktion zum Rollback von Knotenpools allgemein verfügbar und standardmäßig aktiviert.

1,29

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Pre-GA-Angebotsbedingungen“ 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 verfügbar (Cluster mit Knoten der Steuerungsebene der Version 1.29). Solange sich diese Funktion im Vorschaumodus befindet, müssen Sie der Ressource Cluster die folgende Annotation 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 ein Knotenpool-Upgrade mit bmctl rückgängig 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 auf die vorherige Version durchführen 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.35.600-gke.141
     nodes:
     - address:  10.200.0.1
     - address:  10.200.0.2
     - address:  10.200.0.3
     ...
   

   Wenn mehrere Worker-Knotenpools für den Rollback ausgewählt sind, bestimmt der Wert von spec.nodePoolUpgradeStrategy.concurrentNodePools in der Clusterspezifikation, wie viele Knotenpools parallel zurückgesetzt werden. Wenn Sie Worker-Knotenpools nicht gleichzeitig zurücksetzen 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 Spezifikation NodePool, 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 eigenständig).

   Der Rollback wird automatisch gestartet. Der Befehl bmctl update cluster wird sofort beendet, aber das Rollback wird fortgesetzt. Führen Sie während des Rollbacks keine anderen Vorgänge im Cluster aus.

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 die Maschine auf dem 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 Ressource NodePool auf die Ziel-Rollback-Version gesetzt.

Verwenden Sie bmctl update und kubectl apply -f nicht austauschbar, wenn Sie die Clusterkonfigurationsdatei bearbeiten. Wenn diese Befehle austauschbar verwendet werden, werden Inhalte, die vom Header der Clusterspezifikation ausgefüllt werden, möglicherweise unbeabsichtigt 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 Rollback für ein Knotenpool-Upgrade durchführen, indem Sie die Ressource NodePool direkt mit kubectl bearbeiten:

1. Öffnen Sie zum Rollback eines Worker-Knotenpools die Ressource NodePool 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 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).

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.600-gke.141
     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.

   Der Rollback wird automatisch gestartet. Führen Sie während des Rollbacks keine anderen Vorgänge im Cluster aus.

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 auf dem Knoten Preflight-Prüfungen für die Maschine 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 Ressource NodePool auf die Ziel-Rollback-Version gesetzt.

Parallele Upgrades

Bei einem typischen Standard-Clusterupgrade wird jeder Clusterknoten nacheinander aktualisiert. In diesem Abschnitt erfahren Sie, wie Sie Ihren Cluster und Ihre Worker-Knotenpools so konfigurieren, dass beim Upgrade Ihres Clusters mehrere Knoten parallel aktualisiert werden. Durch das parallele Upgrade 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 Ihr 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 NodePool-Spezifikation (spec.upgradeStrategy.parallelUpgrade) konfiguriert. Nur Knoten in einem Worker-Knotenpool können parallel aktualisiert werden. Knoten in Knotenpools der Steuerungsebene oder des Load Balancers können nur einzeln aktualisiert werden. Weitere Informationen finden Sie unter Strategie für das Knotenupgrade.

• Gleichzeitiges 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 Mindestschwellenwert für die Anzahl der Knoten festlegen, die während des gesamten Upgrades Arbeitslasten ausführen können (minimumAvailableNodes). Diese Konfiguration wird in der NodePool-Spezifikation vorgenommen. Weitere Informationen zu diesen Feldern finden Sie in der Referenz zu Clusterkonfigurationsfeldern.

Wichtig: Bei parallelen Upgrades wird das Budget für Pod-Störungen (Pod Disruption Budget, PDB) nicht berücksichtigt. Wenn Ihre Arbeitslasten empfindlich auf Unterbrechungen reagieren, empfehlen wir, das Feld minimumAvailableNodes zu verwenden. Sie können die Mindestanzahl von Knoten angeben, die während des gesamten Upgrades für die Ausführung von Arbeitslasten verfügbar bleiben müssen.

Die Knoten-Upgradestrategie gilt nur für Worker-Knotenpools. Sie können keine Knotenupgradestrategie 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 (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 weder 50 % der Anzahl der Knoten im Knotenpool noch die feste Anzahl von 15 ü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 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. Mindestens 4 Knoten müssen 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 

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

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 ausführen.

   Beispiel:

   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: NodePool
   metadata:
     name: np1
     namespace: cluster-ci-bf8b9aa43c16c47
   spec:
     clusterName: ci-bf8b9aa43c16c47
     nodes:
     - address:  10.200.0.1
     - address:  10.200.0.2
     - address:  10.200.0.3
     ...
     - address:  10.200.0.30
     upgradeStrategy:
       parallelUpgrade:
         concurrentNodes: 5
         minimumAvailableNodes: 10
   

   In diesem Beispiel ist der Wert des Felds concurrentNodes 5, was bedeutet, dass 5 Knoten parallel aktualisiert werden. Das Feld minimumAvailableNodes ist auf 10 festgelegt. Das bedeutet, dass während des Upgrades mindestens 10 Knoten für Arbeitslasten verfügbar bleiben müssen.

   Hinweis: Sie können keine Knotenupgradestrategie 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.200-gke.118
     ...
     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 ä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	Knoten nacheinander aktualisieren.
upgradeStrategy.parallelUpgrade.minimumAvailableNodes (NodePool-Spezifikation)	Der Standardwert für minimumAvailableNodes hängt vom Wert von concurrentNodes ab. Wenn Sie concurrentNodes nicht angeben, beträgt minimumAvailableNodes standardmäßig zwei Drittel der Größe des Knotenpools. 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 Upgrade 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.200-gke.118 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 vor 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 neueste bmctl-Version herunter, wie unter Google Distributed Cloud-Downloads beschrieben.

3. Aktualisieren Sie anthosBareMetalVersion in der Clusterkonfigurationsdatei auf die Zielversion des Upgrades.

   Die Zielversion des Upgrades muss mit der Version der heruntergeladenen bmctl-Datei ü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.36.200-gke.118
   

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 Vorschauannotationen 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 Probleme bei der Clusterinstallation oder beim Clusterupgrade beheben.

   Sobald alle Clusterkomponenten aktualisiert wurden, werden im Rahmen des Cluster-Upgrades Cluster-Systemdiagnosen ausgeführt. Mit diesem letzten Schritt wird überprüft, ob der Cluster in einem guten Betriebszustand ist. 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 zur Abfolge von Ereignissen bei 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 des Upgrades 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 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. Prüfen Sie zur Fehlerbehebung den Cluster und die zugehörigen Logs, 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 aktuelle Version von bmctl, um Cluster mit kubectl zu aktualisieren, wir empfehlen jedoch, die aktuelle Version von bmctl herunterzuladen. Sie müssen bmctl verwenden, 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 Clusterupgrade pausiert wird, werden keine neuen Worker-Knotenupgrades 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. Das Feature ist für Cluster mit allen Knoten der Steuerungsebene in der Nebenversion 1.29 oder höher allgemein verfügbar.

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

• Knoten hinzufügen oder entfernen
• Knotenpools hinzufügen oder entfernen
• Bereich des Dienstnetzwerks vergrößern
• Cluster aus einer Sicherung wiederherstellen

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

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

• Zertifizierungsstellen rotieren
• Cluster sichern

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

Pausieren und Fortsetzen von Upgrades 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 diese Funktion unterliegt den „Pre-GA-Angebotsbedingungen“ 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 Annotation in der Clusterressource aktivieren.

So aktivieren Sie das Pausieren und Fortsetzen von Upgrades:

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

2. Aktualisieren Sie den Cluster, um die Änderung 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: 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 ist änderbar. 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 setzen.

So pausieren Sie ein aktives Clusterupgrade:

1. Fügen Sie nodePoolUpgradeStrategy.pause der Clusterkonfigurationsdatei 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 initiiert haben, benötigen Sie ein neues Terminalfenster, um den nächsten Schritt auszuführen.

2. Aktualisieren Sie den Cluster, um die Änderung zu übernehmen:

   bmctl update CLUSTER_NAME
   

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

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

   Die bmctl-Befehlszeile erkennt keine Änderungen am Status der Upgrade-Pause und wird daher nicht automatisch beendet. Wenn Sie bmctl jedoch beenden, wird der Upgradefortschritt nicht mehr in der Logdatei cluster-upgrade-TIMESTAMP im Clusterordner auf Ihrer Administratorworkstation und in Cloud Logging protokolliert. Bei kurzen Pausen sollten Sie bmctl daher möglicherweise weiter ausführen. Wenn Sie bmctl über einen längeren Zeitraum ausführen, während das Upgrade pausiert ist, kommt es schließlich zu einer Zeitüberschreitung.

Pausiertes Upgrade fortsetzen

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

So setzen Sie ein pausiertes Clusterupgrade fort:

1. Legen Sie nodePoolUpgradeStrategy.pause auf die Clusterkonfigurationsdatei und 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 gesetzt ist.

2. Aktualisieren Sie den Cluster, um die Änderung zu übernehmen:

   bmctl update CLUSTER_NAME
   

   Der Upgradevorgang wird an der Stelle fortgesetzt, an der 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 ihrer 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. 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
   

4. So prüfen Sie die status.anthosBareMetalVersion (aktuelle Version der Ressource) und rufen Details zu einzelnen Ressourcen ab:

   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.