Upgrade – Übersicht

Auf dieser Seite finden Sie eine Übersicht über den Upgrade-Prozess und Informationen zu Versionsabweichungen für Google Distributed Cloud (nur Software) für VMware-Cluster. Diese Informationen sollen Ihnen bei der Planung der Reihenfolge helfen, 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.

Diese Seite richtet sich an IT-Administratoren und ‑Betreiber, die den Lebenszyklus der zugrunde liegenden technischen Infrastruktur verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Unterschiede bei erweiterten Clustern

Wenn erweiterte Cluster aktiviert sind, gibt es einige Unterschiede bei Upgrades, insbesondere in der Vorschau erweiterter Cluster in Version 1.31. Wenn Sie die Unterschiede beim Upgrade sehen möchten, suchen Sie in diesem Dokument nach dem Wort advanced. Eine Tabelle mit allen Unterschieden finden Sie unter Unterschiede beim Ausführen von Advanced-Clustern.

Automatisches Upgrade auf erweiterte Cluster in Version 1.33

Wichtig :Wenn Sie Ihre Cluster von Version 1.32 auf 1.33 aktualisieren, werden sie automatisch auf erweiterte Cluster aktualisiert, die verbesserte Architekturen verwenden, die mehr Flexibilität und Skalierbarkeit bieten.

• gkectl-Version prüfen: Die gkectl-Version muss mit Ihrer Zielversion übereinstimmen. Wenn Sie beispielsweise ein Upgrade eines nicht erweiterten Clusters der Version 1.32 auf einen erweiterten Cluster der Version 1.33.0-gke.799 durchführen, muss die gkectl-Version 1.33.0-gke.799 sein. Diese strenge Versionsanforderung gilt nur während der Umstellung auf einen erweiterten Cluster. Für alle nachfolgenden Upgrades Ihres erweiterten Clusters gelten die Standardregeln für die Versionsabweichung.
• Versionsabweichung nicht zulässig: Wenn Sie ein Upgrade von einem nicht erweiterten auf einen erweiterten Cluster durchführen, können Sie die Steuerungsebene und die Knotenpools nicht separat aktualisieren. Sie müssen die Steuerungsebene und alle Knotenpools gleichzeitig auf Version 1.33 aktualisieren.

Versionsregeln

Die Regeln für Upgrades hängen von der Nebenversion des Clusters ab.

• Bei Versionen 1.30 und niedriger muss die Nebenversion des Nutzerclusters mindestens der Nebenversion des Administratorclusters entsprechen. Die Patchversion spielt keine Rolle. Wenn ein Nutzercluster beispielsweise Version 1.30.1 hat, kann der Administratorcluster auf eine höhere Patchversion wie 1.30.3 aktualisiert werden.

• Bei Version 1.31 und höher muss die Version des Administratorclusters, einschließlich der Patchversion, mindestens der Version des Nutzerclusters entsprechen. Wenn ein Administratorcluster beispielsweise Version 1.31.1 hat, kann der Nutzercluster höchstens auf Version 1.31.1 aktualisiert werden.

Wenn Sie Ihre Cluster auf Version 1.31 aktualisieren möchten, müssen Sie zuerst alle Ihre Cluster auf Version 1.30 aktualisieren. Wenn alle Cluster die Version 1.30 haben, führen Sie ein Upgrade des Administratorclusters auf Version 1.31 durch. Danach können Sie die Nutzercluster auf dieselbe 1.31-Patchversion wie den Administratorcluster aktualisieren.

Versionsregeln für gkectl

Die Version von gkectl, die Sie für das Upgrade verwenden können, hängt von der Zielclusterversion ab (d. h. der Version des Clusters, auf den Sie ein Upgrade durchführen). In der Regel verwenden Sie dieselbe Version von gkectl wie die Zielversion des Clusters. Während des Upgrades werden die folgenden Regeln erzwungen:

