Upgrade – Übersicht

Diese Seite bietet einen Überblick über den Upgradeprozess und Informationen zu Versionsabweichungen, die Ihnen bei der Planung der Reihenfolge helfen sollen, in der Sie Cluster in einer Multi-Cluster-Umgebung aktualisieren. Ausführlichere Informationen zur Planung, einschließlich einer Checkliste zur Planung des Upgrades, finden Sie unter Best Practices für das Upgrade.

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, wenn Sie die Google Cloud Console, die Google Cloud CLI oder Terraform verwenden möchten, um Nutzercluster zu aktualisieren.

  2. Führen Sie ein Upgrade der Nutzercluster nacheinander durch. In Version 1.14 und höher können Sie optional ein Upgrade der Steuerungsebene eines Nutzerclusters unabhängig von den Knotenpools im Nutzercluster durchführen. Weitere Informationen dazu 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 kann keine spätere Nebenversion haben als jeder der von ihm verwalteten Nutzercluster. Wenn einer Ihrer Nutzercluster dieselbe Nebenversion wie der Administratorcluster hat, können Sie den Administratorcluster nicht aktualisieren.

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

Die Versionsabweichung und die Versionsregeln für Upgrades haben sich in 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 als Ganzes upgraden (d. h. Sie können die Steuerungsebene und alle Knotenpools im Cluster upgraden) oder die Steuerungsebene des Nutzerclusters aktualisieren und die Knotenpools auf der aktuellen Version belassen. Welcher 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 hilfreich 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 sollten Sie jedoch möglicherweise nur ein Upgrade der Steuerungsebene durchführen, da dies weniger Zeit in Anspruch nimmt. Außerdem sollte das Upgrade der Steuerungsebene Nutzerarbeitslasten durch das Upgrade der Steuerungsebene nicht beeinträchtigen. Wenn sich die Steuerungsebene in der Version 1.28 oder höher befindet, 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 möchten Sie möglicherweise einige, aber nicht alle Knotenpools in einem Nutzercluster upgraden. Nach dem Upgrade der Steuerungsebene können Sie beispielsweise einen Knotenpool mit wenig Traffic upgraden oder die am wenigsten kritischen Arbeitslasten ausführen. Sobald Sie davon überzeugt sind, dass Ihre Arbeitslasten in der neuen Version ordnungsgemäß ausgeführt werden, können Sie zusätzliche Knotenpools aktualisieren, bis schließlich alle Knotenpools aktualisiert werden.

Tool zum Upgraden von Nutzerclustern auswählen

GKE on VMware 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 der Nutzercluster mit gkectl erstellt wurde, muss der Cluster 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 in der GKE On-Prem API registriert. Bei Clustern, die in früheren Versionen erstellt wurden, können Sie den Cluster registrieren, nachdem er erstellt wurde.

      Auch wenn Sie gkectl für das Upgrade verwenden möchten, sollten Sie den Cluster in der GKE On-Prem API registrieren, um über die Console oder die gcloud CLI Informationen zu den Clustern abzurufen.

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

  • Cluster insgesamt 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: Sie können gkectl, die gcloud CLI oder Terraform verwenden, um die Steuerungsebene eines Nutzerclusters getrennt von den Knotenpools zu aktualisieren. Die Console 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 einem Upgrade der Steuerungsebene zu aktualisieren.

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

Administratorclusterupgrades

Wenn die Steuerungsebene und die Knotenpools auf allen Nutzerclustern mindestens eine Nebenversion höher als der Administratorcluster 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 Nutzerclusterversion auf die Version der Steuerungsebene und der Knotenpools als Ganzes.

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

In einer Multi-Cluster-Umgebung kann es hilfreich sein, die unterstützte Versionsverzerrung und die Versionsregeln für Upgrades zu verstehen, um die Reihenfolge zu planen, in der Sie Cluster upgraden.

Versionsabweichung von Administrator- und Nutzerclustern

Ein Administratorcluster kann Nutzercluster verwalten, die sich in verschiedenen Versionen befinden. Mit dieser Funktion können Sie ein Upgrade einer Flotte von Nutzerclustern nach einem für Ihre Organisation geltenden Zeitplan durchführen.

