Lebenszyklus und Phasen von Clusterupgrades

Ein Upgrade von Google Distributed Cloud umfasst mehrere Schritte und Komponenten. Wenn Sie den Upgrade-Status im Blick behalten oder Probleme diagnostizieren und beheben möchten, ist es hilfreich zu wissen, was passiert, wenn Sie den Befehl bmctl upgrade cluster ausführen. In diesem Dokument werden die Komponenten und Phasen eines Cluster-Upgrades beschrieben.

Übersicht

Beim Upgrade wird Ihr Google Distributed Cloud-Cluster von der aktuellen Version auf eine höhere Version umgestellt.

Diese Versionsinformationen werden im Administratorcluster an den folgenden Stellen als Teil der benutzerdefinierten Clusterressource gespeichert:

  • status.anthosBareMetalVersion: Definiert die aktuelle Version des Clusters.

  • spec.anthosBareMetalVersion: Definiert die Zielversion und wird festgelegt, wenn der Upgrade-Prozess gestartet wird.

Bei einem erfolgreichen Upgrade wird status.anthosBareMetalVersion mit spec.anthosBareMetalVersion abgeglichen, sodass in beiden Feldern die Zielversion angezeigt wird.

Abweichung bei der Clusterversion

Die Abweichung der Clusterversion ist der Versionsunterschied zwischen einem verwaltenden Cluster (Hybrid- oder Administratorcluster) und seinen verwalteten Nutzerclustern. Wenn Sie einen Nutzercluster hinzufügen oder aktualisieren, gelten die folgenden Versionsregeln:

1,30

Für Nutzercluster, die von einem Administrator- oder Hybrid-Cluster der Version 1.30 verwaltet werden, gelten die folgenden Regeln:

  • Die Version eines Nutzerclusters darf nicht höher sein als die Version des verwaltenden Clusters (Administrator- oder Hybrid-Cluster).

  • (1.30 GA) Nutzercluster können bis zu zwei Nebenversionen niedriger als die Version des verwaltenden Clusters sein. Ein Administratorcluster der Version 1.30 kann beispielsweise einen Nutzercluster der Version 1.28 verwalten. Diese Funktion zur Verwaltung von Versionsabweichungen vom Typ n-2 ist für die Verwaltung von Clustern mit Version 1.30 allgemein verfügbar.

  • (1.30 GA) Für einen bestimmten verwaltenden Cluster mit Version 1.30 müssen Nutzercluster nicht dieselbe Nebenversion haben. Ein Administratorcluster der Version 1.30 kann beispielsweise Nutzercluster der Versionen 1.30, 1.29 und 1.28 verwalten.

    Die Funktion zur Verwaltung mehrerer Abweichungen bietet Ihnen mehr Flexibilität bei der Planung Ihrer Flotten-Upgrades. Sie müssen beispielsweise nicht alle Nutzercluster der Version 1.28 auf Version 1.29 aktualisieren, bevor Sie Ihren Administratorcluster auf Version 1.30 aktualisieren können.

1,29

Für Nutzercluster, die von einem Administrator- oder Hybrid-Cluster der Version 1.29 verwaltet werden, gelten die folgenden Regeln:

  • Die Version eines Nutzerclusters darf nicht höher sein als die Version des verwaltenden Clusters (Administrator- oder Hybrid-Cluster).

  • (1.29, Vorabversion) Nutzercluster können bis zu zwei Nebenversionen niedriger als die Version des verwaltenden Clusters sein. Beispielsweise kann ein Administratorcluster der Version 1.29 einen Nutzercluster der Version 1.16 verwalten. Diese Verwaltung von Versionsabweichungen vom Typ n-2 ist als Vorabversion für die Verwaltung von Clustern mit Version 1.29 verfügbar.

  • (1.29, Vorabversion) Für einen bestimmten verwaltenden Cluster müssen Nutzercluster nicht dieselbe Nebenversion haben. Ein Administratorcluster der Version 1.29 kann beispielsweise Nutzercluster der Versionen 1.29, 1.28 und 1.16 verwalten. Diese Verwaltung von Abweichungen bei unterschiedlichen Versionen ist als Vorabversion für die Verwaltung von Clustern der Version 1.29 verfügbar.

    Die Vorabversion der Funktion zur Verwaltung mehrerer Abweichungen bietet mehr Flexibilität bei der Planung von Flotten-Upgrades. Sie müssen beispielsweise nicht alle Nutzercluster der Version 1.16 auf Version 1.28 aktualisieren, bevor Sie Ihren Administratorcluster auf Version 1.29 aktualisieren können.

