Upgradeübersicht

Diese Seite bietet einen Überblick über den Upgradeprozess und Informationen zu Versionsabweichungen, damit Sie die Reihenfolge beim Upgrade von Clustern in einer Multi-Cluster-Umgebung planen können. Ausführlichere Informationen zur Planung, einschließlich einer Checkliste zur Planung des Upgrades, finden Sie unter Best Practices für Upgrades.

Upgradesequenz

Bei direkten Upgrades seit Version 1.7 muss immer eine bestimmte Upgradereihenfolge eingehalten werden:

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

  2. Aktualisieren Sie die Nutzercluster nacheinander. In Version 1.14 und höher können Sie optional ein Upgrade der Steuerungsebene eines Nutzerclusters von den Knotenpools im Nutzercluster durchführen. Weitere Informationen dazu, warum das erforderlich ist, finden Sie unter Upgrades von Nutzerclustern.

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

    Ein Administratorcluster darf keine spätere Nebenversion haben als die von ihm verwalteten Nutzercluster. Wenn einer Ihrer Nutzercluster dieselbe Nebenversion wie der Administratorcluster hat, können Sie den Administratorcluster nicht upgraden.

  3. Wenn alle Nutzercluster mindestens eine Nebenversion höher als der Administratorcluster haben, können Sie optional ein Upgrade des Administratorclusters durchführen.

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

Upgrades von Nutzerclustern

Beim Upgrade von Nutzerclustern können Sie den Nutzercluster vollständig upgraden (Sie können also die Steuerungsebene und alle Knotenpools im Cluster upgraden) oder die Steuerungsebene des Nutzerclusters aktualisieren und die Knotenpools unter 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 kann es sinnvoll sein, den Prozess einfach zu halten und sowohl die Steuerungsebene des Nutzerclusters als auch alle Knotenpools zu aktualisieren. In einer Produktionsumgebung mit einem kurzen Wartungsfenster kann es jedoch sinnvoll sein, nur die Steuerungsebene zu aktualisieren, da dies weniger Zeit in Anspruch nimmt und bei der Hochverfügbarkeit von Steuerungsebenen die Nutzerarbeitslasten durch das Upgrade der Steuerungsebene nicht beeinträchtigt werden. Wenn die Steuerungsebene die Version 1.28 oder höher hat, können Sie beim Upgrade von Knotenpools eine Nebenversion überspringen.

Das separate Upgrade von Knotenpools von der Steuerungsebene wird für Ubuntu- und COS-Knotenpools unterstützt, jedoch nicht für Windows-Knotenpools.

Knotenpools selektiv upgraden

In bestimmten Situationen kann es erforderlich sein, ein Upgrade für einige, aber nicht alle Knotenpools in einem Nutzercluster durchzuführen. Nach dem Upgrade der Steuerungsebene können Sie beispielsweise ein Upgrade für einen Knotenpool mit wenig Traffic ausführen oder für Ihre am wenigsten kritischen Arbeitslasten. Wenn Sie davon überzeugt sind, dass Ihre Arbeitslasten auf der neuen Version ordnungsgemäß ausgeführt werden, können Sie zusätzliche Knotenpools upgraden, bis schließlich alle Knotenpools aktualisiert werden.

Tool zum Upgraden von Nutzerclustern auswählen

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

  • Dem Befehlszeilentool gkectl, das Sie auf Ihrer Administratorworkstation ausführen. Vor dem Upgrade ändern Sie die Konfigurationsdatei Ihres 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 nur für das Upgrade verwenden, wenn Sie den Nutzercluster mit Terraform erstellt haben.

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

      Auch wenn Sie sich für die Verwendung von gkectl für das Upgrade entscheiden, können Sie den Cluster in der GKE On-Prem API registrieren, um über die Console oder die gcloud CLI Informationen zu den Clustern zu erhalten.

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

  • Cluster als Ganzes upgraden: 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 die Steuerungsebene upgraden: Mit gkectl, der gcloud CLI oder Terraform können Sie die Steuerungsebene eines Nutzerclusters getrennt von den Knotenpools upgraden. Die Konsole unterstützt nicht nur das Upgrade der Steuerungsebene.

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

  • Aktualisieren Sie die Steuerungsebene und einen oder mehrere Knotenpools gleichzeitig: Nur gkectl unterstützt diesen Anwendungsfall.

Administratorcluster upgraden

Wenn die Steuerungsebene und die Knotenpools in allen Nutzerclustern mindestens eine Nebenversion höher als die des Administratorclusters sind, können Sie optional ein Upgrade des Administratorclusters durchführen. Nur gkectl unterstützt das Upgrade von Administratorclustern. Die GKE On-Prem API-Clients unterstützen kein Upgrade von Administratorclustern.