1.16 und früher

In Version 1.16 und früheren Versionen können Nutzercluster nur eine Nebenversion nach ihrem Administratorcluster liegen. Wenn sich ein Administratorcluster beispielsweise bei 1,15 befindet, können die von diesem Administratorcluster verwalteten Nutzercluster auch 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.

1.28 und höher

In Version 1.28 und höher können Nutzercluster bis zu zwei Nebenversionen später als ihr Administratorcluster sein. Wenn ein Administratorcluster beispielsweise 1.15 hat, können die von diesem Administratorcluster verwalteten Nutzercluster die Version 1.15, 1.16 oder 1.28 haben (1.28 ist die Version, die in der Versionsausrichtung mit GKE auf 1.16 folgt). 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 der Domain 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.

Versionsabweichung der Steuerungsebene und des Knotenpools des Nutzerclusters

1.16 und früher

In Version 1.16 und früher kann die Steuerungsebene eines Nutzerclusters nur eine Nebenversion später als die Knotenpools im Cluster sein. Wenn sich die Steuerungsebene eines Nutzerclusters beispielsweise bei 1,16 befindet, können die Knotenpools im Cluster 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 unter 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.

1.28 und höher

In Version 1.28 und höher kann die Steuerungsebene eines Nutzerclusters bis zu zwei Nebenversionen später als die Knotenpools im Cluster sein. Wenn sich die Steuerungsebene eines Nutzerclusters beispielsweise bei 1,28 befindet, können sich die Knotenpools im Cluster bei 1,15, 1,16 oder 1,28 befinden. 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.

Steuerungsebenen von Nutzerclustern können erst auf die nächste Nebenversion aktualisiert werden, wenn alle Knotenpools den Status 1.n oder 1.n-1 haben.

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

Die Versionsregeln für Administratorcluster und Upgrades der Nutzercluster-Steuerungsebene sind identisch. Sie können ein direktes Upgrade auf eine beliebige Version ausführen, die in derselben Nebenversion oder in der nächsten Nebenversion enthalten ist. Sie können beispielsweise ein Upgrade von 1.28.0 auf 1.28.1 oder von 1.16.1 auf 1.28.0 ausfü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 für jede Nebenversion jeweils eine Version zwischen der aktuellen und der Zielversion upgraden. Das Überspringen einer Nebenversion wird nicht unterstützt. Wenn Sie beispielsweise ein Upgrade von Version 1.15.x auf Version 1.28.x ausführen möchten, können Sie kein direktes Upgrade durchführen. Sie müssen zuerst ein Upgrade von 1.15.x auf 1.16.x und dann ein Upgrade auf 1.28.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

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 bei 1,28 und der Knotenpool auf 1,15 festgelegt ist, können Sie 1,16 überspringen und den Knotenpool direkt auf 1,28 upgraden. Die Patchversionen wirken sich nicht auf die Upgradeversionsregeln aus.

Allgemein gilt: Wenn sich die Steuerungsebene eines Nutzerclusters in 1.n befindet, können Sie Knotenpools, die sich unter 1.n-2 befinden, direkt auf 1.n aktualisieren. Das Überspringen einer Nebenversion beim Upgrade von Knotenpools kann den Zeitaufwand verringern als das Ausführen von 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 vielleicht vorziehen, die Steuerungsebene eines Nutzerclusters getrennt von den Knotenpools zu aktualisieren, die auf dem Nutzercluster ausgeführt werden.

Upgrades der Patchversionen

Wir empfehlen ein Upgrade auf die neueste Patchversion nach Möglichkeit, damit Ihre Cluster die neuesten Sicherheitsupdates haben. Patchversionen wirken sich nicht auf die Versionsverzerrung und die Upgraderegeln aus. Für eine bestimmte Nebenversion können Sie ein Upgrade auf eine höhere Patchversion durchführen. Das heißt, Sie können einen Cluster der 1.28.X-Version auf Version 1.28.Y aktualisieren, solange Y größer als X ist. Beispielsweise können Sie ein Upgrade von 1.16.0 auf 1.16.1 und von 1.16.1 auf 1.16.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.