• Die gkectl-Version darf keine niedrigere Nebenversion als die Nebenversion des Zielclusters sein. Wenn Sie beispielsweise ein Upgrade eines Clusters der Version 1.29 auf Version 1.30 durchführen, können Sie gkectl 1.29 nicht verwenden, da diese niedriger als die Zielclusterversion ist. Patchversionen spielen keine Rolle. Sie können beispielsweise die gkectl-Version 1.29.0-gke.1456 verwenden, um ein Upgrade auf eine höhere Patch-Version wie 1.29.1000-gke.94 durchzuführen.

• Die Version gkectl darf nicht mehr als zwei Nebenversionen höher sein als die aktuelle Clusterversion. Wenn Sie beispielsweise ein Upgrade eines Clusters der Version 1.28 auf Version 1.29 ausführen, kann die gkectl-Version 1.29 oder 1.30 sein. Sie können jedoch nicht die gkectl-Version 1.31 verwenden, da sie drei Nebenversionen höher ist als die Clusterversion.

• Wenn Sie ein Upgrade des Clusters auf einen erweiterten Cluster durchführen, muss die gkectl-Version mit der Zielversion übereinstimmen. Wenn Sie beispielsweise ein Upgrade eines nicht erweiterten Clusters der Version 1.32 auf einen erweiterten Cluster der Version 1.33.0-gke.799 durchführen, muss die gkectl-Version 1.33.0-gke.799 sein.

  • Ihr Cluster wird in Version 1.33 standardmäßig auf einen erweiterten Cluster aktualisiert. Das bedeutet, dass bei Upgrades von 1.32 auf 1.33 die gkectl-Version mit der aktualisierten Version übereinstimmen muss.

  • Diese strenge Versionsanforderung gilt nur während der Umstellung auf einen erweiterten Cluster. Für alle nachfolgenden Upgrades Ihres erweiterten Clusters gelten die Standardregeln für die Versionsabweichung.

Falls erforderlich, lesen Sie den Abschnitt gkectl herunterladen, um eine unterstützte Version von gkectl zu erhalten.

Informationen zu Versionsabweichungen zwischen Administrator- und Nutzerclustern finden Sie in diesem Dokument im Abschnitt Versionsabweichung.

Legacy-Funktionen bei Upgrades gesperrt

Dataplane V2 ist für alle Nutzercluster erforderlich. Bevor Sie einen Nutzercluster auf Version 1.31 aktualisieren, folgen Sie der Anleitung unter Dataplane V2 aktivieren.

Die folgenden Legacy-Funktionen sind während des Cluster-Upgrades auf Version 1.32 blockiert:

• Konfiguration des integrierten F5 Big-IP-Load-Balancers
• Nicht-HA-Administratorcluster
• Kubeception-Nutzercluster
• Seesaw-Load-Balancer

Sie müssen Ihre Cluster zu empfohlenen Funktionen migrieren, bevor Sie ein Upgrade auf Version 1.32 durchführen.

Upgrade-Sequenz

Die Reihenfolge, in der Sie Administrator- und Nutzercluster aktualisieren, hängt von der Clusterversion ab, auf die Sie aktualisieren, der Zielversion:

1.31 und höher

Wenn die Zielversion 1.31 oder höher ist, müssen Sie den Administratorcluster vor dem Upgrade von Nutzerclustern, die vom Administratorcluster verwaltet werden, upgraden. In den folgenden Schritten wird die Upgrade-Reihenfolge beschrieben.

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 den Administratorcluster.

3. Aktualisieren Sie die Nutzercluster einzeln.

   • Sie können die Steuerungsebene eines Nutzerclusters auch separat von den Knotenpools im Nutzercluster aktualisieren. Weitere Informationen finden Sie unter Knotenpools aktualisieren.

     • Version 1.31: Nicht für erweiterte Cluster verfügbar.
     • Version 1.32 und höher: Verfügbar in erweiterten Clustern.

   • Sie können beim Upgrade von Knotenpools optional eine Nebenversion überspringen. Weitere Informationen finden Sie unter Version beim Upgraden von Knotenpools überspringen.

     • Version 1.31: Nicht für erweiterte Cluster verfügbar.
     • Version 1.32 und höher: Verfügbar in erweiterten Clustern.

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

1.30 und niedriger