1.28 und früher

Für Nutzercluster, die von einem Administrator- oder Hybrid-Cluster der Version 1.28 oder älter verwaltet werden, gelten die folgenden Regeln:

  • Die Version eines Nutzerclusters darf nicht höher sein als die Version des verwaltenden Clusters (Administrator- oder Hybrid-Cluster).

  • Nutzercluster können maximal eine Nebenversion niedriger als die Version des verwaltenden Clusters sein. Ein Administratorcluster der Version 1.28 kann beispielsweise keinen Nutzercluster der Version 1.15 verwalten.

  • Für einen bestimmten verwaltenden Cluster müssen alle verwalteten Nutzercluster dieselbe Nebenversion haben.

Informationen zu Versionsabweichungsregeln für Knotenpools finden Sie unter Regeln für die Versionsverwaltung von Knotenpools.

Versionsregeln

Wenn Sie eine neue Version von bmctl herunterladen und installieren, können Sie ein Upgrade für Ihre Administrator-, Hybrid-, eigenständigen und Nutzercluster ausführen, die mit einer früheren Version von bmctl erstellt oder aktualisiert wurden. Cluster können nicht auf eine niedrigere Version herabgestuft werden.

Sie können ein Cluster nur auf eine Version aktualisieren, die der von Ihnen verwendeten Version von bmctl entspricht. Das heißt, wenn Sie die Version 1.30.100-gke.96 von bmctl verwenden, können Sie einen Cluster nur auf Version 1.30.100-gke.96 aktualisieren.

Upgrades der Patchversionen

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.100 und von 1.29.100 auf 1.29.300 durchführen. Wir empfehlen, nach Möglichkeit ein Upgrade auf die neueste Patchversion durchzuführen, damit Ihre Cluster die neuesten Sicherheitsupdates haben.

Upgrades von Nebenversionen

Sie können Cluster unabhängig von der Patchversion von einer Nebenversion auf die nächste aktualisieren. Sie können also ein Upgrade von 1.N.X auf 1.N+1.Y durchführen, wobei 1.N.X die Version Ihres Clusters ist und N+1 ist die nächste verfügbare Nebenversion. Die Patchversionen X und Y wirken sich in diesem Fall nicht auf die Upgradelogik aus. Beispielsweise ist ein Upgrade von 1.29.600-gke.108 auf 1.30.100-gke.96 möglich.

Beim Upgrade von Clustern können Sie Nebenversionen nicht überspringen. Wenn Sie versuchen, ein Upgrade auf eine Nebenversion durchzuführen, die zwei oder mehr Nebenversionen höher ist als die Clusterversion, gibt bmctl einen Fehler aus. Sie können beispielsweise einen Cluster der Version 1.28.0 nicht auf Version 1.30.0 aktualisieren.

Ein Administratorcluster kann Nutzercluster verwalten, die sich in der gleichen oder einer früheren Nebenversion befinden. Verwaltete Nutzercluster können maximal eine Nebenversion niedriger als der Administratorcluster sein. Prüfen Sie daher vor dem Upgrade eines Administratorclusters auf eine neue Nebenversion, ob alle verwalteten Nutzercluster dieselbe Nebenversion als der Administratorcluster haben.

Regeln für die Versionsverwaltung von Knotenpools

Wenn Sie Knotenpools selektiv aktualisieren, gelten die folgenden Versionsregeln:

