Best Practices für Cluster-Upgrades in der Google Distributed Cloud

In diesem Dokument werden Best Practices und Überlegungen für das Upgrade von Google Distributed Cloud beschrieben. Sie erfahren, wie Sie sich auf Cluster-Upgrades vorbereiten und welche Best Practices Sie vor dem Upgrade beachten sollten. Mit diesen Best Practices lassen sich die mit Cluster-Upgrades verbundenen Risiken reduzieren.

Wenn Sie mehrere Umgebungen wie Test, Entwicklung und Produktion haben, empfehlen wir Ihnen, mit der am wenigsten kritischen Umgebung zu beginnen, z. B. Test, und die Funktion des Upgrades zu prüfen. Nachdem Sie bestätigt haben, dass das Upgrade erfolgreich war, fahren Sie mit der nächsten Umgebung fort. Wiederholen Sie diesen Vorgang, bis Sie Ihre Produktionsumgebungen aktualisiert haben. So können Sie von einem kritischen Punkt zum nächsten übergehen und prüfen, ob das Upgrade und Ihre Arbeitslasten ordnungsgemäß ausgeführt werden.

Checkliste für Upgrades

Wir empfehlen, alle Best Practices in diesem Dokument zu befolgen. Mit der folgenden Checkliste können Sie Ihre Fortschritte im Blick behalten. Jeder Eintrag in der Liste ist mit einem Abschnitt in diesem Dokument verknüpft, in dem weitere Informationen zu finden sind:

Sobald diese Prüfungen abgeschlossen sind, können Sie mit dem Upgrade fortfahren. Beobachten Sie den Fortschritt, bis alle Cluster erfolgreich aktualisiert wurden.

Upgrade planen

Updates können zu Unterbrechungen führen. Bevor Sie mit dem Upgrade beginnen, ist vorab eine sorgfältige Planung erforderlich, damit Ihre Umgebung und Anwendungen bereit sind.

Zeitaufwand schätzen und Wartungsfenster planen

Die Dauer des Upgrades eines Clusters hängt von der Anzahl der Knoten und der Arbeitslastdichte ab, die auf ihnen ausgeführt wird. Verwenden Sie ein Wartungsfenster mit ausreichend Zeit, um ein Cluster-Upgrade erfolgreich abzuschließen.

Um eine grobe Schätzung für das Upgrade zu berechnen, verwenden Sie 10 minutes * the number of nodes für ein einzelnes gleichzeitiges Knoten-Upgrade.

Wenn Sie beispielsweise 50 Knoten in einem Cluster haben, beträgt die Gesamtzeit für das Upgrade etwa 500 Minuten: 10 minutes * 50 nodes = 500 minutes.

Kompatibilität anderer GKE Enterprise-Komponenten prüfen

Wenn in Ihrem Cluster GKE Enterprise-Komponenten wie Cloud Service Mesh, Config Sync, Policy Controller oder Config Controller ausgeführt werden, lesen Sie den Hilfeartikel Unterstützung für GKE Enterprise-Versionen und ‑Upgrades und prüfen Sie vor und nach dem Upgrade, ob die unterstützten Versionen mit Google Distributed Cloud kompatibel sind.

Die Kompatibilitätsprüfung basiert auf dem Administrator- oder Nutzercluster, in dem Cloud Service Mesh, Config Sync, Policy Controller oder Config Controller bereitgestellt wird.

Clusterressourcenauslastung prüfen

Prüfen Sie die aktuelle Ressourcennutzung des Clusters, um sicherzustellen, dass Pods evakuiert werden können, wenn der Knoten per Drain beendet ist, und dass im Cluster, der aktualisiert wird, genügend Ressourcen vorhanden sind, um das Upgrade zu verwalten. Verwenden Sie die benutzerdefinierten Dashboards in Google Cloud Observability, um die Ressourcennutzung für Ihren Cluster zu prüfen.