Wenn die Zielversion 1.30 oder niedriger ist, müssen Sie alle Nutzercluster vor dem Upgrade des Administratorclusters aktualisieren, der sie verwaltet.

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.

   • Ab Version 1.16 können Sie beim Upgrade von Knotenpools optional eine Nebenversion überspringen. Weitere Informationen finden Sie unter Version beim Upgraden von Knotenpools überspringen.

   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 in diesem Dokument im Abschnitt Versionsabweichung.

Reihenfolge, in der Knoten aktualisiert werden

Die Reihenfolge, in der die Knoten der Steuerungsebene des Administratorclusters, die Knoten der Steuerungsebene des Nutzerclusters und die Worker-Knoten des Nutzerclusters aktualisiert werden, hängt von der Zielversion und davon ab, ob Controlplane V2 im Nutzercluster aktiviert ist.

Steuerungsebene v2

Wenn Controlplane V2 aktiviert ist, wird die Steuerungsebene für den Nutzercluster im Nutzercluster selbst ausgeführt. Bei Controlplane V2 werden die Knoten der Steuerungsebene des Nutzerclusters während des Upgrades des Nutzerclusters und die Knoten der Steuerungsebene des Administratorclusters während des Upgrades des Administratorclusters aktualisiert.

Kubeception

Wenn Controlplane V2 nicht aktiviert ist, wird die Steuerungsebene für den Nutzercluster auf einem oder mehreren Knoten im Administratorcluster ausgeführt. Diese Konfiguration wird als „Kubeception“ bezeichnet. Bei Kubeception-Clustern bestimmt die Upgrade-Version das Verhalten bei Knotenupgrades:

Version upgraden	Verhalten bei Knotenupgrades
1.32 und höher	Kubeception-Cluster werden nicht unterstützt. Sie müssen alle Nutzercluster zu Controlplane V2 migrieren, bevor Sie auf Version 1.32 aktualisieren.
1,31	Die Administratorclusterknoten werden während des Administratorcluster-Upgrades aktualisiert. Die Knoten der Steuerungsebene des Nutzerclusters werden während des Upgrades des Nutzerclusters aktualisiert.
1.30 und niedriger	Sowohl die Knoten der Steuerungsebene des Nutzerclusters als auch die Knoten der Steuerungsebene des Administratorclusters werden während des Upgrades des Administratorclusters aktualisiert.

Administratorcluster-Upgrades

1.31 und höher

Wenn die Zielversion 1.31 oder höher ist, müssen Sie zuerst den Administratorcluster und dann die Nutzercluster aktualisieren.

Sie können entweder gkectl oder die gcloud CLI verwenden, um Administratorcluster zu aktualisieren.

1.30 und niedriger

Wenn die Zielversion 1.30 oder niedriger ist, führen Sie zuerst ein Upgrade aller Nutzercluster und dann des Administratorclusters durch. Sie können den Administratorcluster upgraden, wenn die Version der Steuerungsebene und der Knotenpools in allen Nutzerclustern mindestens eine Nebenversion höher ist als die des Administratorclusters.

Nur gkectl unterstützt das Upgraden von Administratorclustern. Die GKE On-Prem API-Clients unterstützen keine Upgrades von Administratorclustern.

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.

• Version 1.31: Nicht für erweiterte Cluster verfügbar.
• Version 1.32 und höher: Verfügbar in erweiterten Clustern.

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. Weitere Informationen finden Sie unter Knotenpools aktualisieren.

Nebenversion beim Upgrade von Knotenpools überspringen

Wenn Ihre Cluster Version 1.16 oder höher haben, können Sie beim Upgraden von Knotenpools eine Nebenversion überspringen. Durch ein Upgrade mit Überspringen von Versionen wird die Zeit halbiert, die für das sequenzielle Upgrade von Knotenpools um zwei Versionen erforderlich wäre. Außerdem können Sie durch das Überspringen von Versionen den Zeitraum zwischen Upgrades verlängern, der erforderlich ist, um eine unterstützte Version zu verwenden. Wenn Sie die Anzahl der Upgrades reduzieren, werden Arbeitslastunterbrechungen und die Überprüfungszeit verringert. Weitere Informationen finden Sie unter Version beim Upgraden von Knotenpools überspringen.

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.

  Wenn Sie die erweiterte Clusterfunktion aktiviert haben, müssen Sie für das Upgrade gkectl verwenden. Die GKE On-Prem API-Clients werden in erweiterten Clustern nicht unterstützt.