Versionsabweichung

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

Darüber hinaus ist die Versionsabweichung der Unterschied der Nebenversionen zwischen der Steuerungsebene eines Nutzerclusters und den Knotenpools im 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 die Versionsregeln für Upgrades kennen.

Versionsabweichung bei Administrator- und Nutzercluster

Ein Administratorcluster kann Nutzercluster verwalten, die sich in verschiedenen Versionen befinden. Mit dieser Funktion können Sie eine Flotte von Nutzerclustern nach einem für Ihre Organisation passenden Zeitplan upgraden.

1.29 und höher

Die Versionsabweichung ist mit der in 1.28 identisch. In Version 1.29 ist diese Funktion in die Phase Allgemeine Verfügbarkeit übergegangen.

In Version 1.29 und höher können Nutzercluster bis zu zwei Nebenversionen höher sein als ihr Administratorcluster. Wenn sich ein Administratorcluster beispielsweise bei 1,16 befindet, können die von diesem Administratorcluster verwalteten Nutzercluster bei 1,16, 1,28 oder 1,29 liegen.

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 mit 1.n+2 kann erst 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 sich ein Administratorcluster beispielsweise bei 1,15 befindet, können die von diesem Administratorcluster verwalteten Nutzercluster die Version 1,15, 1,16 oder 1,28 haben. Nutzercluster mit 1.28 können erst auf 1.29 aktualisiert werden, wenn der Administratorcluster auf mindestens 1.16 aktualisiert wurde.

1.16 und niedriger

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

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.

Versionsabweichung der Steuerungsebene und des Knotenpools des Nutzerclusters

1.29 und höher

Die Versionsabweichung ist mit der in 1.28 identisch. 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 2 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 bei 1,16, 1,28 oder 1,29 liegen.

Allgemein gilt: Wenn 1.n die Nebenversion der Steuerungsebene eines Nutzerclusters ist, können sich die Knotenpools im Cluster in 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 sich die Steuerungsebene eines Nutzerclusters beispielsweise bei 1,28 befindet, können die Knotenpools im Cluster bei 1,15, 1,16 oder 1,28 liegen. Für Nutzercluster-Steuerungsebenen kann erst ein Upgrade auf 1,29 durchgeführt werden, wenn sich alle Knotenpools bei 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 sich die Steuerungsebene eines Nutzerclusters beispielsweise bei 1,16 befindet, können die Knotenpools im Cluster auch bei 1,15 oder 1,16 liegen.

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

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

Die Versionsregeln für Administratorcluster und Upgrades der Nutzercluster-Steuerungsebene sind identisch. Sie können direkt auf jede Version upgraden, die in derselben Nebenversion oder in der nächsten Nebenversion enthalten ist. Sie können beispielsweise ein Upgrade von 1.29.0 auf 1.29.1 oder von 1.28.1 auf 1.29.0 ausführen. Die Patchversionen wirken sich nicht auf die Regeln für die Upgradeversion 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 jeder Nebenversion aktualisieren. Das Überspringen einer Nebenversion wird nicht unterstützt. Wenn Sie beispielsweise ein Upgrade von Version 1.16.x auf Version 1.29.x ausführen möchten, können Sie das Upgrade nicht direkt ausführen. Sie müssen zuerst ein Upgrade von 1.16.x auf 1.28.x und dann ein Upgrade auf 1.29.x durchführen.

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

Ab Version 1.28 können Sie beim Upgrade eines Knotenpools in einem Nutzercluster eine Nebenversion überspringen. Wenn die Steuerungsebene eines Nutzerclusters beispielsweise bei 1,29 und ein Knotenpool bei 1,16 liegt, können Sie 1,28 überspringen und den Knotenpool direkt auf 1,29 upgraden. Die Patchversionen wirken sich nicht auf die Regeln für Upgradeversionen aus.

Allgemein gilt: Wenn sich die Steuerungsebene eines Nutzerclusters unter 1.n befindet, können Sie Knotenpools, die sich in 1.n-2 befinden, direkt auf 1.n upgraden. Das Überspringen einer Nebenversion beim Upgrade von Knotenpools kann den Zeitaufwand verringern, als bei zwei Knotenpoolupgrades (um von 1.n-2 auf 1.n-1 und dann auf 1.n zu aktualisieren). Dies ist ein weiterer Grund, warum Sie es vorziehen, die Steuerungsebene eines Nutzerclusters getrennt von den Knotenpools zu aktualisieren, die auf dem Nutzercluster ausgeführt werden.

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 Versionsverzerrungen und Upgraderegeln aus. Sie können für eine bestimmte Nebenversion 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 upgraden, 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

Lesen Sie die Best Practices für Upgrades und erstellen Sie einen Plan für das Upgrade Ihrer Cluster.