Sie können Befehle wie kubectl top nodes verwenden, um die aktuelle Ressourcennutzung des Clusters abzurufen. Dashboards können jedoch eine detailliertere Übersicht über die im Laufe der Zeit verbrauchten Ressourcen bieten. Anhand dieser Daten zur Ressourcennutzung lässt sich ermitteln, wann ein Upgrade die geringsten Unterbrechungen verursacht, z. B. an Wochenenden oder abends, je nach laufender Arbeitslast und Anwendungsfällen.

Der Zeitpunkt für das Upgrade des Administratorclusters ist möglicherweise weniger kritisch als für die Nutzercluster, da ein Upgrade des Administratorclusters in der Regel keine Anwendungsausfallzeiten verursacht. Es ist jedoch wichtig, nach verfügbaren Ressourcen zu suchen, bevor Sie mit dem Upgrade eines Administratorclusters beginnen. Außerdem kann das Upgrade des Administratorclusters ein gewisses Risiko bergen. Daher wird empfohlen, es in Zeiten mit geringerer Nutzung durchzuführen, wenn der Verwaltungszugriff auf den Cluster weniger kritisch ist.

Ressourcen der Steuerungsebene des Administratorclusters

Alle Upgrade-Controller und ‑Jobs werden auf den Knoten der Steuerungsebene des Administratorclusters ausgeführt. Prüfen Sie den Ressourcenverbrauch dieser Steuerungsebenenknoten auf verfügbare Rechenressourcen. Für das Upgrade werden in der Regel 1.000 Millicore CPU (1.000 mCPU) und 2–3 GiB RAM für jeden Satz von Lebenszykluscontrollern benötigt. Die CPU-Einheit „mCPU“ steht für „tausendstel eines Kerns“. 1.000 Millicore entsprechen also einem Kern auf jedem Knoten für jeden Satz von Lebenszykluscontrollern. Um die zusätzlichen Rechenressourcen zu reduzieren, die bei einem Upgrade erforderlich sind, sollten Sie die Nutzercluster auf derselben Version belassen.

In der folgenden Beispielbereitstellung haben die beiden Nutzercluster unterschiedliche Versionen als der Administratorcluster:

Administratorcluster Nutzercluster 1 Nutzercluster 2
1.13.3 1.13.0 1.13.2

Für jede verwendete Version werden im Administratorcontroller eine Reihe von Lebenszykluscontrollern bereitgestellt. In diesem Beispiel gibt es drei Lebenszykluscontroller: 1.13.3, 1.13.0 und 1.13.2. Jeder Satz von Lebenszykluscontrollern verbraucht insgesamt 1.000 mCPU und 3 GiB RAM. Der aktuelle Gesamtressourcenverbrauch dieser Lebenszykluscontroller beträgt 3.000 mCPU und 9 GiB RAM.

Wenn Nutzercluster 2 auf 1.13.3 umgestellt wird, gibt es jetzt zwei Lebenszykluscontroller: 1.13.3 und 1.13.0:

Administratorcluster Nutzercluster 1 Nutzercluster 2
1.13.3 1.13.0 1.13.3

Die Lebenszykluscontroller verbrauchen jetzt insgesamt 2.000 mCPU und 6 GiB RAM.

Wenn Nutzercluster 1 auf 1.13.3 aktualisiert wird, wird die gesamte Flotte jetzt mit derselben Version ausgeführt: 1.13.3:

Administratorcluster Nutzercluster 1 Nutzercluster 2
1.13.3 1.13.3 1.13.3

Es gibt jetzt nur noch einen Satz von Lebenszykluscontrollern, die insgesamt 1.000 mCPU und 3 GiB RAM verbrauchen.

Im folgenden Beispiel haben alle Nutzercluster dieselbe Version. Wenn der Administratorcluster aktualisiert wird, werden nur zwei Lebenszykluscontroller verwendet, wodurch der Verbrauch von Rechenressourcen reduziert wird:

Administratorcluster Nutzercluster 1 Nutzercluster 2
1.14.0 1.13.3 1.13.3

In diesem Beispiel verbrauchen die Lebenszykluscontroller wieder insgesamt 2.000 mCPU und 6 GiB RAM, bis alle Nutzercluster auf dieselbe Version wie der Administratorcluster aktualisiert wurden.

