Upgrade-Übersicht

Diese Seite bietet einen Überblick über den Upgradeprozess und Informationen zu Versionsverzerrungen, mit denen Sie die Reihenfolge planen können, in der Sie Cluster in einer Multi-Cluster-Umgebung upgraden. Ausführlichere Informationen zur Planung, einschließlich einer Checkliste, die Ihnen bei der Planung des Upgrades hilft, finden Sie unter Best Practices für das Upgrade.

Sequenz upgraden

Direkte Upgrades seit Version 1.7 müssen immer einer bestimmten Upgradereihenfolge folgen:

  1. Führen Sie ein Upgrade der Administratorworkstation durch. Das empfiehlt sich auch dann, wenn Sie die Google Cloud Console, die Google Cloud CLI oder Terraform verwenden möchten, um Nutzercluster zu aktualisieren.

  2. Aktualisieren Sie die Nutzercluster einzeln nacheinander. In Version 1.14 und höher können Sie optional die Steuerungsebene eines Nutzerclusters getrennt von den Knotenpools im Nutzercluster upgraden. Weitere Informationen dazu finden Sie unter Upgrades von Nutzerclustern.

    Wenn alle Knotenpools in einem Nutzercluster dieselbe Version wie die Steuerungsebene des Nutzerclusters haben, wird der Nutzercluster vollständig aktualisiert.

    Ein Administratorcluster kann keine höhere Nebenversion haben als alle anderen Nutzercluster, die er verwaltet. Wenn einer Ihrer Nutzercluster dieselbe Nebenversion wie der Administratorcluster hat, können Sie den Administratorcluster nicht aktualisieren.

  3. Wenn alle Nutzercluster mindestens eine Nebenversion nach dem Administratorcluster sind, können Sie den Administratorcluster optional upgraden.

Die Versionsabweichung und die Versionsregeln für Upgrades haben sich in 1.28 und höher geändert. Weitere Informationen finden Sie unter Versionsabweichungen.

Nutzerclusterupgrades

Wenn Sie Nutzercluster upgraden, können Sie den Nutzercluster als Ganzes aktualisieren (d. h. Sie können die Steuerungsebene und alle Knotenpools im Cluster aktualisieren) oder die Steuerungsebene des Nutzerclusters aktualisieren und die Knotenpools in der aktuellen Version belassen. Welchen Ansatz Sie wählen, hängt von mehreren Faktoren ab, z. B.:

  • Die Umgebung (Produktion oder Nicht-Produktion), in der sich der Cluster befindet.
  • Die Länge Ihres Wartungsfensters.
  • Die Version des Nutzerclusters.

In einer Entwicklungsumgebung können Sie beispielsweise den Prozess einfach halten und sowohl die Steuerungsebene des Nutzerclusters als auch alle Knotenpools aktualisieren. In einer Produktionsumgebung mit einem kurzen Wartungsfenster empfiehlt es sich jedoch, nur die Steuerungsebene zu aktualisieren, da dies weniger Zeit in Anspruch nimmt und bei Steuerungsebenen mit Hochverfügbarkeit (High Availability, Hochverfügbarkeit) die Nutzerarbeitslasten nicht beeinträchtigt werden. Wenn die Steuerungsebene Version 1.28 oder höher ist, können Sie eine Nebenversion beim Upgrade von Knotenpools überspringen.

Ein Upgrade von Knotenpools unabhängig von der Steuerungsebene wird für Ubuntu- und COS-Knotenpools unterstützt, jedoch nicht für Windows-Knotenpools.

Knotenpools selektiv aktualisieren

In bestimmten Situationen möchten Sie möglicherweise einige, aber nicht alle Knotenpools in einem Nutzercluster aktualisieren. Nach dem Upgrade der Steuerungsebene können Sie beispielsweise einen Knotenpool aktualisieren, der wenig Traffic aufweist oder Ihre am wenigsten kritischen Arbeitslasten ausführt. Wenn Sie sich sicher sind, dass Ihre Arbeitslasten in der neuen Version korrekt ausgeführt werden, können Sie weitere Knotenpools upgraden, bis schließlich alle Knotenpools aktualisiert sind.