1,30

  • Die Clusterversion muss mindestens der Version des Worker-Knotenpools entsprechen.

  • Die maximale Versionsabweichung zwischen einem Worker-Knotenpool und dem Cluster beträgt zwei Nebenversionen.

  • Worker-Knotenpools können sich in einer beliebigen Patchversion einer kompatiblen Nebenversion befinden.

1,29

  • Die Clusterversion muss mindestens der Version des Worker-Knotenpools entsprechen.

  • (1.29 GA) Die maximale Versionsabweichung zwischen einem Worker-Knotenpool und dem Cluster beträgt zwei Nebenversionen.

  • Worker-Knotenpools dürfen nicht eine Version verwenden, die chronologisch später als die Clusterversion veröffentlicht wurde. Die ältere Version enthält nicht die umfassenden Details für die neuere Version, was eine Voraussetzung für die Kompatibilität ist.

    Beispielsweise wurde Version 1.16.6 nach Version 1.28.100-gke.146 veröffentlicht. Daher können Sie Ihren Cluster nicht von Version 1.16.6 auf Version 1.28.100-gke.146 aktualisieren und einen Worker-Knotenpool bei Version 1.16.6 belassen. Wenn Sie Ihren Cluster auf Version 1.28.100-gke.146 aktualisieren, aber einen Worker-Knotenpool bei Version 1.16.5 belassen, können Sie den Worker-Knotenpool nicht auf Version 1.16.6 aktualisieren, solange der Cluster Version 1.28.100-gke.146 hat.

1,28

  • Die Clusterversion muss mindestens der Version des Worker-Knotenpools entsprechen.

  • (1.28, Vorabversion) Die maximale Versionsabweichung zwischen einem Worker-Knotenpool und dem Cluster beträgt zwei Nebenversionen, wenn die Vorabversion der Versionsabweichung n-2 aktiviert ist. Wenn Sie diese Funktion nicht aktivieren, beträgt die maximale Versionsabweichung zwischen einem Worker-Knotenpool und dem Cluster eine Nebenversion.

  • Worker-Knotenpools dürfen nicht eine Version verwenden, die chronologisch später als die Clusterversion veröffentlicht wurde. Die ältere Version enthält nicht die umfassenden Details für die neuere Version, was eine Voraussetzung für die Kompatibilität ist.

    Beispielsweise wurde Version 1.16.6 nach Version 1.28.100-gke.146 veröffentlicht. Daher können Sie Ihren Cluster nicht von Version 1.16.6 auf Version 1.28.100-gke.146 aktualisieren und einen Worker-Knotenpool bei Version 1.16.6 belassen. Wenn Sie Ihren Cluster auf Version 1.28.100-gke.146 aktualisieren, aber einen Worker-Knotenpool bei Version 1.16.5 belassen, können Sie den Worker-Knotenpool nicht auf Version 1.16.6 aktualisieren, solange der Cluster Version 1.28.100-gke.146 hat.

1.16

  • Die Clusterversion muss mindestens der Version des Worker-Knotenpools entsprechen.

  • Die maximale Versionsabweichung zwischen einem Worker-Knotenpool und dem Cluster ist eine Nebenversion.

  • Worker-Knotenpools dürfen nicht eine Version verwenden, die chronologisch später als die Clusterversion veröffentlicht wurde. Die ältere Version enthält nicht die umfassenden Details für die neuere Version, was eine Voraussetzung für die Kompatibilität ist.

    Beispielsweise wurde Version 1.16.6 nach Version 1.28.100-gke.146 veröffentlicht. Daher können Sie Ihren Cluster nicht von Version 1.16.6 auf Version 1.28.100-gke.146 aktualisieren und einen Worker-Knotenpool bei Version 1.16.6 belassen. Wenn Sie Ihren Cluster auf Version 1.28.100-gke.146 aktualisieren, aber einen Worker-Knotenpool bei Version 1.16.5 belassen, können Sie den Worker-Knotenpool nicht auf Version 1.16.6 aktualisieren, solange der Cluster Version 1.28.100-gke.146 hat.

