Aktualisierung – Ü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-Abfolge eingehalten werden:

  1. Führen Sie ein Upgrade der Administrator-Workstation 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 optional separat von den Knotenpools des Nutzerclusters 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 Nutzercluster vollständig aktualisiert.

    Ein Administratorcluster darf keine höhere Nebenversion als die von ihm verwalteten Nutzercluster haben. 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 Version 1.28 und höher geändert. Weitere Informationen finden Sie unter Versionsabweichung.

Nutzercluster-Upgrades

Beim Upgraden 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, z. B.:

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

In einer Entwicklungsumgebung möchten Sie den Vorgang beispielsweise möglichst einfach halten und sowohl die Steuerungsebene des Nutzerclusters als auch alle Knotenpools 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 (HA) 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 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 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 an Tools zum Upgraden von Nutzerclustern.

  • Das Befehlszeilentool gkectl, das Sie auf Ihrer Administrator-Workstation 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 Terraform für das Upgrade nur 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, 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 zusammen mit allen 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 keine Upgrades von nur der Steuerungsebene.

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

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

Administratorcluster-Upgrades

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 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 des Nutzerclusters.

In einer Multi-Cluster-Umgebung können Sie die Reihenfolge der Cluster-Upgrades 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 sich in verschiedenen Versionen befinden. So können Sie eine Flotte von Nutzerclustern nach einem Zeitplan aktualisieren, der für Ihre Organisation geeignet ist.

1.29 und höher

Die Versionsabweichung ist mit der von Version 1.28 identisch. Mit Version 1.29 wurde diese Funktion in die Phase General Availability überführt.

Ab Version 1.29 können Nutzercluster bis zu zwei Nebenversionen höher als ihr Administratorcluster sein. Wenn ein Administratorcluster beispielsweise Version 1.28 hat, können die von diesem Administratorcluster verwalteten Nutzercluster Version 1.28, 1.29 oder 1.30 haben.

Generell gilt: Wenn 1.n die Nebenversion des Administratorclusters ist, können die Nutzercluster 1.n, 1.n+1 oder 1.n+2 haben. Nutzercluster mit der Version 1.n+2 können erst auf die nächste Nebenversion aktualisiert werden, wenn der Administratorcluster mindestens eine Nebenversion höher ist.

1,28

Ab Version 1.28 können Nutzercluster bis zu zwei Nebenversionen höher als ihr Administratorcluster sein. Wenn ein Administratorcluster beispielsweise Version 1.15 hat, können die von diesem Administratorcluster verwalteten Nutzercluster Version 1.15, 1.16 oder 1.28 haben. Nutzercluster der Version 1.28 können erst auf Version 1.29 aktualisiert werden, wenn der Administratorcluster auf mindestens Version 1.16 aktualisiert wurde.

1.16 und niedriger

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

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

Abweichung zwischen der Version der Steuerungsebene des Nutzerclusters und der des Knotenpools

1.29 und höher

Die Versionsabweichung ist mit der von Version 1.28 identisch. Mit Version 1.29 wurde diese Funktion in die Phase General Availability überführt.

Ab Version 1.29 kann die Steuerungsebene eines Nutzerclusters bis zu zwei Nebenversionen höher als die Knotenpools im Cluster sein. Wenn die Steuerungsebene eines Nutzerclusters beispielsweise 1.30 ist, können die Knotenpools im Cluster 1.28, 1.29 oder 1.30 haben.

Generell gilt: Wenn 1.n die Nebenversion der Steuerungsebene eines Nutzerclusters ist, können die Knotenpools im Cluster 1.n, 1.n-1 oder 1.n-2 sein. Steuerungsebenen von Nutzerclustern können erst auf die nächste Nebenversion aktualisiert werden, wenn alle Knotenpools 1.n oder 1.n-1 erreicht haben.

1,28

In Version 1.28 kann die Steuerungsebene eines Nutzerclusters bis zu zwei Nebenversionen höher als die Knotenpools im Cluster sein. Wenn die Steuerungsebene eines Nutzerclusters beispielsweise 1.28 ist, können die Knotenpools im Cluster 1.15, 1.16 oder 1.28 haben. Steuerungsebenen von Nutzerclustern können erst auf 1.29 aktualisiert werden, wenn alle Knotenpools die Version 1.28 oder 1.16 haben.

1.16 und niedriger

In Version 1.16 und niedriger kann die Steuerungsebene eines Nutzerclusters nur eine Nebenversion höher als die Knotenpools im Cluster sein. Wenn die Steuerungsebene eines Nutzerclusters beispielsweise 1.16 ist, können die Knotenpools im Cluster 1.15 oder 1.16 haben.

Generell gilt: Wenn 1.n die Nebenversion der Steuerungsebene eines Nutzerclusters ist, können die Knotenpools im Cluster 1.n oder 1.n-1 haben. 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 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 1.28.x auf 1.29.x und dann ein Upgrade auf 1.30.x ausführen.

Generell werden nur Upgrades von 1.n auf 1.n+1 für Upgrades von Administratorclustern und Steuerungsebenen der Nutzercluster 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 1.n hat, können Sie Knotenpools, die 1.n-2 haben, 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 Sie die Steuerungsebene eines Nutzerclusters getrennt von den Knotenpools aktualisieren sollten, 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 1.30.X-Versionscluster 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 Upgrade Ihrer Cluster.