Upgrade – Übersicht

Auf dieser Seite finden Sie eine Übersicht über den Upgrade-Vorgang 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, finden Sie unter Best Practices für Upgrades.

Upgrade-Sequenz

Bei direkten Upgrades ab Version 1.7 muss immer eine bestimmte Upgrade-Sequenz eingehalten werden:

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

2. Aktualisieren Sie die Nutzercluster einzeln. Ab Version 1.14 können Sie die Steuerungsebene eines Nutzerclusters auch separat von den Knotenpools im Nutzercluster aktualisieren. Weitere Informationen dazu, warum Sie dies tun sollten, finden Sie unter Nutzercluster-Upgrades.

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

   Ein Administratorcluster darf keine höhere Nebenversion haben als die Nutzercluster, die von ihm verwaltet werden. Wenn einer Ihrer Nutzercluster dieselbe Nebenversion wie der Administratorcluster hat, können Sie den Administratorcluster nicht aktualisieren.

3. Wenn die Version aller Nutzercluster mindestens eine Nebenversion höher ist als die des Administratorclusters, können Sie optional ein Upgrade des Administratorclusters durchführen.

Die Versionsabweichung und die Versionsregeln für Upgrades haben sich ab Version 1.28 geändert. Weitere Informationen finden Sie unter Versionsabweichung.

Nutzercluster-Upgrades

Beim Aktualisieren von Nutzerclustern können Sie den Nutzercluster als Ganzes aktualisieren, d. h. die Steuerungsebene und alle Knotenpools im Cluster. Sie können auch nur die Steuerungsebene des Nutzerclusters aktualisieren und die Knotenpools bei der aktuellen Version belassen. Welchen Ansatz Sie wählen, hängt von mehreren Faktoren ab, unter anderem:

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

In einer Entwicklungsumgebung ist es wahrscheinlich sinnvoll, den Vorgang 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 nur die Steuerungsebene aktualisieren, da dies weniger Zeit in Anspruch nimmt. Bei Steuerungsebenen mit Hochverfügbarkeit sollte das Upgrade der Steuerungsebene die Arbeitslasten der Nutzer nicht beeinträchtigen. Wenn die Steuerungsebene Version 1.28 oder höher hat, können Sie beim Upgraden von Knotenpools eine Nebenversion überspringen.

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

Knotenpools selektiv upgraden

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 nur wenig Traffic hat oder auf dem Ihre am wenigsten kritischen Arbeitslasten ausgeführt werden. Wenn Sie sicher sind, dass Ihre Arbeitslasten in der neuen Version ordnungsgemäß ausgeführt werden, können Sie weitere Knotenpools aktualisieren, bis alle Knotenpools aktualisiert sind.

Tool zum Upgraden von Nutzerclustern auswählen

Google Distributed Cloud bietet eine Auswahl von Tools zum Upgraden von Nutzerclustern.

• Das 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, ausführbar auf jedem Computer, der eine Netzwerkverbindung zur GKE On-Prem API hat. Diese Standardtools sind Clients der GKE On-Prem API, die in der Google Cloud-Infrastruktur ausgeführt wird.

  • Sie können das Upgrade nur mit Terraform ausführen, 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, damit Sie die Console oder die gcloud CLI für das Upgrade verwenden können. Ab Version 1.16 werden Cluster, die mit gkectl erstellt wurden, 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, 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 aktualisieren 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 und alle Knotenpools) zu aktualisieren.

• Nur die Steuerungsebene aktualisieren: Mit gkectl, der gcloud CLI oder Terraform können Sie die Steuerungsebene eines Nutzerclusters separat von den Knotenpools aktualisieren. Die Console unterstützt kein eigenständiges Upgrade der Steuerungsebene.

• Knotenpools nach dem Upgrade der Steuerungsebene selektiv aktualisieren: Sie können gkectl, die gcloud CLI oder Terraform verwenden, um bestimmte Knotenpools zu aktualisieren, nachdem Sie ein Upgrade der Steuerungsebene ausgeführt haben.

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

Administratorcluster-Upgrades

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

Versionsabweichung