In der folgenden Tabelle sind die unterstützten Knotenpoolversionen aufgeführt, die für eine bestimmte Clusterversion zulässig sind:

1,30

Für Knotenpools mit einer kompatiblen Nebenversion, Version 1.29 oder Version 1.28, sind alle Patchversionen mit Clustern mit beliebigen Patchversionen der Nebenversion 1.30 kompatibel.

1,29

Clusterversion (Steuerungsebene) Unterstützte Versionen von Worker-Knotenpools (hinzugefügte Versionen fett)
1.29.600-gke.105
  • 1.29.600-gke.105
  • 1.29.500-gke.162
  • 1.29.400-gke.86
  • 1.29.300-gke.185
  • 1.29.200-gke.243
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.900-gke.112
  • 1.28.800-gke.111
  • 1.28.700-gke.150
  • 1.28.600-gke.163
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.12
  • 1.16.11
  • 1.16.10
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
1.29.500-gke.162
  • 1.29.500-gke.162
  • 1.29.400-gke.86
  • 1.29.300-gke.185
  • 1.29.200-gke.243
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.900-gke.112
  • 1.28.800-gke.111
  • 1.28.700-gke.150
  • 1.28.600-gke.163
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.12
  • 1.16.11
  • 1.16.10
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
1.29.400-gke.86
  • 1.29.400-gke.86
  • 1.29.300-gke.185
  • 1.29.200-gke.243
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.800-gke.111
  • 1.28.700-gke.150
  • 1.28.600-gke.163
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.11
  • 1.16.10
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
1.29.300-gke.185
  • 1.29.300-gke.185
  • 1.29.200-gke.243
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.700-gke.150
  • 1.28.600-gke.163
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.10
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
1.29.200-gke.243
  • 1.29.200-gke.243
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
1.29.100-gke.251
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
1.29.0-gke.1449
  • 1.29.0-gke.1449
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0

1,28

Clusterversion (Steuerungsebene) Unterstützte Versionen von Worker-Knotenpools (hinzugefügte Versionen fett)
1.28.1000-gke.60
  • 1.28.1000-gke.60
  • 1.28.900-gke.112
  • 1.28.800-gke.111
  • 1.28.700-gke.150
  • 1.28.600-gke.163
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.12
  • 1.16.11
  • 1.16.10
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.11
  • 1.15.10
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.900-gke.112
  • 1.28.900-gke.112
  • 1.28.800-gke.111
  • 1.28.700-gke.150
  • 1.28.600-gke.163
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.11
  • 1.16.10
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.11
  • 1.15.10
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.800-gke.111
  • 1.28.800-gke.111
  • 1.28.700-gke.150
  • 1.28.600-gke.163
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.11
  • 1.16.10
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.11
  • 1.15.10
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.700-gke.150
  • 1.28.700-gke.150
  • 1.28.600-gke.163
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.11
  • 1.15.10
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.600-gke.163
  • 1.28.600-gke.163
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.11
  • 1.15.10
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.500-gke.120
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.11
  • 1.15.10
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.400-gke.77
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.11
  • 1.15.10
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.300-gke.131
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.10
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.200-gke.118
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.100-gke.146
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.0-gke.425
  • 1.28.0-gke.425
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

     

     

     

1.16

Clusterversion (Steuerungsebene) Unterstützte Versionen von Worker-Knotenpools (hinzugefügte Versionen fett)
1.16.12
  • 1.16.12
  • 1.16.11
  • 1.16.10
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.11
  • 1.15.10
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.11
  • 1.16.11
  • 1.16.10
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.11
  • 1.15.10
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.10
  • 1.16.10
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.11
  • 1.15.10
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.9
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.11
  • 1.15.10
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.8
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.11
  • 1.15.10
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.7
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.11
  • 1.15.10
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.6
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.5
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.4
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.3
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.2
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.1
  • 1.16.1
  • 1.16.0
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.0
  • 1.16.0
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