• Die Google Cloud Console, die Google Cloud CLI oder Terraform, die Sie auf jedem Computer ausführen können, 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.

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.

1.31 und höher

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

Generell gilt: Wenn 1.n die Nebenversion des Administratorclusters ist, können die Nutzercluster die Version 1.n-2, 1.n-1 oder 1.n haben. Der Administratorcluster kann erst auf die nächste Nebenversion aktualisiert werden, wenn alle Nutzercluster die Version 1.n oder 1.n-1 haben.

1.29 – 1.30

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 sein als ihr Administratorcluster. Wenn ein Administratorcluster beispielsweise Version 1.31 hat, können die von diesem Administratorcluster verwalteten Nutzercluster Version 1.31, 1.32 oder 1.33 haben.

Generell gilt: Wenn 1.n die Nebenversion des Administratorclusters ist, können die Nutzercluster die Version 1.n, 1.n+1 oder 1.n+2 haben. Nutzercluster 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

Vorschau

Diese Funktion unterliegt den Bedingungen für Pre‑GA-Angebote im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie gesehen“ verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

In Version 1.28 können Nutzercluster bis zu zwei Nebenversionen höher sein als ihr Administratorcluster. 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 mindestens auf Version 1.16 aktualisiert wurde.

1.16 und niedriger

In Version 1.16 und niedriger können Nutzercluster nur eine Nebenversion höher sein als der Administratorcluster. 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 den Versionen der Steuerungsebene und des Knotenpools eines Nutzerclusters

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 sein als die Knotenpools im Cluster. Wenn die Steuerungsebene eines Nutzerclusters beispielsweise Version 1.33 hat, können die Knotenpools im Cluster die Version 1.31, 1.32 oder 1.33 haben.

Wenn 1.n die Nebenversion der Steuerungsebene eines Nutzerclusters ist, können die Knotenpools im Cluster die Version 1.n, 1.n-1 oder 1.n-2 haben. Nutzercluster-Steuerungsebenen können erst auf die nächste Nebenversion aktualisiert werden, wenn alle Knotenpools die Version 1.n oder 1.n-1 haben.

1,28

Vorschau

Diese Funktion unterliegt den Bedingungen für Pre‑GA-Angebote im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie gesehen“ verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

In Version 1.28 kann die Steuerungsebene eines Nutzerclusters bis zu zwei Nebenversionen höher sein als die Knotenpools im Cluster. Wenn die Steuerungsebene eines Nutzerclusters beispielsweise Version 1.28 hat, können die Knotenpools im Cluster die Version 1.15, 1.16 oder 1.28 haben. Nutzercluster-Steuerungsebenen können erst auf Version 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 sein als die Knotenpools im Cluster. Wenn die Steuerungsebene eines Nutzerclusters beispielsweise Version 1.16 hat, können die Knotenpools im Cluster die Version 1.15 oder 1.16 haben.

Generell gilt: Wenn 1.n die Nebenversion der Steuerungsebene eines Nutzerclusters ist, können die Knotenpools im Cluster die Version 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.33.0 auf 1.33.1 oder von 1.32.1 auf 1.33.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.31.x auf Version 1.33.x durchführen möchten, ist ein direktes Upgrade nicht möglich. Sie müssen zuerst ein Upgrade von Version 1.31.x auf 1.32.x und dann ein Upgrade auf 1.33.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.33 und ein Knotenpool Version 1.31 hat, können Sie Version 1.32 überspringen und den Knotenpool direkt auf Version 1.33 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.

• Version 1.31: Nicht für erweiterte Cluster verfügbar.
• Version 1.32 und höher: Verfügbar in erweiterten Clustern.

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.33.X auf Version 1.33.Y aktualisieren, solange Y größer als X ist. Beispielsweise können Sie ein Upgrade von 1.32.0 auf 1.32.1 und von 1.32.1 auf 1.32.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.