Version 1.14. This version is no longer supported. For information about how to upgrade to version 1.15, see Upgrading Anthos on bare metal in the 1.15 documentation. For more information about supported and unsupported versions, see the Version history page in the latest documentation.

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 das Upgrade eines Clusters auf die neueste GKE on Bare Metal-Version werden dem Cluster zusätzliche Features und Fehlerkorrekturen hinzugefügt. Außerdem wird dadurch sichergestellt, dass Ihr Cluster weiterhin unterstützt wird. Mit dem Befehl bmctl upgrade cluster können Sie Administrator-, Hybrid-, eigenständige oder Nutzercluster upgraden.

Überlegungen zum Upgrade

In folgenden Abschnitten werden Regeln und Best Practices beschrieben, die vor dem Upgrade eines Clusters zu berücksichtigen sind.

Vorschaufeatures

Die Vorschaufunktionen können sich ändern und werden nur zu Test- und Bewertungszwecken bereitgestellt. Verwenden Sie keine Vorschau-Features auf Ihren Produktionsclustern. Es wird nicht garantiert, dass Cluster, die Vorschaufunktionen verwenden, aktualisiert werden können. In einigen Fällen werden Upgrades für Cluster, die Vorschaufunktionen verwenden, explizit blockiert.

Informationen zu funktionsgefährdenden Änderungen im Zusammenhang mit dem Upgraden finden Sie in den Versionshinweisen.

SELinux

Wenn Sie SELinux zum Schutz Ihrer Container aktivieren möchten, müssen Sie darauf achten, dass SELinux auf allen Hostcomputern im Enforced-Modus aktiviert ist. Ab GKE on Bare Metal-Version 1.9.0 können Sie SELinux vor oder nach der Clustererstellung oder Clusterupgrades aktivieren oder deaktivieren. SELinux ist unter Red Hat Enterprise Linux (RHEL) und CentOS standardmäßig aktiviert. Wenn SELinux auf Ihren Hostcomputern deaktiviert ist oder Sie sich nicht sicher sind, finden Sie unter Container mit SELinux sichern Informationen zur Aktivierung.

GKE on Bare Metal unterstützt SELinux nur in RHEL- und CentOS-Systemen.

Preflight-Prüfungen upgraden

Preflight-Prüfungen werden als Teil des Clusterupgrades ausgeführt, um den Clusterstatus und den Knotenzustand zu validieren. Das Clusterupgrade wird nicht fortgesetzt, wenn die Preflight-Prüfungen fehlschlagen. Weitere Informationen zu Preflight-Prüfungen finden Sie unter Preflight-Prüfungen.

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

Anzahl von Knoten

Wenn Ihr Cluster mehr als 51 Knoten hat, ist der Standardupgradevorgang, bei dem ein Bootstrap-Cluster verwendet wird, anfällig für Fehler. Die Fehler sind auf die begrenzte Anzahl von Pod-IP-Adressen zurückzuführen, die dem Bootstrap-Cluster zugewiesen sind. Der für Pods im Bootstrap-Cluster verfügbare Standard-IP-Adressbereich verwendet die Maske /24 in CIDR-Blöcken.

In dieser Situation gibt es zwei Behelfslösungen:

Empfohlen: Verwenden Sie das Flag --use-bootstrap=false mit dem Befehl bmctl upgrade cluster, um ein direktes Upgrade auszuführen. Dieses Flag sorgt dafür, dass das Upgrade den Bootstrap-Cluster und die zugehörige Einschränkung der Pod-Adresse vollständig umgeht. Beachten Sie, dass für Cluster der Version 1.13.0 ein bekanntes Problem bei direkten Upgrades besteht. Wenn Ihr Cluster die Version 1.13.0 hat, finden Sie unter dem bekannten Problem eine Umgehungslösung und weitere Informationen.
Verwenden Sie das Flag --bootstrap-cluster-pod-cidr mit dem Befehl bmctl upgrade cluster, um die Anzahl der dem Bootstrap-Cluster zugewiesenen Pod-IP-Adressen zu erhöhen. Wenn Sie beispielsweise --bootstrap-cluster-pod-cidr=192.168.122.0/23 angeben, können Pods, die für den Upgradevorgang ausgeführt werden, IP-Adressen von 192.168.122.0/23 (512 Adressen) anstelle des standardmäßigen CIDR 192.168.122.0/24 (256 Adressen) verwenden. Diese hinzugefügten Adressen sollten die Blockierung von Upgrades für Cluster mit bis zu 52 Knoten aufheben.