Komponenten aktualisieren

Komponenten werden sowohl auf Knoten- als auch auf Clusterebene aktualisiert. Auf Clusterebene werden die folgenden Komponenten aktualisiert:

  • Clusterkomponenten für Netzwerk, Beobachtbarkeit und Speicher.
  • Bei Administrator-, Hybrid- und eigenständigen Clustern: die Lebenszykluscontroller.
  • Das Feld gke-connect-agent.

Knoten in einem Cluster werden mit einer der folgenden Rollen ausgeführt. Je nach Rolle des Knotens werden unterschiedliche Komponenten aktualisiert:

Rolle des Knotens Funktion Komponenten, die aktualisiert werden sollen
Worker Führt Nutzerarbeitslasten aus Kubelet, Containerlaufzeit (Docker oder containerd)
Steuerungsebene Führt die Kubernetes-Steuerungsebene, Cluster-Lebenszykluscontroller und Plattform-Add-ons der Google Kubernetes Engine (GKE) Enterprise Edition aus Statische Pods der Kubernetes-Steuerungsebene (kubeapi-server, kube-scheduler, kube-controller-manager, etcd)

Lebenszykluscontroller wie lifecycle-controllers-manager und anthos-cluster-operator

Plattform-Add-ons der Google Kubernetes Engine (GKE) Enterprise Edition wie stackdriver-log-aggregator und gke-connect-agent
Load Balancer der Steuerungsebene Führt HAProxy und Keepalived aus, die Traffic an kube-apiserver weiterleiten, und MetalLB-Lautsprecher, um virtuelle IP-Adressen anzufordern Statische Pods des Load Balancer der Steuerungsebene (HAProxy, Keepalived)

MetalLB-Lautsprecher

Voraussichtliche Ausfallzeit

In der folgenden Tabelle finden Sie Informationen zur erwarteten Ausfallzeit und den möglichen Auswirkungen eines Cluster-Upgrades. In dieser Tabelle wird davon ausgegangen, dass Sie mehrere Clusterknoten und eine Hochverfügbarkeits-Steuerungsebene haben. Wenn Sie einen eigenständigen Cluster ausführen oder keine Hochverfügbarkeits-Steuerungsebene haben, ist mit zusätzlichen Ausfallzeiten zu rechnen. Sofern nicht anders angegeben, gilt diese Ausfallzeit sowohl für Upgrades von Administratorclustern als auch von Nutzerclustern:

Komponenten Voraussichtliche Ausfallzeit Während Ausfallzeiten
Kubernetes-Steuerungsebene – API-Server (kube-apiserver), etcd und Planer Keine Ausfallzeiten –
Lebenszykluscontroller und ansible-runner-Job (nur Administratorcluster) Keine Ausfallzeiten –
Kubernetes-Steuerungsebene loadbalancer-haproxy und keepalived Vorübergehende Ausfallzeit (weniger als 1 bis 2 Minuten), wenn der Load Balancer den Traffic weiterleitet. Beginn des Upgrade-Prozesses.
Beobachtbarkeit – pipeline-stackdriver und metrics-server Operator wird per Drain beendet und aktualisiert. Die Ausfallzeit sollte weniger als 5 Minuten betragen.

DaemonSets funktionieren weiterhin ohne Ausfallzeit.		 Nach Abschluss des Upgrades der Steuerungsebenenknoten.
Container Network Interface (CNI) Keine Ausfallzeiten für vorhandene Netzwerkrouten.

DaemonSet wird paarweise ohne Ausfallzeit bereitgestellt.

Der Operator wird per Drain beendet und aktualisiert. Ausfallzeit von weniger als 5 Minuten		 Nach Abschluss des Upgrades der Steuerungsebenenknoten.
MetalLB (nur Nutzercluster) Operator wird per Drain beendet und aktualisiert. Die Ausfallzeit beträgt weniger als 5 Minuten.

