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 eine Nebenversion höher als der Administratorcluster sind, können Sie optional ein Upgrade des Administratorclusters durchführen.

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.

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 eine Nebenversion höher als der Administratorcluster sind, 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 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.

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.

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.

Versionsabweichung der Steuerungsebene und des Knotenpools des Nutzerclusters

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.

Versionsregeln für Upgrades von Administrator- und Nutzerclustern

Die Versionsregeln für das Upgrade eines Administratorclusters, der Steuerungsebene eines Nutzerclusters und der Knotenpools von Nutzerclustern sind identisch. Sie können direkt auf eine beliebige Version aktualisieren, die sich in derselben Nebenversion oder in der nächsten Nebenversion befindet. Sie können beispielsweise ein Upgrade von 1.16.0 auf 1.16.1 oder von 1.15.1 auf 1.16.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 von Version 1.14.x auf Version 1.16.x aktualisieren möchten, können Sie kein direktes Upgrade durchführen. Sie müssen zuerst ein Upgrade von 1.14.x auf 1.15.x und dann ein Upgrade auf 1.16.x durchführen.

Im Allgemeinen werden für Administratorclusterupgrades und Nutzerclusterupgrades nur Upgrades von 1.n auf 1.n+1 unterstützt.

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.16.X-Version auf Version 1.16.Y aktualisieren, solange Y größer als X ist. Beispielsweise können Sie ein Upgrade von 1.15.0 auf 1.15.1 und von 1.15.1 auf 1.15.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.