Wenn die Knoten der Kontrollebene während des Upgrades keine zusätzlichen Rechenressourcen haben, sehen Sie möglicherweise Pods wie anthos-cluster-operator, capi-controller-manager, cap-controller-manager oder cap-kubeadm-bootstraper im Zustand Pending. Aktualisieren Sie einige der Nutzercluster auf dieselbe Version, um die Versionen zu konsolidieren und die Anzahl der verwendeten Lebenszykluscontroller zu reduzieren. Wenn das Upgrade bereits ins Stocken geraten ist, können Sie die ausstehenden Bereitstellungen auch mit kubectl edit deployment bearbeiten, um die CPU- und RAM-Anfragen so zu senken, dass sie in die Steuerungsebene des Administratorclusters passen.

In der folgenden Tabelle sind die Anforderungen an die Rechenressourcen für verschiedene Upgrade-Szenarien aufgeführt:

Cluster Erforderliche Ressourcen für Administratorcluster
Nutzercluster-Upgrade Upgrade auf dieselbe Version anderer Cluster: –

Upgrade auf eine andere Version anderer Administrator- oder Nutzercluster: 1.000 mCPU und 3 GiB RAM

Nutzercluster in einem Hybridcluster haben dieselben Ressourcenanforderungen.
Administratorcluster-Upgrade (mit Nutzercluster) 1.000 mCPU und 3 GiB RAM
Hybridcluster-Upgrade (ohne Nutzercluster) 1000 mCPU and 3 GiB RAM-Surge. Ressourcen werden nach der Verwendung zurückgegeben.
Eigenständig 200 mCPU und 1 GiB RAM-Surge. Ressourcen werden nach der Verwendung zurückgegeben.

Cluster sichern

Sichern Sie Ihre Cluster mit dem Befehl bmctl backup cluster, bevor Sie mit dem Upgrade beginnen.

Da die Sicherungsdatei vertrauliche Informationen enthält, sollten Sie sie an einem sicheren Ort speichern.

Prüfen, ob Cluster konfiguriert sind und ordnungsgemäß funktionieren

Wenn Sie den Zustand eines Clusters vor einem Upgrade prüfen möchten, führen Sie bmctl check cluster auf dem Cluster aus. Der Befehl führt erweiterte Prüfungen durch, z. B. um Knoten zu identifizieren, die nicht richtig konfiguriert sind, oder Pods, die feststecken.

Wenn Sie den Befehl bmctl upgrade cluster zum Upgrade Ihrer Cluster ausführen, werden einige Preflight-Prüfungen ausgeführt. Wenn diese Prüfungen nicht erfolgreich sind, wird der Upgradevorgang beendet. Es ist am besten, diese Probleme proaktiv mit dem Befehl bmctl check cluster zu erkennen und zu beheben, anstatt sich auf die Preflight-Prüfungen zu verlassen, die Cluster vor möglichen Schäden schützen sollen.

Bereitstellungen von Nutzerarbeitslasten prüfen

Bei Nutzerlasten sind zwei Aspekte zu berücksichtigen: Entleerung und API-Kompatibilität.

Arbeitslastentleerung

Die Nutzerarbeitslast auf einem Knoten wird während eines Upgrades aufgebraucht. Wenn die Arbeitslast nur ein Replikat hat oder sich alle Replikate auf demselben Knoten befinden, kann das Entleeren der Arbeitslast zu Unterbrechungen bei den im Cluster ausgeführten Diensten führen. Führen Sie Ihre Arbeitslasten mit mehreren Replikaten aus. Die Anzahl der Replikate sollte über der Anzahl der gleichzeitigen Knoten liegen.

Um ein steckengebliebenes Upgrade zu vermeiden, wird beim Entfernen von Ressourcen für das Upgrade auf Version 1.31 kein Budget für Pod-Störungen (PDBs) berücksichtigt. Arbeitslasten werden möglicherweise in einem eingeschränkten Zustand ausgeführt und das Replik, das am wenigsten Anfragen verarbeitet, ist total replica number - concurrent upgrade number.

