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 und wählen Sie 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:

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.

Upgrades überspringen

Ab Version 1.33 unterstützt Google Distributed Cloud das Überspringen von Upgrades für alle Clustertypen. So können Sie einen Cluster in einem einzigen Vorgang auf eine Zielversion 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.

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

Solange sich diese Funktion in der Vorschau befindet, empfehlen wir, keine Skip-Upgrades mit Produktionsclustern durchzuführen.

Voraussetzungen für das Upgrade überspringen

Das Verfahren zum Ausführen eines Skip-Upgrades unterscheidet sich nicht von dem für ein sequenzielles Upgrade. Es gibt jedoch einige zusätzliche Voraussetzungen:

  1. Prüfen Sie, ob sich der Cluster 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 mit einem Skip-Upgrade für einen Nutzercluster beginnen, müssen Ihre Cluster die folgenden Kriterien erfüllen:

      • Der zugehörige 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.33.0-gke.799
  ...

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

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 aus einem Registry-Spiegel abrufen, um Ihren Cluster zu aktualisieren, muss Ihr Registry-Spiegel 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 anhand 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. Übertragen Sie die Image-Pakete für die Zielversion und die Zwischenversion an den Registry-Spiegel, bevor Sie das Überspringen des Upgrades starten.

    Für das Hosting 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 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, 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.33 haben, können Sie Worker-Knotenpools in ausgewählten Versionen 1.33, 1.32 und 1.31 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-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. Diese Funktion ist für Cluster mit Version 1.30 standardmäßig aktiviert.

Knotenpools mit einer beliebigen Patchversion der Nebenversionen 1.28 und 1.29 können auf eine beliebige Patchversion von 1.30 aktualisiert werden, wenn die Knotenpoolversion mit der Clusterversion 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 auf GA umstellen, ist für Hybridcluster in der folgenden Situation weiterhin die Vorschau-Anmerkung 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

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 Ihrer 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 Vorabfunktion 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 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.32.0 und zwei Worker-Knotenpools: wpool01 und wpool02. Angenommen, Sie möchten die Steuerungsebene und wpool01 auf 1.33.100-gke.89 aktualisieren, wpool02 soll aber auf Version 1.32.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.33.100-gke.89
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.33.100-gke.89
  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.32.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.33.100-gke.89 aktualisiert, aber der Knotenpool wpool02 hat immer noch die alte Clusterversion 1.32.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.33.100-gke.89
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.33.100-gke.89
  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

Die Funktion zum Rollback von Knotenpools ist als Vorabversion für Cluster der Version 1.29 (Cluster mit Steuerungsebenenknoten 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. Setzen Sie anthosBareMetalVersion auf die vorherige (vor dem Upgrade) Clusterversion.

    ...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.32.500-gke.48
  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 eigenständiger 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 ausgeführt wird.

  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 Computer auf dem Knoten aus.
    • Führen Sie einen Machine-Init-Job auf dem Knoten aus, um ihn mit der Rollabck-Zielversion vor dem Upgrade neu zu installieren.
    • Entfernen Sie den Knoten aus dem Wartungsmodus.

    Am Ende eines erfolgreichen Rollbacks wird der Wert von nodePool.status.anthosBareMetalVersion in der NodePool-Ressource auf die Ziel-Rollback-Version festgelegt.

kubectl

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

  1. So führen Sie ein Rollback für einen Worker-Knotenpool durch:NodePool

    kubectl edit nodepool NODE_POOL_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

    Ersetzen Sie Folgendes:

    • NODE_POOL_NAME ist der Name des Knotenpools, für den 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ändiger 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.32.500-gke.48
  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 ausgeführt wird.

  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 Computer auf dem Knoten aus.
    • Führen Sie einen Machine-Init-Job auf dem Knoten aus, um ihn mit der Rollabck-Zielversion vor dem Upgrade neu zu installieren.
    • Entfernen Sie den Knoten aus dem Wartungsmodus.

    Am Ende eines erfolgreichen Rollbacks wird der Wert von nodePool.status.anthosBareMetalVersion in der NodePool-Ressource auf die Ziel-Rollback-Version festgelegt.

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 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 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 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-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 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 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, wird für jeden Worker-Knotenpool im Cluster ein paralleles 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 gesetzt. 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.33.100-gke.89
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

    In diesem Beispiel ist das Feld concurrentNodePools auf 0 gesetzt. Das bedeutet, dass alle Worker-Knotenpools während des Cluster-Upgrades gleichzeitig aktualisiert werden. Die Upgradestrategie für die Knoten in den Knotenpools wird in den NodePool-Spezifikationen definiert.

  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:

Feld Standardwert Bedeutung
nodePoolUpgradeStrategy.concurrentNodePools (Clusterspezifikation) 1 Aktualisieren Sie Worker-Knotenpools nacheinander.
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 Größe des Knotenpools 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.

Cluster-Upgrade starten

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

bmctl

Wenn Sie eine neue Version von bmctl herunterladen und installieren, können Sie Ihre Administrator-, Hybrid-, eigenständigen und Nutzer-Cluster aktualisieren, die mit einer früheren Version erstellt wurden. Bei einer bestimmten Version von bmctl können Cluster nur auf die gleiche Version aktualisiert werden.

  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.33.100-gke.89

  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.

    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.

    Wenn alle Clusterkomponenten erfolgreich aktualisiert wurden, werden im Rahmen des Cluster-Upgrades Systemdiagnosen für den Cluster durchgeführt. Mit diesem letzten Schritt wird überprüft, ob der Cluster betriebsbereit 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 führen Sie ein Upgrade für einen Cluster mit kubectl durch:

  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. Um Fehler zu beheben, müssen Sie den Cluster und die zugehörigen Logs untersuchen, 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 jedoch, die neueste Version von bmctl herunterzuladen. Sie benötigen bmctl, um andere Aufgaben wie Systemdiagnosen und Sicherungen auszuführen und so dafür zu sorgen, dass Ihr Cluster in gutem Zustand bleibt.

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

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:

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

Pausieren und Fortsetzen von Upgrades aktivieren

Google Distributed Cloud 1.33

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

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. So wenden Sie die Änderung 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: Geben Sie für Administrator-, Hybrid- oder eigenständige Cluster den Pfad zur kubeconfig-Datei des Clusters ein. Geben Sie für einen Nutzercluster den Pfad zur kubeconfig-Datei des Administratorclusters ein.

    Das Feld nodePoolUpgradeStrategy.pause kann geändert werden. Sie können sie jederzeit hinzufügen und aktualisieren.

Upgrade pausieren

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

  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 einen längeren Zeitraum ausführen, während das Upgrade pausiert ist, tritt schließlich 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.