Cluster aktualisieren

Version 1.11 (unsupported)

• Neueste
• Version 1.16
• Frühere Versionen (nicht unterstützt)

Wenn Sie eine neue Version von bmctl installieren, können Sie Ihre vorhandenen Cluster aktualisieren, die mit einer früheren Version erstellt wurden. Wenn Sie einen Cluster auf die neueste Anthos on Bare Metal-Version upgraden, erhält der Cluster weitere Features und Fehlerkorrekturen. Außerdem wird so gewährleistet, dass Ihr Cluster unterstützt bleibt. Sie können Administrator-, Hybrid-, Standalone- oder Nutzercluster mit dem Befehl bmctl upgrade cluster upgraden.

Hinweis: Wenn Sie Anthos-Cluster auf Bare-Metal von einer Version mit einem Sicherheitspatch auf die nächste Nebenversion aktualisieren, empfehlen wir ein Upgrade auf die höchste verfügbare Patchversion, um sicherzustellen, dass Sie über die neuesten Sicherheitspatches verfügen. Lesen Sie immer die Versionshinweise vor dem Upgrade, damit Sie wissen, was sich geändert hat, einschließlich Sicherheitsupdates und bekannter Probleme. Ein Upgrade auf eine niedrigere Patchversion wird nicht unterstützt.

Ü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 Anthos Cluster on Bare Metal-Release 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.

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

Versionsregeln für Upgrades

Wenn Sie eine neue Version von bmctl herunterladen und installieren, können Sie ein Upgrade für Ihre Administrator-, Hybrid-, eigenständigen und Nutzercluster ausführen, die mit einer früheren Version von bmctl erstellt oder aktualisiert wurden. Cluster können nicht auf eine niedrigere Version herabgestuft werden.

Sie können ein Cluster nur auf eine Version aktualisieren, die der von Ihnen verwendeten Version von bmctl entspricht. Wenn Sie also Version 1.11.8 von bmctl verwenden, können Sie für einen Cluster nur ein Upgrade auf Version 1.11.8 durchführen.

Upgrades der Patchversionen

Für eine Nebenversion können Sie ein Upgrade auf eine höhere Patchversion ausführen. Das heißt, Sie können einen 1.11.X-Versionscluster auf Version 1.11.Y aktualisieren, solange Y größer als X ist. Beispielsweise können Sie ein Upgrade von 1.10.0 auf 1.10.1 und von 1.10.1 auf 1.10.3 durchführen. Wir empfehlen, nach Möglichkeit ein Upgrade auf die neueste Patchversion durchzuführen, damit Ihre Cluster die neuesten Sicherheitsupdates haben.

Upgrades von Nebenversionen

Sie können Cluster unabhängig von der Patchversion von einer Nebenversion auf die nächste aktualisieren. Sie können also ein Upgrade von 1.N.X auf 1.N+1.Y durchführen, wobei 1.N.X die Version Ihres Clusters ist und N+1 ist die nächste verfügbare Nebenversion. Die Patchversionen X und Y wirken sich in diesem Fall nicht auf die Upgradelogik aus. Beispielsweise ist ein Upgrade von 1.10.3 auf 1.11.8 möglich.

Beim Upgrade von Clustern können Sie Nebenversionen nicht überspringen. Wenn Sie versuchen, ein Upgrade auf eine Nebenversion durchzuführen, die zwei oder mehr Nebenversionen höher ist als die Clusterversion, gibt bmctl einen Fehler aus. Sie können beispielsweise einen Cluster der Version 1.9.0 nicht auf Version 1.11.0 aktualisieren.

Ein Administratorcluster kann Nutzercluster verwalten, die sich in der gleichen oder einer früheren Nebenversion befinden. Verwaltete Nutzercluster können maximal eine Nebenversion niedriger als der Administratorcluster sein. Prüfen Sie daher vor dem Upgrade eines Administratorclusters auf eine neue Nebenversion, ob alle verwalteten Nutzercluster dieselbe Nebenversion als der Administratorcluster haben.

Die Beispiele in der folgenden Upgrade-Anleitung zeigen den Upgrade-Prozess von Version 1.10.2 auf Anthos-Cluster auf Bare Metal 1.11.8.

Pod-Dichte

Anthos-Cluster auf Bare Metal unterstützt die Konfiguration von bis zu 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-Cluster auf 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.

Hinweis: Beachten Sie, dass Sie einen Administratorcluster aktualisieren sollten, bevor Sie einen zugehörigen Nutzercluster aktualisieren. Bevor Sie jedoch den Administratorcluster auf Version 1.11.8 aktualisieren, prüfen Sie, ob die zugehörigen Nutzercluster die Version 1.10.0 oder höher haben. bmctl gibt einen Fehler aus, wenn ein Nutzercluster unter 1.10.0 liegt.

1. 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.11.8/linux-amd64/bmctl bmctl
   chmod a+x bmctl
   

2. Ändern Sie die Cluster-Konfigurationsdatei, um die Cluster-Version von Anthos-Cluster on Bare Metal von 1.10.2 auf 1.11.8 zu ändern. Das folgende Beispiel zeigt ein Beispiel für eine Administratorclusterkonfiguration:

   ---
   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.10.2 to 1.11.8, shown below
     anthosBareMetalVersion: 1.11.8
   

3. Beim Upgrade von Clustern auf 1.11.8 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 wie auf der Seite "Google-Dienste und Dienstkonten aktivieren" unter Dienstkonten für die Verwendung mit Connect konfigurieren ab.
   2. Verweisen Sie auf die heruntergeladenen JSON-Schlüssel in den zugehörigen Feldern gkeConnectAgentServiceAccountKeyPath und gkeConnectRegisterServiceAccountKeyPath der Cluster-Konfigurationsdatei.

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.

   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.