API-Kompatibilität

Prüfen Sie bei einem Upgrade auf eine neuere Nebenversion von Kubernetes, ob die API Ihrer Arbeitslast mit dieser Version kompatibel ist. Führen Sie bei Bedarf ein Upgrade der Arbeitslast auf eine kompatible Version durch. Nach Möglichkeit stellt das GKE Enterprise-Entwicklerteam eine Anleitung zum Identifizieren von Arbeitslasten bereit, die inkompatible APIs verwenden, z. B. entfernte Kubernetes APIs.

Wenn Sie Cloud Service Mesh, Config Sync, Policy Controller, Config Controller oder andere GKE Enterprise-Komponenten verwenden, prüfen Sie, ob die installierte Version mit der neuen Version von Google Distributed Cloud kompatibel ist. Informationen zur Kompatibilität der GKE Enterprise-Komponentenversion finden Sie unter Unterstützung für GKE Enterprise-Versionen und ‑Upgrades.

Nutzung von Webhooks prüfen

Prüfen Sie, ob Ihr Cluster Webhooks hat, insbesondere Pod-Ressourcen für Prüfzwecke wie Policy Controller. Der beim Upgrade des Clusters stattfindende Leerungsprozess kann den Policy Controller Webhook-Dienst unterbrechen, was dazu führen kann, dass das Upgrade stecken bleibt oder sehr lange dauert. Wir empfehlen, diese Webhooks vorübergehend zu deaktivieren oder eine hochverfügbare Bereitstellung (High Availability, HA) zu verwenden.

Informationen zur Verwendung von Vorabversionen

Die Vorschaufunktionen können sich ändern und werden nur zu Test- und Bewertungszwecken bereitgestellt. Verwenden Sie keine Vorabversionen in Produktionsclustern. Es wird nicht garantiert, dass Cluster, die Vorabversionen verwenden, aktualisiert werden können. In einigen Fällen werden Upgrades für Cluster, die Vorschaufunktionen verwenden, explizit blockiert.

Informationen zu funktionsgefährdenden Änderungen im Zusammenhang mit dem Upgraden finden Sie in den Versionshinweisen.

SELinux-Status prüfen

Wenn Sie SELinux zum Schutz Ihrer Container aktivieren möchten, müssen Sie darauf achten, dass SELinux auf allen Hostcomputern im Enforced-Modus aktiviert ist. Beginnend mit Google Distributed Cloud Release 1.9.0 oder höher können Sie SELinux vor oder nach Clustererstellung oder Clusterupgrades aktivieren oder deaktivieren. SELinux ist unter Red Hat Enterprise Linux (RHEL) standardmäßig aktiviert. Wenn SELinux auf Ihren Hostcomputern deaktiviert ist oder Sie sich nicht sicher sind, finden Sie unter Container mit SELinux sichern Informationen zur Aktivierung.

Google Distributed Cloud unterstützt SELinux nur in RHEL-Systemen.

Konfiguration der Pod-Dichte nicht ändern

Google Distributed Cloud unterstützt die Konfiguration von bis zu 250 Pods pro Knoten mit nodeConfig.PodDensity.MaxPodsPerNode. Sie können die Pod-Dichte nur während der Clustererstellung konfigurieren. Sie können die Einstellungen für die Pod-Dichte nicht für vorhandene Cluster aktualisieren. Versuchen Sie nicht, die Konfiguration der Poddichte während eines Upgrades zu ändern.

Achten Sie darauf, dass sich die Knoten der Steuerungsebene und des Load Balancers nicht im Wartungsmodus befinden.

Achten Sie darauf, dass die Knoten der Steuerungsebene und des Load Balancers nicht gerade gewartet werden, bevor Sie mit dem Upgrade beginnen. Wenn sich ein Knoten im Wartungsmodus befindet, wird das Upgrade pausiert, um sicherzustellen, dass die Knotenpools der Steuerungsebene und des Load Balancers ausreichend verfügbar sind.

Nächste Schritte