Die Anzahl der Pods, die während eines Upgrades gleichzeitig ausgeführt werden, kann maximal fünfmal so groß wie die Anzahl der Knoten sein. Damit das Upgrade erfolgreich ist, geben Sie einen CIDR-Block mit einer Anzahl von IP-Adressen an, die fünfmal so groß wie die Anzahl der Knoten ist. Für dieses Flag sind interne IP-Adressen erforderlich.
Wenn Sie keine der vorherigen Optionen verwenden möchten, können Sie die Validierung mit dem Flag --skip-bootstrap-cidr-check umgehen. Wenn dieses Argument übergeben wird, kann das Upgrade jedoch aufgrund unzureichender IP-Adressen, die im Pod-CIDR für den Bootstrap-Cluster verfügbar sind, fehlschlagen.

Direkte Upgrades für selbstverwaltete Cluster

Ab GKE on Bare Metal-Version 1.13.1 können Sie direkte Upgrades für Administrator-, Hybrid- und eigenständige Cluster ausführen. Bei einem direkten Upgrade ist kein Bootstrap-Cluster erforderlich, was den Prozess vereinfacht und den Ressourcenbedarf für ein Upgrade reduziert. Bevor Sie ein direktes Upgrade für Ihren selbstverwalteten Cluster ausführen können, muss dieser in der Version 1.13.0 oder höher sein.

Für ein direktes Upgrade können Sie entweder bmctl oder kubectl verwenden:

`bmctl`

Der Upgradeprozess ist mit Ausnahme des Befehls bmctl upgrade cluster identisch mit dem Standard-Upgradeprozess.