Tool zum Aktualisieren von Nutzerclustern auswählen

Google Distributed Cloud bietet Ihnen eine Auswahl an Tools für das Upgrade von Nutzerclustern.

  • Das gkectl-Befehlszeilentool, das Sie auf Ihrer Administratorworkstation ausführen. Vor dem Upgrade ändern Sie die Konfigurationsdatei des Nutzerclusters, um die Zielversion für die Steuerungsebene des Clusters und optional für die Knotenpools festzulegen. Sie geben diese Datei in der Befehlszeile für gkectl an.

  • Die Google Cloud Console, die Google Cloud CLI oder Terraform, die Sie auf jedem Computer mit Netzwerkverbindung zur GKE On-Prem API ausführen können. Diese Standardtools sind Clients der GKE On-Prem API, die auf der Google Cloud-Infrastruktur ausgeführt wird.

    • Sie können Terraform für das Upgrade nur verwenden, wenn Sie den Nutzercluster mit Terraform erstellt haben.

    • Wenn der Nutzercluster mit gkectl erstellt wurde, muss der Cluster bei der GKE On-Prem API registriert sein, um die Console oder die gcloud CLI für das Upgrade verwenden zu können. Ab Version 1.16 werden mit gkectl erstellte Cluster standardmäßig in der GKE On-Prem API registriert. Cluster, die in früheren Versionen erstellt wurden, können Sie nach der Erstellung registrieren.

      Auch wenn Sie gkectl für das Upgrade verwenden, empfiehlt es sich, den Cluster in der GKE On-Prem API zu registrieren, um Informationen über die Cluster über die Console oder die gcloud CLI zu erhalten.

Welches Tool Sie verwenden, hängt davon ab, wie Sie Nutzercluster upgraden möchten:

  • Cluster als Ganzes aktualisieren: Sie können gkectl, die Google Cloud Console, die Google Cloud CLI oder Terraform verwenden, um einen Nutzercluster (die Steuerungsebene zusammen mit allen Knotenpools) zu aktualisieren.

  • Nur Steuerungsebene upgraden: Sie können gkectl, die gcloud CLI oder Terraform verwenden, um die Steuerungsebene eines Nutzerclusters getrennt von den Knotenpools zu aktualisieren. Die Konsole unterstützt kein Upgrade nur der Steuerungsebene.

  • Knotenpools nach dem Upgrade der Steuerungsebene selektiv upgraden: Sie können gkectl, die gcloud CLI oder Terraform verwenden, um bestimmte Knotenpools nach dem Upgrade der Steuerungsebene zu aktualisieren.

  • Gleichzeitiges Upgrade der Steuerungsebene und eines oder mehrerer Knotenpools: Nur gkectl unterstützt diesen Anwendungsfall.

Administratorclusterupgrades

Wenn die Steuerungsebene und die Knotenpools in allen Nutzerclustern mindestens eine Nebenversion nach dem Administratorcluster haben, können Sie den Administratorcluster optional upgraden. Nur gkectl unterstützt das Upgrade von Administratorclustern. Die GKE On-Prem API-Clients unterstützen kein Upgrade von Administratorclustern.

Versionsabweichung

Die Versionsabweichung ist die Differenz zwischen Nebenversionen zwischen einem Administratorcluster und seinen verwalteten Nutzerclustern. In den folgenden Abschnitten bezieht sich die Nutzerclusterversion auf die Version der Steuerungsebene und der Knotenpools insgesamt.

Darüber hinaus ist die Versionsabweichung der Unterschied zwischen Nebenversionen zwischen der Steuerungsebene eines Nutzerclusters und den Knotenpools auf dem Nutzercluster.

In einer Multi-Cluster-Umgebung können Sie die Reihenfolge, in der Sie Cluster upgraden, besser planen, wenn Sie die unterstützten Versionsabweichungen und Versionsregeln für Upgrades kennen.

Versionsabweichung zwischen Administrator- und Nutzercluster

