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 GKE on Bare Metal-Version werden zusätzliche Features und Fehlerkorrekturen für den Cluster bereitgestellt. 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 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 Clusterupgrades von Anthos Clusters on Bare Metal.

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 Anthos Clusters on Bare Metal. Wählen Sie in diesem Fall 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 bzw. 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.

Die Versionierungsregeln für das ausgewählte 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:

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

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

3. 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.15.0 und hat zwei Worker-Knotenpools: wpool01 und wpool02. Angenommen, Sie möchten ein Upgrade der Steuerungsebene und von wpool01 auf 1.16.8 durchführen, aber wpool02 bei der Version 1.15.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.16.8
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.16.8
  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.15.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 ihrer Knotenpoolspezifikation auf die vorherige Clusterversion (vor dem Upgrade) festgelegt.

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

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

   Wenn mehrere Worker-Knotenpools für das Upgrade ausgewählt 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.

2. 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 Ihren Cluster auf Version 1.16.8 aktualisiert, aber der Knotenpool wpool02 befindet sich noch in der alten Clusterversion 1.15.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.16.8
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.16.8
  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

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 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. Ebenso gilt: Wenn concurrentNodes auf 10 gesetzt ist, darf minimumAvailableNodes 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:

1. 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 Feld minimumAvailableNodes ist auf 10 gesetzt. Das bedeutet, dass während des Upgrades mindestens 10 Knoten für Arbeitslasten verfügbar bleiben müssen.

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

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

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

3. 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. Wenn Sie concurrentNodes nicht angeben, beträgt minimumAvailableNodes standardmäßig 2/3 der Knotenpoolgröße. Wenn Sie concurrentNodes angeben, ist minimumAvailableNodes standardmäßig die Knotenpoolgröße abzüglich concurrentNodes.	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.