Verwenden Sie das Flag --use-bootstrap=false mit dem Upgrade-Befehl, um das direkte Upgrade zu starten:
```
bmctl upgrade cluster -c CLUSTER_NAME --use-bootstrap=false \
    --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME ist der Name des Clusters, der aktualisiert werden soll.
- ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters.

Wie beim Standardupgradeprozess 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.

`kubectl`

Führen Sie die folgenden Schritte aus, um einen selbstverwalteten 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 zur Clusterkonfigurationsdatei.

Wie beim Standard-Upgradeprozess 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. Prüfen Sie den Cluster und die zugehörigen Logs, um Fehler zu beheben, da kein Bootstrap-Cluster erstellt wird.

Pod-Dichte

GKE on Bare Metal unterstützt die Konfiguration von maximal 250 Pods pro Knoten mit nodeConfig.PodDensity.MaxPodsPerNode. Sie können die Pod-Dichte nur während der Clustererstellung konfigurieren. Sie können die Einstellungen für die Pod-Dichte nicht für vorhandene Cluster aktualisieren.

Bekannte Probleme

Informationen zu potenziellen Problemen im Zusammenhang mit Clusterupgrades finden Sie auf der Seite „Bekannte Probleme” unter Anthos Clusters on Bare Metal aktualisieren.

Administrator-, eigenständige, Hybrid- oder Nutzercluster aktualisieren

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 zuerst die neueste Version von bmctl herunter. Ändern Sie dann die entsprechenden Cluster-Konfigurationsdateien und geben Sie den Befehl bmctl upgrade cluster aus, um das Upgrade abzuschließen.

Laden Sie die neueste bmctl aus dem Cloud Storage-Bucket herunter und verwenden Sie chmod, um allen Nutzern bmctl-Berechtigungen zu erteilen:
```
gsutil cp gs://anthos-baremetal-release/bmctl/1.14.11/linux-amd64/bmctl bmctl
chmod a+x bmctl
```

Ändern Sie die Clusterkonfigurationsdatei, um die Version des GKE on Bare Metal-Clusters von 1.13.2 in 1.14.11 zu ändern. Das folgende Beispiel zeigt die Konfiguration eines Administratorclusters:

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  # Cluster type. This can be:
  #   1) admin:  to create an admin cluster. This can later be used to create user clusters.
  #   2) user:   to create a user cluster. Requires an existing admin cluster.
  #   3) hybrid: to create a hybrid cluster that runs admin cluster components and user workloads.
  #   4) standalone: to create a cluster that manages itself, runs user workloads, but does not manage other clusters.
  type: admin
  # Anthos cluster version.
  # Change the following line from 1.13.2 to 1.14.11, shown below
  anthosBareMetalVersion: 1.14.11

Beim Upgrade von Clustern auf 1.14.11 müssen Sie die Cluster bei Connect in Ihrer Projektflotte registrieren, falls sie noch nicht registriert sind.
1. Erstellen Sie manuell Dienstkonten und rufen Sie die JSON-Schlüsseldateien ab, wie unter Dienstkonten zur Verwendung mit Connect konfigurieren auf der Seite "Google-Dienste und -Dienstkonten aktivieren" beschrieben.
2. Verweisen Sie auf die heruntergeladenen JSON-Schlüssel in den zugehörigen Feldern gkeConnectAgentServiceAccountKeyPath und gkeConnectRegisterServiceAccountKeyPath der Clusterkonfigurationsdatei.
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.
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.

Parallele Upgrades von Knoten

Bei einem typischen Clusterupgrade wird jeder Clusterknoten nacheinander aktualisiert. In diesem Abschnitt wird beschrieben, wie Sie Ihren Cluster so konfigurieren, dass mehrere Knoten beim Upgrade des Clusters parallel aktualisiert werden.

Parallele Knotenupgrades beschleunigen Clusterupgrades, insbesondere bei Clustern mit Hunderten von Knoten. Parallele Upgrades von Knoten werden auf Knotenpoolbasis konfiguriert. Nur Knoten in einem Worker-Knotenpool können parallel aktualisiert werden. Knoten in Knotenpools der Steuerungsebene oder Load-Balancer können nur einzeln aktualisiert werden.

Parallele Upgrades von Worker-Knoten sind ein Feature in der Vorabversion. Verwenden Sie dieses Feature daher nicht in Ihren Produktionsclustern.

Paralleles Upgrade durchführen

So führen Sie ein paralleles Upgrade von Knoten in einem Worker-Knotenpool durch:

Fügen Sie der Clusterkonfigurationsdatei die Annotation preview.baremetal.cluster.gke.io/parallel-upgrade: "enable" hinzu:

---
gcrKeyPath: /path/to/gcr-sa
gkeConnectAgentServiceAccountKeyPath: /path/to/gke-connect
gkeConnectRegisterServiceAccountKeyPath: /path/to/gke-register
sshPrivateKeyPath: /path/to/private-ssh-key
cloudOperationsServiceAccountKeyPath: /path/to/logging-sa
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-cluster1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    baremetal.cluster.gke.io/maintenance-mode-deadline-seconds: "180"
    preview.baremetal.cluster.gke.io/parallel-upgrade: "enable"
    ...

Fügen Sie dem Manifest des Worker-Knotenpools einen Abschnitt upgradeStrategy hinzu. Dieses Manifest muss sich in der Clusterkonfigurationsdatei befinden. Wenn sie in einer separaten Manifestdatei enthalten ist, wird sie vom Befehl bmctl upgrade cluster nicht verarbeitet. 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.7
  - address:  10.200.0.8
  - address:  10.200.0.9
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
  
```
In diesem Beispiel lautet der Wert des Felds concurrentNodes 5. Dies bedeutet, dass 5 Knoten parallel aktualisiert werden. Der Mindest- und Standardwert dieses Felds ist 1 und der maximal zulässige Wert ist die Anzahl der Knoten im Worker-Knotenpool. Wir empfehlen jedoch, diesen Wert auf maximal 3% der Gesamtzahl der Knoten in Ihrem Cluster festzulegen. Wenn der Wert von concurrentNodes zu hoch ist, können Arbeitslasten während eines parallelen Upgrades beeinträchtigt werden.
Führen Sie ein Upgrade des Clusters durch, wie im obigen Abschnitt Administrator-, eigenständige, Hybrid- oder Nutzercluster upgraden beschrieben.

Parallele Upgrades von Knoten deaktivieren

Wenn Sie parallele Upgrades von Knoten deaktivieren möchten, setzen Sie die Annotation preview.baremetal.cluster.gke.io/parallel-upgrade in der Clusterkonfigurationsdatei auf disable.