Ein Administratorcluster kann Nutzercluster mit verschiedenen Versionen verwalten. Mit dieser Funktion können Sie eine Flotte von Nutzerclustern nach einem für Ihre Organisation geeigneten Zeitplan aktualisieren.

1.29 und höher

Die Versionsabweichung ist die gleiche wie in 1.28. In Version 1.29 ist diese Funktion in die Phase Allgemeine Verfügbarkeit übergegangen.

Ab Version 1.29 können Nutzercluster bis zu zwei Nebenversionen höher sein als ihr Administratorcluster. Wenn ein Administratorcluster beispielsweise den Wert 1,16 hat, können die von diesem Administratorcluster verwalteten Nutzercluster den Wert 1,16, 1,28 oder 1,29 haben.

Allgemein gilt: Wenn 1.n die Nebenversion des Administratorclusters ist, können sich die Nutzercluster unter 1.n, 1.n+1 oder 1.n+2 befinden. Für Nutzercluster unter 1.n+2 kann erst dann ein Upgrade auf die nächste Nebenversion durchgeführt werden, wenn für den Administratorcluster mindestens eine Nebenversion aktualisiert wurde.

1,28

In Version 1.28 können Nutzercluster bis zu zwei Nebenversionen höher sein als ihr Administratorcluster. Wenn ein Administratorcluster beispielsweise die Version 1.15 hat, können die von diesem Administratorcluster verwalteten Nutzercluster die Version 1.15, 1.16 oder 1.28 haben. Nutzercluster mit Version 1.28 können erst auf Version 1.29 aktualisiert werden, wenn ein Upgrade des Administratorclusters auf mindestens 1.16 durchgeführt wurde.

1.16 und niedriger

In Version 1.16 und niedriger können Nutzercluster nur eine Nebenversion höher sein als ihr Administratorcluster. Wenn ein Administratorcluster beispielsweise 1,15 hat, können die von diesem Administratorcluster verwalteten Nutzercluster die Version 1,15 oder 1,16 haben.

Allgemein gilt: Wenn 1.n die Nebenversion des Administratorclusters ist, können sich die Nutzercluster unter 1.n oder 1.n+1 befinden. Nutzercluster können erst auf die nächste Nebenversion aktualisiert werden, wenn der Administratorcluster dieselbe Nebenversion wie der Nutzercluster hat.

Abweichung der Steuerungsebene des Nutzerclusters und der Version des Knotenpools

1.29 und höher

Die Versionsabweichung ist die gleiche wie in 1.28. In Version 1.29 ist diese Funktion in die Phase Allgemeine Verfügbarkeit übergegangen.

Ab Version 1.29 kann die Steuerungsebene eines Nutzerclusters bis zu zwei Nebenversionen höher sein als die Knotenpools im Cluster. Wenn die Steuerungsebene eines Nutzerclusters beispielsweise bei 1,29 liegt, können die Knotenpools im Cluster 1,16, 1,28 oder 1,29 sein.

Allgemein gilt: Wenn 1.n die Nebenversion der Steuerungsebene eines Nutzerclusters ist, können sich die Knotenpools im Cluster unter 1.n, 1.n-1 oder 1.n-2 befinden. Nutzercluster-Steuerungsebenen können erst auf die nächste Nebenversion aktualisiert werden, wenn alle Knotenpools den Status 1.n oder 1.n-1 haben.

1,28

In Version 1.28 kann die Steuerungsebene eines Nutzerclusters bis zu zwei Nebenversionen höher sein als die Knotenpools im Cluster. Wenn die Steuerungsebene eines Nutzerclusters beispielsweise bei 1,28 liegt, können die Knotenpools im Cluster den Wert 1,15, 1,16 oder 1,28 haben. Nutzercluster-Steuerungsebenen können erst auf 1.29 aktualisiert werden, wenn sich alle Knotenpools unter 1.28 oder 1.16 befinden.

1.16 und niedriger

