Cluster aktualisieren

Wenn Sie eine neue Version von bmctl installieren, können Sie Ihre vorhandenen Cluster aktualisieren, die mit einer früheren Version erstellt wurden. Durch ein Upgrade eines Clusters auf die neueste Google Distributed Cloud-Version werden zusätzliche Funktionen und Fehlerkorrekturen für Ihren Cluster bereitgestellt. Außerdem wird Ihr Cluster 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.

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

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

Bekannte Probleme

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

Upgradeoptionen konfigurieren

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

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

• Parallele Upgrades: Sie können den Upgradevorgang so konfigurieren, 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 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 dazu, was diese Optionen bewirken und wie Sie sie verwenden, finden Sie in den folgenden Abschnitten.

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 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, die aktualisiert werden. Wenn Sie die Anzahl der Knoten, die aktualisiert werden, durch Ausschließen von Knotenpools verringern, verkürzt sich die Upgradezeit. Sie führen mehrere Upgrades durch, aber die kleineren, besser planbaren Wartungsfenster können bei der Planung helfen.

Abweichung der Knotenpoolversion um zwei Nebenversionen

Bei Clustern ab Version 1.28 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.32 haben, können Sie Worker-Knotenpools mit ausgewählten Versionen 1.32, 1.31 und 1.30 haben.

Bevor Sie einen Cluster upgraden 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-Knotenpool-Versionen, 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.

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

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

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 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 Cluster-Upgrade 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 Cluster-Upgrade enthalten.
   • Worker-Knotenpools, die Sie nicht vom Upgrade ausgeschlossen haben.

Angenommen, Ihr Cluster hat die Version 1.31.0 und zwei Worker-Knotenpools: wpool01 und wpool02. Angenommen, Sie möchten die Steuerungsebene und wpool01 auf 1.32.200-gke.104 aktualisieren, wpool02 soll aber auf Version 1.31.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.32.200-gke.104
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.32.200-gke.104
  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.31.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 durchführen, bei dem die Knotenpools auf die Zielclusterversion aktualisiert werden. Bei Worker-Knotenpools, die von einem Cluster-Upgrade 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 keine gleichzeitigen Upgrades von Worker-Knotenpools durchführen möchten, wählen Sie jeweils einen Knotenpool für das Upgrade aus.

2. Fahren Sie mit dem Upgrade fort, wie unter Cluster-Upgrade 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.32.200-gke.104 aktualisiert, aber der Knotenpool wpool02 hat immer noch die alte Clusterversion 1.31.0. Arbeitslasten werden im aktualisierten Knotenpool wpool01 ordnungsgemäß ausgeführt. Sie möchten nun 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.32.200-gke.104
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.32.200-gke.104
  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:

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

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

Parallele Upgrades

Bei einem typischen Standard-Cluster-Upgrade 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.

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 gleichzeitig aktualisiert werden. Parallele Upgrades von Knoten werden in der NodePool-Spezifikation (spec.upgradeStrategy.parallelUpgrade) konfiguriert. Nur Knoten in einem Worker-Knotenpool können parallel aktualisiert werden. Knoten in Knotenpools der Steuerungsebene oder Load Balancer-Knotenpools können jeweils 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 jeweils 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 Feldern finden Sie in der Feldreferenz für die Clusterkonfiguration.

Die Knoten-Upgrade-Strategie 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 Cluster-Upgrades werden Knoten in Knotenpools der Steuerungsebene und Load Balancer-Knotenpools 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 nicht mehr als 50 % der Anzahl der Knoten im Knotenpool oder die feste Zahl 15 betragen, 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. 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 das Upgrade des Knotenpools

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

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 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 Upgrades mindestens 10 Knoten für Arbeitslasten verfügbar sein müssen.

2. Fügen Sie der Clusterspezifikation in der Clusterkonfigurationsdatei den Abschnitt nodePoolUpgradeStrategy hinzu.

   ---
   apiVersion: v1
   kind: Namespace
   metadata:
     name: cluster-user001
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: user001
     namespace: cluster-user001
   spec:
     type: user
     profile: default
     anthosBareMetalVersion: 1.32.200-gke.104
     ...
     nodePoolUpgradeStrategy:
       concurrentNodePools: 0
     ...
   

   In diesem Beispiel ist das Feld concurrentNodePools auf 0 festgelegt. 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. Aktualisieren Sie den Cluster 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 das parallele Upgrade und ihre Standardwerte aufgeführt:

Cluster-Upgrade starten

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

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 während eines pausierten Upgrades ein neuer Knoten hinzugefügt wird, werden keine Machine-Check-Jobs darauf ausgeführt, bis das Upgrade fortgesetzt und abgeschlossen wird.

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.

Pausieren und Fortsetzen von Upgrades aktivieren

Upgrade pausieren

Sie pausieren ein Clusterupgrade, indem Sie nodePoolUpgradeStrategy.pause im Clusterspec auf true setzen.

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 für den nächsten Schritt ein neues Terminalfenster.

2. So wenden Sie die Änderung an:

   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 einlegen möchten, 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, werden jedoch keine Upgrade-Fortschritte mehr in der Logdatei cluster-upgrade-TIMESTAMP im Clusterordner auf Ihrer Administrator-Workstation und in Cloud Logging protokolliert. Daher sollten Sie bmctl bei kurzen Pausen aktiviert lassen. Wenn Sie bmctl für längere Zeit ausführen, während das Upgrade pausiert ist, tritt irgendwann ein Zeitüberschreitungsfehler auf.

Pausiertes 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 wenden Sie die Änderung an:

   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 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 Statusinformationen zu anthosBareMetalVersion.

   • 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
   

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

   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.