Keine Ausfallzeiten für den vorhandenen Dienst		 Nach Abschluss des Upgrades der Steuerungsebenenknoten.
CoreDNS- und DNS-Autoscaler (nur Nutzercluster) CoreDNS hat mehrere Replikate mit Autoscaling. Normalerweise keine Ausfallzeiten. Nach Abschluss des Upgrades der Steuerungsebenenknoten.
Bereitsteller lokaler Volumes Keine Ausfallzeit für vorhandene bereitgestellte nichtflüchtige Volumes (PVs).

Eine Ausfallzeit von 5 Minuten ist für den Operator möglich.		 Nach Abschluss des Upgrades der Steuerungsebenenknoten.
Istio/Ingress Der Istio-Operator wird per Drain beendet und aktualisiert. Die Ausfallzeit beträgt etwa 5 Minuten.

Vorhandener konfigurierter eingehender Traffic funktioniert weiterhin.		 Nach Abschluss des Upgrades der Steuerungsebenenknoten.
Andere Systemoperatoren 5 Minuten Ausfallzeit, wenn per Drain beendet und ein Upgrade durchgeführt wurde. Nach Abschluss des Upgrades der Steuerungsebenenknoten.
Nutzerarbeitslasten Hängt von der Konfiguration ab, z. B. ob sie hochverfügbar ist.

Prüfen Sie Ihre eigenen Arbeitslastbereitstellungen, um die potenziellen Auswirkungen zu ermitteln.		 Wenn die Worker-Knoten aktualisiert werden.

Details zum Upgrade des Nutzerclusters

In diesem Abschnitt wird die Reihenfolge der Komponenten-Upgrades und Statusinformationen für ein Nutzercluster-Upgrade beschrieben. Im folgenden Abschnitt werden Abweichungen von diesem Ablauf für Upgrades von Administrator- oder Hybrid-Clustern bzw. eigenständigen Clustern beschrieben.

Das folgende Diagramm zeigt den Ablauf der Preflight-Prüfung für ein Nutzercluster-Upgrade:

Bei der Cluster-Preflight-Prüfung werden zusätzliche Systemdiagnosen für den Cluster ausgeführt, bevor der Upgrade-Vorgang beginnt.

Das obige Diagramm zeigt die Schritte, die während eines Upgrades ausgeführt werden:

  • Mit dem Befehl bmctl upgrade cluster wird eine benutzerdefinierte PreflightCheck-Ressource erstellt.
  • Bei dieser Preflight-Prüfung werden zusätzliche Prüfungen zu Cluster-Upgrades sowie Netzwerk- und Knotensystemdiagnosen ausgeführt.
  • Die Ergebnisse dieser zusätzlichen Prüfungen werden zusammengeführt, um zu ermitteln, ob das Upgrade des Clusters auf die Zielversion erfolgreich durchgeführt werden kann.

Wenn die Preflight-Prüfungen erfolgreich sind und keine blockierenden Probleme auftreten, werden die Komponenten im Cluster in einer bestimmten Reihenfolge aktualisiert, wie im folgenden Diagramm dargestellt:

Die Load Balancer und Knotenpools der Steuerungsebene werden aktualisiert. Anschließend werden GKE Connect, Cluster-Add-ons, der Load Balancer-Knotenpool und die Worker-Knotenpools aktualisiert.

Im vorherigen Diagramm werden die Komponenten in der folgenden Reihenfolge aktualisiert:

  1. Zuerst wird das Feld spec.anthosBareMetalVersion aktualisiert.
  2. Die Load Balancer der Steuerungsebene werden aktualisiert.
  3. Der Knotenpool der Steuerungsebene wird aktualisiert.
  4. Parallel dazu werden GKE Connect, Cluster-Add-ons und der Load Balancer-Knotenpool aktualisiert.
    1. Nachdem der Load Balancer-Knotenpool erfolgreich aktualisiert wurde, werden die Worker-Knotenpools aktualisiert.

  5. Sobald alle Komponenten aktualisiert wurden, werden Cluster-Systemdiagnosen ausgeführt.

    Die Systemdiagnosen werden so lange ausgeführt, bis alle Prüfungen bestanden wurden.

  6. Wenn alle Systemdiagnosen bestanden wurden, ist das Upgrade abgeschlossen.