Die Versionsabweichung ist der Unterschied zwischen den Nebenversionen eines Administratorclusters und seiner verwalteten Nutzercluster. In den folgenden Abschnitten bezieht sich die Version des Nutzerclusters auf die Version der Steuerungsebene und der Knotenpools zusammen.

Außerdem ist die Versionsabweichung der Unterschied zwischen den Nebenversionen der Steuerungsebene eines Nutzerclusters und den Knotenpools im Nutzercluster.

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

Abweichung der Versionen von Administrator- und Nutzerclustern

Ein Administratorcluster kann Nutzercluster verwalten, die verschiedene Versionen haben. So können Sie eine Flotte von Nutzerclustern nach einem Zeitplan aktualisieren, der für Ihre Organisation geeignet ist.

Abweichung zwischen den Versionen der Steuerungsebene und des Knotenpools eines Nutzerclusters

Versionsregeln für Upgrades der Steuerungsebene von Administrator- und Nutzerclustern

Die Versionsregeln für Upgrades der Steuerungsebene von Administratorclustern und Nutzerclustern sind identisch. Sie können ein Upgrade direkt auf jede Version ausführen, die sich in der gleichen Nebenversion oder in der nächsten Nebenversion befindet. Beispielsweise können Sie ein Upgrade von Version 1.30.0 auf 1.30.1 oder von 1.29.1 auf 1.30.0 ausführen. Die Patchversionen wirken sich nicht auf die Versionsregeln für Upgrades aus.

Wenn Sie ein Upgrade auf eine Version ausführen, die nicht Teil der nächsten Nebenversion ist, müssen Sie zwischen der aktuellen und der Zielversion ein Upgrade für jede Nebenversion ausführen. Das Überspringen einer Nebenversion wird nicht unterstützt. Wenn Sie beispielsweise ein Upgrade von Version 1.28.x auf Version 1.30.x durchführen möchten, ist ein direktes Upgrade nicht möglich. Sie müssen zuerst ein Upgrade von Version 1.28.x auf 1.29.x und dann ein Upgrade auf 1.30.x ausführen.

Generell werden für Administratorcluster und Nutzercluster-Steuerungsebenen nur Upgrades von 1.n auf 1.n+1 unterstützt.

Versionsregeln für Knotenpool-Upgrades

Ab Version 1.28 können Sie beim Upgrade eines Knotenpools in einem Nutzercluster eine Nebenversion überspringen. Wenn die Steuerungsebene eines Nutzerclusters beispielsweise Version 1.30 und ein Knotenpool Version 1.28 hat, können Sie Version 1.29 überspringen und den Knotenpool direkt auf Version 1.30 aktualisieren. Die Patchversionen wirken sich nicht auf die Versionsregeln für Upgrades aus.

Wenn die Steuerungsebene eines Nutzerclusters Version 1.n hat, können Sie Knotenpools mit der Version 1.n-2 direkt auf 1.n aktualisieren. Wenn Sie beim Upgraden von Knotenpools eine Nebenversion überspringen, kann das weniger Zeit in Anspruch nehmen als zwei Knotenpool-Upgrades nacheinander (von 1.n-2 auf 1.n-1 und dann auf 1.n). Dies ist ein weiterer Grund, warum es von Vorteil sein kann, die Steuerungsebene eines Nutzerclusters getrennt von den Knotenpools zu aktualisieren, die im Nutzercluster ausgeführt werden.

Upgrades der Patchversionen

Wir empfehlen, nach Möglichkeit ein Upgrade auf die neueste Patchversion durchzuführen, damit Ihre Cluster die neuesten Sicherheitsupdates haben. Patchversionen wirken sich nicht auf die Versionsabweichung und die Upgraderegeln aus. Für eine Nebenversion können Sie ein Upgrade auf eine höhere Patchversion ausführen. Das heißt, Sie können einen Cluster der Version 1.30.X auf Version 1.30.Y aktualisieren, solange Y größer als X ist. Beispielsweise können Sie ein Upgrade von 1.29.0 auf 1.29.1 und von 1.29.1 auf 1.29.3 durchführen.

Nächste Schritte

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