In Version 1.16 und niedriger kann die Steuerungsebene eines Nutzerclusters nur eine Nebenversion höher sein als die Knotenpools im Cluster. Wenn die Steuerungsebene eines Nutzerclusters beispielsweise auf 1,16 liegt, können die Knotenpools im Cluster den Wert 1,15 oder 1,16 haben.

Allgemein gilt: Wenn 1.n die Nebenversion der Steuerungsebene eines Nutzerclusters ist, können sich die Knotenpools im Cluster im Allgemeinen unter 1.n oder 1.n-1 befinden. Nutzercluster können erst dann auf die nächste Nebenversion aktualisiert werden, wenn alle Knotenpools dieselbe Nebenversion wie die Steuerungsebene haben.

Versionsregeln für Upgrades der Administrator- und Nutzercluster-Steuerungsebenen

Die Versionsregeln für Administratorcluster und Upgrades der Nutzercluster-Steuerungsebene sind identisch. Sie können direkt ein Upgrade auf jede Version ausführen, die im selben Nebenrelease oder in der nächsten Nebenversion enthalten ist. Beispielsweise können Sie ein Upgrade von 1.29.0 auf 1.29.1 oder von 1.28.1 auf 1.29.0 durchführen. Die Patchversionen wirken sich nicht auf die Upgradeversionsregeln aus.

Wenn Sie ein Upgrade auf eine Version durchführen, die nicht Teil der nächsten Nebenversion ist, müssen Sie zwischen der aktuellen und der Zielversion jeweils eine Version jedes Nebenrelease aktualisieren. Das Überspringen einer Nebenversion wird nicht unterstützt. Wenn Sie beispielsweise ein Upgrade von Version 1.16.x auf Version 1.29.x durchführen möchten, können Sie kein direktes Upgrade durchführen. Führen Sie zuerst ein Upgrade von 1.16.x auf 1.28.x und dann ein Upgrade auf 1.29.x durch.

Im Allgemeinen werden für Upgrades von Administratorclustern und Nutzercluster-Steuerungsebenen nur Upgrades von 1.n auf 1.n+1 unterstützt.

Versionsregeln für Knotenpoolupgrades

In Version 1.28 und höher können Sie beim Upgrade eines Knotenpools in einem Nutzercluster eine Nebenversion überspringen. Wenn die Steuerungsebene eines Nutzerclusters beispielsweise auf 1,29 und ein Knotenpool auf 1,16 liegt, können Sie 1,28 überspringen und den Knotenpool direkt auf 1,29 aktualisieren. Die Patchversionen wirken sich nicht auf die Versionsregeln für das Upgrade aus.

Allgemein gilt: Wenn sich die Steuerungsebene eines Nutzerclusters unter 1.n befindet, können Sie Knotenpools, die sich unter 1.n-2 befinden, direkt auf 1.n aktualisieren. Wenn Sie beim Upgrade von Knotenpools eine Nebenversion überspringen, dauert dies möglicherweise weniger Zeit als bei zwei Knotenpoolupgrades (Upgrade von 1.n-2 auf 1.n-1 und dann auf 1.n). Dies ist ein weiterer Grund, warum Sie die Steuerungsebene eines Nutzerclusters getrennt von den Knotenpools, die auf dem Nutzercluster ausgeführt werden, upgraden möchten.

Upgrades der Patchversionen

Wir empfehlen, nach Möglichkeit ein Upgrade auf die neueste Patchversion durchzuführen, damit Ihre Cluster über die neuesten Sicherheitsupdates verfügen. Patchversionen wirken sich nicht auf Versionsabweichungen und Upgraderegeln aus. Für eine bestimmte Nebenversion können Sie ein Upgrade auf eine beliebige höhere Patchversion durchführen. Das heißt, Sie können einen 1.29.X-Versionscluster auf Version 1.29.Y aktualisieren, solange Y größer als X ist. Beispielsweise können Sie ein Upgrade von 1.28.0 auf 1.28.1 und von 1.28.1 auf 1.28.3 durchführen.

Nächste Schritte

Sehen Sie sich die Best Practices für das Upgrade an und erstellen Sie einen Plan für das Upgrade Ihrer Cluster.