Jede Komponente hat ein eigenes Statusfeld in der benutzerdefinierten Clusterressource. In diesen Feldern können Sie den Status prüfen, um den Fortschritt des Upgrades zu verfolgen:

Sequenz Feldname Bedeutung
1 status.controlPlaneNodepoolStatus Der Status wird aus dem Knotenpoolstatus der Steuerungsebene kopiert. Das Feld enthält die Versionen der Knoten von Knotenpools der Steuerungsebene.
2 status.anthosBareMetalLifecycleControllersManifestsVersion Version von lifecycles-controllers-manager, die auf den Cluster angewendet wird. Dieses Feld ist nur für Administrator-, eigenständige oder Hybrid-Cluster verfügbar.
2 status.anthosBareMetalManifestsVersion Version des Clusters aus dem zuletzt angewendeten Manifest.
2 status.controlPlaneLoadBalancerNodepoolStatus Der Status wird aus dem Status des Load Balancer-Knotenpools der Steuerungsebene kopiert. Dieses Feld ist leer, wenn in Cluster.Spec kein separater Load Balancer für die Steuerungsebene angegeben ist.
3 status.anthosBareMetalVersions Eine aggregierte Versionszuordnung von Versionen zu Knotennummern.
4 status.anthosBareMetalVersion Endgültiger Status der aktualisierten Version.

Details zum Upgrade von Administrator-, Hybrid- und eigenständigen Clustern

Ab bmctl Version 1.15.0 ist das Standard-Upgradeverhalten für selbstverwaltete (Administrator-, Hybrid- oder eigenständige) Cluster ein direktes Upgrade. Wenn Sie also einen Cluster auf Version 1.15.0 oder höher aktualisieren, wird der gesamte Upgrade-Vorgang mithilfe von Lebenszykluscontrollern und nicht mit einem Bootstrap-Cluster verwaltet. Diese Änderung vereinfacht den Prozess und reduziert die Ressourcenanforderungen, wodurch Cluster-Upgrades zuverlässiger und skalierbarer werden.

Die Verwendung eines Bootstrap-Clusters für das Upgrade wird zwar nicht empfohlen, die Option ist aber weiterhin verfügbar. Wenn Sie beim Upgrade einen Bootstrap-Cluster verwenden möchten, führen Sie den Befehl bmctl upgrade mit dem Flag --use-bootstrap=true aus. Die Phasen des Upgrades unterscheiden sich je nach verwendeter Methode.

Direkte Upgrades

Das standardmäßige direkte Upgrade für selbstverwaltete Cluster ähnelt dem Upgrade-Prozess für Nutzercluster. Wenn Sie jedoch das direkte Upgrade verwenden, wird eine neue Version von preflightcheck-operator bereitgestellt, bevor die Preflight-Prüfung und die Systemdiagnosen des Clusters ausgeführt werden:

Eine neue Version des preflightcheck-Operators wird bereitgestellt, bevor die Preflight-Prüfung des Clusters zusätzliche Systemdiagnosen für den Cluster ausführt.

Wie beim Upgrade des Nutzerclusters beginnt der Upgrade-Vorgang damit, dass das Feld Cluster.spec.anthosBareMetalVersion auf die Zielversion aktualisiert wird. Bevor Komponenten aktualisiert werden, werden zwei zusätzliche Schritte ausgeführt, wie im folgenden Diagramm dargestellt: lifecycle-controller-manager wird auf die Zielversion aktualisiert und dann wird die Zielversion von anthos-cluster-operator bereitgestellt. anthos-cluster-operator führt die restlichen Schritte des Upgrade-Prozesses aus:

„lifecycle-controller-manager“ und „anthos-cluster-operator“ werden vor dem Upgrade des Rests des Clusters in derselben Reihenfolge wie die Komponenten im Nutzercluster bereitgestellt.

