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 Version von Google Distributed Cloud erhält er zusätzliche Funktionen und Fehlerkorrekturen. Außerdem wird dadurch sichergestellt, dass Ihr Cluster weiterhin unterstützt wird.
Sie können Administrator-, Hybrid-, eigenständige oder Nutzercluster mit dem Befehl bmctl upgrade cluster
oder mit kubectl
upgraden.
Weitere Informationen zum Upgradeprozess und zu den Versionsregeln finden Sie unter Lebenszyklus und Phasen von Clusterupgrades.
Upgrade planen
Dieser Abschnitt enthält Informationen und Links zu Informationen, die Sie vor dem Upgrade eines Clusters berücksichtigen sollten.
Best Practices
Informationen zur Vorbereitung auf ein Clusterupgrade finden Sie unter Best Practices für Upgrades von Google Distributed Cloud-Clustern.
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 verstehen.
Sie können prüfen, ob die Cluster für ein Upgrade bereit sind. Führen Sie dazu vor dem Upgrade die Preflight-Prüfung aus. Weitere Informationen finden Sie unter Preflight-Prüfungen auf 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 die Problemkategorie Upgrades und Updates aus.
Upgradeoptionen konfigurieren
Bevor Sie ein Clusterupgrade starten, können Sie die folgenden Upgradeoptionen konfigurieren, die die Funktionsweise des Upgrades steuern:
Selektive Upgrades für Worker-Knotenpools: Führen Sie für bestimmte Worker-Knotenpools ein Upgrade separat vom Rest des Clusters durch.
Parallele Upgrades: Konfigurieren Sie den Upgradeprozess, um Knotengruppen oder Knotenpools gleichzeitig zu aktualisieren.
Diese Optionen können das Risiko von Störungen kritischer Anwendungen und Dienste reduzieren und die Upgradezeit insgesamt erheblich verkürzen. Diese Optionen sind besonders nützlich für große Cluster mit zahlreichen Knoten und Knotenpools, auf denen wichtige Arbeitslasten ausgeführt werden. Weitere Informationen zur Funktionsweise und Verwendung dieser Optionen finden Sie in den folgenden Abschnitten.
Upgrades für selektive Worker-Knotenpools
Standardmäßig führt das Clusterupgrade ein Upgrade für jeden Knoten und Knotenpool im Cluster durch. Ein Clusterupgrade kann störend und zeitaufwendig sein, da es dazu führt, dass jeder Knoten per Drain beendet und alle zugehörigen Pods neu gestartet und neu geplant werden. In diesem Abschnitt wird beschrieben, wie Sie ausgewählte Worker-Knotenpools für ein Clusterupgrade ein- oder ausschließen können, um Unterbrechungen von Arbeitslasten zu minimieren. Dieses Feature gilt nur für Nutzer-, Hybrid- und eigenständige Cluster, da Administratorcluster keine Worker-Knotenpools zulassen.
Sie können in den folgenden Situationen selektive Knotenpoolupgrades verwenden:
So rufen Sie Sicherheitskorrekturen ab, ohne Arbeitslasten zu unterbrechen: Sie können ein Upgrade nur für die Knoten der Steuerungsebene (und die Load-Balancer-Knoten) durchführen, um Kubernetes-Sicherheitslückenkorrekturen ohne Beeinträchtigung Ihrer Worker-Knotenpools anzuwenden.
So überprüfen Sie den ordnungsgemäßen Betrieb einer aktualisierten Teilmenge von Worker-Knoten, bevor Sie alle Worker-Knoten aktualisieren: Sie können Ihre Worker-Knotenpools selektiv upgraden, um sicherzustellen, dass Arbeitslasten auf einem aktualisierten Knotenpool ordnungsgemäß ausgeführt werden, bevor Sie einen weiteren Knotenpool upgraden.
Verkürzung des Wartungsfensters: Das Upgrade eines großen Clusters kann zeitaufwendig sein und es ist schwierig, genau vorherzusagen, wann ein Upgrade abgeschlossen wird. Die Zeit für das Clusterupgrade ist proportional zur Anzahl der Knoten, die aktualisiert werden. Wenn Sie die Anzahl der Knoten, für die ein Upgrade durchgeführt wird, durch den Ausschluss von Knotenpools reduzieren, verkürzt sich die Upgradezeit. Sie führen mehrmals ein Upgrade durch, aber die kleineren, besser vorhersehbaren Wartungsfenster können bei der Planung helfen.
Zweifache Versionsabweichung des Knotenpools
Bei Clustern der Version 1.28 und höher kann die Version eines Worker-Knotenpools bis zu zwei Nebenversionen älter als die Version des Clusters (Steuerungsebene) sein. Diese Unterstützung der n-2-Versionsabweichung für Worker-Knotenpools bietet Ihnen mehr Flexibilität bei der Planung von Flottenupgrades. Sie müssen beispielsweise nicht alle Worker-Knotenpools der Version 1.16 auf Version 1.28 upgraden, bevor Sie Ihren Cluster auf Version 1.29 upgraden können.
Google Distributed Cloud
In Release 1.29 ist die Unterstützung der n-2-Versionsabweichung für Worker-Knotenpools für alle Clustertypen allgemein verfügbar. Dieses Feature ist für Cluster mit Version 1.29 standardmäßig aktiviert.
Während wir diese Funktion von der öffentlichen Vorschau auf die allgemeine Verfügbarkeit umstellen, benötigen Hybridcluster die Vorschauanmerkung auch in der folgenden Situation. Wenn Sie einen Hybridcluster der Version 1.28.x und einen 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 upgraden:
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 ...
Google Distributed Cloud
Die Unterstützung der n-2-Versionsabweichung für Worker-Knotenpools ist in der Vorabversion 1.28 verfügbar. Fügen Sie der Clusterkonfigurationsdatei die Annotation preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
hinzu, um diese Vorschaufunktion zu aktivieren:
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 Vorschaufunktion nicht aktivieren, beträgt die maximale Versionsverzerrung zwischen einem Worker-Knotenpool und dem Cluster eine Nebenversion.
Weitere Informationen zu den Versionsregeln für das selektive Upgrade von Worker-Knotenpools finden Sie unter Regeln für die Versionsverwaltung für Knotenpools unter Lebenszyklus und Phasen von Clusterupgrades.
Cluster-Steuerungsebene und ausgewählte Knotenpools upgraden
So aktualisieren Sie Worker-Knotenpools im ersten Clusterupgrade selektiv:
Nehmen Sie für die Worker-Knotenpools, die Sie in das Clusterupgrade aufnehmen möchten, eine der folgenden Änderungen an der Knotenpoolspezifikation vor:
- Legen Sie
anthosBareMetalVersion
in der Knotenpoolspezifikation auf die Upgradeversion des Clusterziels fest. - Lassen Sie das Feld
anthosBareMetalVersion
aus der Knotenpoolspezifikation aus oder legen Sie dafür den leeren String fest. Standardmäßig sind Worker-Knotenpools in Clusterupgrades enthalten.
- Legen Sie
Legen Sie für die Worker-Knotenpools, die Sie vom Upgrade ausschließen möchten,
anthosBareMetalVersion
auf die aktuelle Version des Clusters fest (vor dem Upgrade):Fahren Sie mit dem Upgrade wie unter Clusterupgrade starten beschrieben fort.
Beim Clusterupgrade wird ein Upgrade der folgenden Knoten durchgeführt:
- 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 upgraden, da dieser immer im ersten Clusterupgrade enthalten ist. - Worker-Knotenpools, die Sie nicht vom Upgrade ausgeschlossen haben.
Angenommen, Ihr Cluster befindet sich in der Version 1.28.0 und hat zwei Worker-Knotenpools: wpool01
und wpool02
. Angenommen, Sie möchten ein Upgrade der Steuerungsebene und von wpool01
auf 1.29.100-gke.251 durchführen, wpool02
jedoch bei Version 1.28.0 bleiben.
Der folgende Auszug 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.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool01
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: 1.29.100-gke.251
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.28.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 upgraden
Wenn Sie Knotenpools aus einem Clusterupgrade ausgeschlossen haben, können Sie ein Clusterupgrade ausführen, das sie auf die Zielclusterversion hochlädt. Bei Worker-Knotenpools, die von einem Clusterupgrade ausgeschlossen wurden, ist das Feld anthosBareMetalVersion
in der Spezifikation NodePool
auf die vorherige Clusterversion (vor dem Upgrade) festgelegt.
So aktualisieren Sie Worker-Knotenpools auf die aktuelle, aktualisierte Clusterversion:
Bearbeiten Sie die
NodePool
-Spezifikationen in der Clusterkonfigurationsdatei für die Worker-Knotenpools, die Sie auf die aktuelle Clusterversion aktualisieren möchten. Legen SieanthosBareMetalVersion
auf die aktuelle Clusterversion (nach dem Upgrade) fest.Wenn mehrere Worker-Knotenpools für das Upgrade ausgewählt werden, bestimmt der Wert von
spec.nodePoolUpgradeStrategy.concurrentNodePools
in der Clusterspezifikation, wie viele Knotenpools gegebenenfalls parallel aktualisiert werden. Wenn Sie Worker-Knotenpools nicht gleichzeitig aktualisieren möchten, wählen Sie jeweils nur einen Knotenpool für das Upgrade aus.Fahren Sie mit dem Upgrade wie unter Clusterupgrade starten beschrieben fort.
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 für Ihren Cluster ein Upgrade auf Version 1.29.100-gke.251 durchgeführt, der Knotenpool wpool02
befindet sich jedoch noch in der alten Clusterversion 1.28.0 vor dem Upgrade. Da Arbeitslasten auf dem aktualisierten Knotenpool wpool01
ordnungsgemäß ausgeführt werden, möchten Sie wpool02
jetzt auch auf die aktuelle Clusterversion hochfahren. Wenn Sie ein Upgrade von wpool02
durchführen möchten, können Sie das Feld anthosBareMetalVersion
entfernen oder seinen Wert auf den leeren String festlegen.
Der folgende Auszug 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.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool01
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: 1.29.100-gke.251
nodes:
- address: 10.200.0.1
- address: 10.200.0.2
- address: 10.200.0.3
...
- address: 10.200.0.8
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool02
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: ""
nodes:
- address: 10.200.1.1
- address: 10.200.1.2
- address: 10.200.1.3
...
- address: 10.200.1.12
Rollback für Knotenpool-Upgrade durchführen
Es gibt viele Abhängigkeiten, z. B. die Kompatibilität mit Kubelet oder Plug-ins, die sich auf die Leistung Ihrer Arbeitslasten auswirken können. Falls nach dem Upgrade eines Worker-Knotenpools ein Problem auftritt, können Sie ein Rollback auf seine vorherige Version durchführen.
Die Rollback-Funktion für Knotenpools ist in der Vorabversion für Cluster der Version 1.29 (Cluster mit Knoten der Steuerungsebene in Version 1.29) verfügbar. Solange sich dieses Feature in der Vorabversion befindet, müssen Sie der Ressource Cluster
die Annotation preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable
hinzufügen, um das Feature zu aktivieren.
Führen Sie die folgenden Schritte aus, um das Upgrade eines Knotenpools rückgängig zu machen:
bmctl
Wenn Sie bmctl
verwenden, um das Rollback eines Knotenpoolupgrades rückgängig zu machen, bearbeiten Sie die Clusterkonfigurationsdatei und wenden Ihre Änderungen mit dem Befehl bmctl update
an:
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 SieanthosBareMetalVersion
auf 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.28.500-gke.120 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 werden, bestimmt der Wert von
spec.nodePoolUpgradeStrategy.concurrentNodePools
in der Clusterspezifikation, wie viele Knotenpools parallel zurückgesetzt werden. Wenn Sie nicht gleichzeitig ein Rollback von Worker-Knotenpools durchführen möchten, wählen Sie für das Rollback jeweils nur einen Knotenpool aus oder aktualisieren Sie die Einstellungen fürnodePoolUpgradeStrategy
. Ebenso bestimmt der Wert vonspec.upgradeStrategy.parallelUpgrade.concurrentNodes
in derNodePool
-Spezifikation, wie viele Knoten parallel zurückgesetzt werden.Verwenden Sie
bmctl update
, um dieNodePool
-Spezifikationsänderungen anzuwenden:bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
Ersetzen Sie Folgendes:
CLUSTER_NAME
: der Name des Clusters, den Sie aktualisieren möchten.ADMIN_KUBECONFIG
: Pfad der kubeconfig-Datei des verwaltenden Clusters (Administrator, Hybrid oder eigenständig).
Das Rollback wird automatisch gestartet.
Während des Rollbacks führt Google Distributed Cloud für jeden Knoten die folgenden Aktivitäten aus:
- Versetzen Sie den Knoten in den Wartungsmodus.
- Führen Sie einen Zurücksetzensjob auf dem Knoten aus, um ihn in einen bereinigten Zustand zu bringen.
- Führen Sie Preflight-Prüfungen der Maschinen auf dem Knoten aus.
- Führen Sie einen Machine-init-Job auf dem Knoten aus, um ihn bei der Ziel-Rollback-Version (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 RessourceNodePool
auf die Ziel-Rollback-Version gesetzt.
kubectl
Sie können ein Upgrade eines Knotenpools rückgängig machen, indem Sie mit kubectl
die Ressource NodePool
direkt bearbeiten:
Öffnen Sie die Ressource
NodePool
zur Bearbeitung, um ein Rollback für einen Worker-Knotenpool durchzuführen: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
: Pfad der kubeconfig-Datei des verwaltenden Clusters (Administrator, Hybrid oder eigenständig).
Ä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.28.500-gke.120 nodes: - address: 10.200.0.1 - address: 10.200.0.2 - address: 10.200.0.3 ...
Speichern und schließen Sie die Ressource
NodePool
in Ihrem Editor.Das Rollback wird automatisch gestartet.
Während des Rollbacks führt Google Distributed Cloud für jeden Knoten die folgenden Aktivitäten aus:
- Versetzen Sie den Knoten in den Wartungsmodus.
- Führen Sie einen Zurücksetzensjob auf dem Knoten aus, um ihn in einen bereinigten Zustand zu bringen.
- Führen Sie Preflight-Prüfungen der Maschinen auf dem Knoten aus.
- Führen Sie einen Machine-init-Job auf dem Knoten aus, um ihn bei der Ziel-Rollback-Version (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 RessourceNodePool
auf die Ziel-Rollback-Version gesetzt.
Parallele Upgrades
Bei einem typischen Standardclusterupgrade wird jeder Clusterknoten nacheinander und nacheinander aktualisiert. In diesem Abschnitt erfahren Sie, wie Sie Ihre Cluster- und Worker-Knotenpools so konfigurieren, dass mehrere Knoten beim Upgrade des Clusters parallel aktualisiert werden. Das parallele Upgrade von Knoten beschleunigt Cluster-Upgrades erheblich, insbesondere bei Clustern mit Hunderten von Knoten.
Es gibt zwei parallele Upgradestrategien, mit denen Sie das 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 Knotenpoolspezifikation (
spec.upgradeStrategy.parallelUpgrade
) konfiguriert und nur Knoten in einem Worker-Knotenpool können parallel aktualisiert werden. Knoten in Steuerungsebenen- oder Load-Balancer-Knotenpools können jeweils nur einzeln aktualisiert werden. Weitere Informationen finden Sie unter Knotenupgrades.Gleichzeitiges Knotenpoolupgrade: Sie können Ihren Cluster so konfigurieren, dass mehrere Knotenpools gleichzeitig aktualisiert werden. Nur Worker-Knotenpools können parallel aktualisiert werden. Knotenpools und Load-Balancer-Knotenpools können nur einzeln aktualisiert werden.
Strategie für Knotenupgrades
Sie können Worker-Knotenpools so konfigurieren, dass mehrere Knoten gleichzeitig aktualisiert werden (concurrentNodes
). Außerdem haben Sie die Möglichkeit, einen Mindestgrenzwert für die Anzahl der Knoten festzulegen, die während des Upgrades ausgeführt werden können (minimumAvailableNodes
). Diese Konfiguration wird in der Knotenpoolspezifikation vorgenommen. Weitere Informationen zu diesen Feldern finden Sie in der Referenz zum Clusterkonfigurationsfeld.
Die Strategie für Knotenupgrades gilt nur für Worker-Knotenpools. Sie können keine Knotenupgrade-Strategie für Steuerungsebenen- oder Load-Balancer-Knotenpools angeben. Während eines Clusterupgrades werden Knoten in der Steuerungsebene und in Load-Balancer-Knotenpools nacheinander und nacheinander aktualisiert. Knotenpools der Steuerungsebene und Knotenpools des Load-Balancers werden in der Clusterspezifikation angegeben (controlPlane.nodePoolSpec.nodes
und loadBalancer.nodePoolSpec.nodes
).
Beachten Sie die folgenden Einschränkungen, wenn Sie parallele Upgrades für Knoten konfigurieren:
Der Wert von
concurrentNodes
darf entweder 50 % der Anzahl von Knoten im Knotenpool oder die feste Anzahl 15 nicht überschreiten, je nachdem, welcher Wert kleiner ist. Wenn Ihr Knotenpool beispielsweise 20 Knoten hat, können Sie keinen Wert über 10 angeben. Wenn Ihr Knotenpool 100 Knoten hat, können Sie maximal 15 angeben.Wenn Sie
concurrentNodes
zusammen mitminimumAvailableNodes
verwenden, dürfen die kombinierten Werte die Gesamtzahl der Knoten im Knotenpool nicht überschreiten. Wenn Ihr Knotenpool beispielsweise 20 Knoten hat undminimumAvailableNodes
auf 18 festgelegt ist, darfconcurrentNodes
nicht größer als 2 sein. Ebenso gilt: WennconcurrentNodes
auf 10 gesetzt ist, darfminimumAvailableNodes
nicht größer als 10 sein.
Das folgende Beispiel zeigt den Worker-Knotenpool np1
mit 10 Knoten. Bei einem Upgrade werden die Knoten bis zu fünfmal aktualisiert, wobei mindestens vier Knoten verfügbar bleiben müssen, 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
Upgradestrategie für 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 und nacheinander aktualisiert. Wenn Sie concurrentNodePools
auf 0
festlegen, wird jeder Worker-Knotenpool im Cluster parallel aktualisiert.
Knotenpools der Steuerungsebene und des Load-Balancings sind von dieser Einstellung nicht betroffen.
Diese Knotenpools werden immer nacheinander und nacheinander aktualisiert. Knotenpools der Steuerungsebene und Knotenpools des Load-Balancers sind in der Clusterspezifikation angegeben (controlPlane.nodePoolSpec.nodes
und loadBalancer.nodePoolSpec.nodes
).
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 aus:
Fügen Sie der Knotenpoolspezifikation einen Abschnitt
upgradeStrategy
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
. Dies bedeutet, dass 5 Knoten parallel aktualisiert werden. Das FeldminimumAvailableNodes
ist auf10
gesetzt. Das bedeutet, dass während des Upgrades mindestens 10 Knoten für Arbeitslasten verfügbar bleiben müssen.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.29.100-gke.251 ... nodePoolUpgradeStrategy: concurrentNodePools: 0 ...
In diesem Beispiel ist das Feld
concurrentNodePools
auf0
gesetzt. Das bedeutet, dass alle Worker-Knotenpools während des Clusterupgrades gleichzeitig aktualisiert werden. Die Upgradestrategie für die Knoten in den Knotenpools ist in den NodePool-Spezifikationen definiert.Führen Sie ein Upgrade des Clusters durch, wie im vorherigen Abschnitt Administrator-, eigenständige, Hybrid- oder Nutzercluster upgraden 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 das Feature 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 sequenzielles Upgrade der Worker-Knotenpools durch. |
upgradeStrategy.parallelUpgrade.concurrentNodes (NodePool-Spezifikation) |
1 |
Führen Sie ein sequenzielles Upgrade der Knoten nacheinander durch. |
upgradeStrategy.parallelUpgrade.minimumAvailableNodes (NodePool-Spezifikation) |
Der Standardwert für minimumAvailableNodes hängt vom Wert von concurrentNodes ab.
|
Das Upgrade wird unterbrochen, sobald minimumAvailableNodes erreicht ist, und wird erst fortgesetzt, wenn die Anzahl der verfügbaren Knoten größer als minimumAvailableNodes ist. |
Clusterupgrade starten
In diesem Abschnitt finden Sie eine Anleitung zum Upgraden von Clustern.
bmctl
Wenn Sie eine neue Version von bmctl
herunterladen und installieren, können Sie Ihre Administrator-, Hybrid-, eigenständigen und Nutzer-Cluster aktualisieren, die mit einer früheren Version erstellt wurden.
Bei einer bestimmten Version von bmctl
können Cluster nur auf die gleiche Version aktualisiert werden.
Laden Sie die neueste
bmctl
wie unter Google Distributed Cloud-Downloads beschrieben herunter.Aktualisieren Sie
anthosBareMetalVersion
in der Clusterkonfigurationsdatei auf die Upgrade-Zielversion.Die Upgrade-Zielversion muss mit der Version der heruntergeladenen Datei
bmctl
übereinstimmen. Das folgende Snippet der Clusterkonfigurationsdatei zeigt das FeldanthosBareMetalVersion
, 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.29.100-gke.251
Verwenden Sie den Befehl
bmctl upgrade cluster
, um das Upgrade abzuschließen:bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
Ersetzen Sie Folgendes:
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 Installation oder beim Upgrade von Clustern beheben.
Wenn alle Clusterkomponenten erfolgreich aktualisiert wurden, führt das Clusterupgrade eine Cluster-Systemdiagnose aus. Mit diesem letzten Schritt wird überprüft, ob der Cluster in einem guten Betriebszustand ist. Wenn der Cluster nicht alle Systemdiagnosen besteht, werden sie weiter ausgeführt, bis sie bestanden sind. Wenn alle Systemdiagnosen bestanden sind, wird das Upgrade erfolgreich abgeschlossen.
Weitere Informationen zur Abfolge von Ereignissen für Clusterupgrades finden Sie unter Lebenszyklus und Phasen von Clusterupgrades.
kubectl
Führen Sie die folgenden Schritte aus, um einen Cluster mit kubectl
zu aktualisieren:
Bearbeiten Sie die Clusterkonfigurationsdatei, um
anthosBareMetalVersion
auf die Upgrade-Zielversion festzulegen.Führen Sie den folgenden Befehl aus, um das Upgrade zu initiieren:
kubectl apply -f CLUSTER_CONFIG_PATH
Ersetzen Sie
CLUSTER_CONFIG_PATH
durch den Pfad der bearbeiteten Clusterkonfigurationsdatei.Wie beim Upgradeprozess mit
bmctl
werden Preflight-Prüfungen im Rahmen des Clusterupgrades ausgeführt, um den Clusterstatus und Knotenzustand zu validieren. Wenn die Preflight-Prüfungen fehlschlagen, wird das Clusterupgrade angehalten. Um Fehler zu beheben, prüfen Sie den Cluster und die zugehörigen Logs, da kein Bootstrap-Cluster erstellt wird. Weitere Informationen finden Sie unter Probleme bei der Installation oder beim Upgrade von Clustern beheben.
Sie benötigen nicht die neueste Version von bmctl
, um ein Upgrade für Cluter mit kubectl
durchzuführen. Wir empfehlen jedoch, die aktuelle Version von bmctl
herunterzuladen. Sie benötigen bmctl
, um andere Aufgaben wie Systemdiagnosen und Sicherungen auszuführen und dafür zu sorgen, dass Ihr Cluster in einem einwandfreien Zustand bleibt.
Upgrades pausieren und fortsetzen
Mit dem Feature zum Pausieren und Fortsetzen von Upgrades können Sie ein Clusterupgrade anhalten, bevor es abgeschlossen ist. Wenn ein Clusterupgrade pausiert wird, werden keine neuen Upgrades von Worker-Knoten mehr ausgelöst, bis das Upgrade fortgesetzt wird.
Dieses Feature ist in der Vorabversion für Cluster mit allen Knoten der Steuerungsebene ab Nebenversion 1.28 verfügbar. Die Funktion ist allgemein verfügbar für Cluster mit allen Knoten der Steuerungsebene ab Nebenversion 1.29.
Wenn Sie ein Upgrade pausieren möchten, kann das folgende Gründe haben:
Sie haben während des Upgrades ein Problem mit Clusterarbeitslasten festgestellt und möchten das Upgrade anhalten, um das Problem zu untersuchen
Die Wartungsfenster sind kurz, daher möchten Sie das Upgrade zwischen den Fenstern anhalten.
Während ein Clusterupgrade pausiert ist, werden die folgenden Vorgänge unterstützt:
- Knoten hinzufügen oder entfernen
- Knotenpools hinzufügen oder entfernen
- Reichweite des Dienstnetzwerks erhöhen
- Cluster aus einer Sicherung wiederherstellen
Wenn ein neuer Knoten hinzugefügt wird, während ein Upgrade pausiert ist, werden darauf erst dann Maschinenprüfungsjobs ausgeführt, wenn das Upgrade fortgesetzt und abgeschlossen ist.
Während das Clusterupgrade pausiert ist, werden die folgenden Clustervorgänge nicht unterstützt:
Sie können kein neues Clusterupgrade initiieren, während ein aktives Clusterupgrade pausiert ist.
Pausieren und Fortsetzen von Upgrades aktivieren
Google Distributed Cloud 1.29
Das Pausieren und Fortsetzen von Upgrades ist für Cluster mit allen Knoten der Steuerungsebene ab Nebenversion 1.29 standardmäßig aktiviert.
Google Distributed Cloud 1.28
Während die Upgrade-Funktion zum Pausieren und Fortsetzen in der Vorabversion verfügbar ist, können Sie sie mit einer Annotation in der Clusterressource aktivieren.
So aktivieren Sie das Pausieren und Fortsetzen des Upgrades:
Fügen Sie der Clusterkonfigurationsdatei die Annotation
preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
hinzu:apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: baremetal-demo namespace: cluster-baremetal-demo annotations: preview.baremetal.cluster.gke.io/upgrade-pause-and-resume spec: ...
Aktualisieren Sie den Cluster, um die Änderung anzuwenden:
bmctl update CLUSTER_NAME
Das Feld
nodePoolUpgradeStrategy.pause
ist änderbar. Sie können sie jederzeit hinzufügen oder aktualisieren.
Upgrade pausieren
Zum Pausieren eines Clusterupgrades setzen Sie nodePoolUpgradeStrategy.pause
in der Clusterspezifikation auf true
.
So pausieren Sie ein aktives Clusterupgrade:
Fügen Sie der Clusterkonfigurationsdatei
nodePoolUpgradeStrategy.pause
hinzu und legen Sie sie auftrue
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
initiiert haben, benötigen Sie ein neues Terminalfenster, um den nächsten Schritt ausführen zu können.Aktualisieren Sie den Cluster, um die Änderung anzuwenden:
bmctl update CLUSTER_NAME
Der Upgradevorgang wurde pausiert. Es werden keine neuen Knotenupgrades ausgelöst.
Wenn Sie das Upgrade mit
bmctl
initiiert haben und eine längere Pause planen, drücken Sie Strg + C, umbmctl
zu beenden. Andernfalls lassen Siebmctl
weiter ausgeführt.Die
bmctl
-Befehlszeile erkennt keine Änderungen am Pausenstatus des Upgrades, sodass er nicht automatisch beendet wird. Wenn Siebmctl
jedoch beenden, wird der Upgradefortschritt nicht mehr in der Logdateicluster-upgrade-TIMESTAMP
im Clusterordner auf Ihrer Administratorworkstation und in Cloud Logging protokolliert. Daher sollten Siebmctl
für kurze Pausen weiter ausführen. Wenn Siebmctl
für einen längeren Zeitraum ausführen, während das Upgrade pausiert ist, kommt es zu einer Zeitüberschreitung.
Pausiertes Upgrade fortsetzen
Wenn Sie ein pausiertes Clusterupgrade fortsetzen möchten, setzen Sie entweder nodePoolUpgradeStrategy.pause
in der Clusterspezifikation auf false
oder entfernen Sie nodePoolUpgradeStrategy.pause
aus der Spezifikation.
So setzen Sie ein pausiertes Clusterupgrade fort:
Legen Sie für
nodePoolUpgradeStrategy.pause
die Clusterkonfigurationsdatei und dannfalse
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 auffalse
gesetzt ist.Aktualisieren Sie den Cluster, um die Änderung anzuwenden:
bmctl update CLUSTER_NAME
Der Upgradevorgang wird an der Stelle fortgesetzt, an der er unterbrochen wurde.
Wenn Sie den Status des Upgrades prüfen möchten, rufen Sie zuerst eine Liste der Ressourcen ab, in deren
status
anthosBareMetalVersion
enthalten ist:kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces
Ersetzen Sie Folgendes:
RESOURCE
: Der Name der Ressource, die Sie abrufen möchten.Cluster
-,NodePool
- undBareMetalMachine
-Ressourcen enthalten alleanthosBareMetalVersion
-Statusinformationen.ADMIN_KUBECONFIG
: der Pfad der kubeconfig-Datei des Administratorclusters
Im folgenden Beispiel wird das Format der Antwort für benutzerdefinierte
BareMetalMachine
-Ressourcen gezeigt. JederBareMetalMachine
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
Rufen Sie Details zu einzelnen Ressourcen ab, um die
status.anthosBareMetalVersion
(aktuelle Version der Ressource) zu prüfen: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-Adresse192.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.