Bei Erfolg gleicht anthos-cluster-operator die Zielversion von spec.anthosBareMetalVersion mit status.anthosBareMetalVersion ab.

Upgrade mit einem Bootstrap-Cluster

Das Upgrade eines Administrator-, Hybrid- oder eigenständigen Clusters ähnelt dem eines Nutzerclusters, das im vorherigen Abschnitt beschrieben wurde.

Der Hauptunterschied besteht darin, dass der Befehl bmctl upgrade cluster einen Prozess zum Erstellen eines Bootstrap-Clusters startet. Dieser Bootstrap-Cluster ist ein temporärer Cluster, der den Hybrid-, Administrator- oder eigenständigen Cluster während eines Upgrades verwaltet.

Die Übertragung der Verwaltungseigentümerschaft des Clusters an den Bootstrap-Cluster wird als Pivot bezeichnet. Der Rest des Upgrades entspricht dem Upgrade des Nutzerclusters.

Während des Upgrades bleiben die Ressourcen im Zielcluster unverändert. Der Fortschritt des Upgrades wird nur in den Ressourcen des Bootstrap-Clusters angezeigt.

Bei Bedarf können Sie auf den Bootstrap-Cluster zugreifen, um den Upgrade-Vorgang zu überwachen und Fehler zu beheben. Auf den Bootstrap-Cluster kann über bmctl-workspace/.kindkubeconfig zugegriffen werden.

Um die Verwaltungseigentümerschaft des Clusters nach Abschluss des Upgrades wieder zu übertragen, werden die Ressourcen vom Bootstrap-Cluster in den aktualisierten Cluster verschoben. Während des Upgrades müssen Sie den Cluster nicht manuell umstellen. Der Bootstrap-Cluster wird gelöscht, nachdem das Cluster-Upgrade erfolgreich abgeschlossen wurde.

Knoten per Drain beenden

Cluster-Upgrades in Google Distributed Cloud können zu Anwendungsstörungen führen, da die Knoten per Drain beendet werden. Bei diesem Vorgang werden alle Pods, die auf einem Knoten ausgeführt werden, heruntergefahren und auf den verbleibenden Knoten im Cluster neu gestartet.

Bereitstellungen können verwendet werden, um solche Störungen aufzufangen. Bei einer Bereitstellung kann angegeben werden, dass mehrere Replikate einer Anwendung oder eines Diensts ausgeführt werden sollen. Bei einer Anwendung mit mehreren Replikaten sollte es während Upgrades nur zu geringen oder gar keinen Störungen kommen.

PodDisruptionBudgets (PDBs)

Wenn Sie einen Cluster aktualisieren, verwendet Google Distributed Cloud den Ablauf für den Wartungsmodus, um Knoten zu entlasten.

Ab Version 1.29 werden Knoten mit der Eviction API per Drain beendet, die PodDisruptionBudgets (PDBs) berücksichtigt. Mit PDBs kann sichergestellt werden, dass unter normalen Betriebsbedingungen immer eine bestimmte Anzahl von Replikaten im Cluster ausgeführt wird. Mit PDBs können Sie die Störung auf eine Arbeitslast beschränken, wenn ihre Pods neu geplant werden müssen. Das bereinigungsbasierte Beenden von Knoten per Drain ist in Version 1.29 als GA verfügbar.

In Version 1.28 und niedriger werden in Google Distributed Cloud keine PDBs berücksichtigt, wenn Knoten während eines Upgrades per Drain beendet werden. Stattdessen wird der Vorgang nach dem Best-Effort-Prinzip durchgeführt. Einige Pods bleiben möglicherweise im Status Terminating hängen und verlassen den Knoten nicht. Das Upgrade wird fortgesetzt, auch wenn Pods hängen bleiben, wenn der Vorgang zum Beenden eines Knotens per Drain mehr als 20 Minuten dauert.

Weitere Informationen finden Sie unter Knoten in den Wartungsmodus versetzen.

Nächste Schritte