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. Verwenden Sie die folgende Checkliste, um Ihren Fortschritt zu verfolgen. Jeder Eintrag in der Liste verweist auf einen Abschnitt in diesem Dokument mit weiteren Informationen:

Nach Abschluss dieser Prüfungen können Sie mit dem Upgrade-Prozess beginnen. Behalten Sie den Fortschritt im Blick, 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 Zeit, die für das Upgrade eines Clusters benötigt wird, 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 Clusterupgrade 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 Knotenupgrade.

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 Google Cloud Produkte prüfen

Wenn auf Ihrem Cluster Cloud Service Mesh, Config Sync oder Policy Controller ausgeführt wird, prüfen Sie die Version und den Upgrade-Support und bestätigen Sie die unterstützten Versionen mit Google Distributed Cloud vor und nach dem Upgrade.

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

Ressourcennutzung des Clusters 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 bieten jedoch eine detailliertere Ansicht der im Zeitverlauf verbrauchten Ressourcen. 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 weiterhin wichtig, vor Beginn eines Administratorcluster-Upgrades nach verfügbaren Ressourcen zu suchen. 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 Knoten der Steuerungsebene auf verfügbare Rechenressourcen. Für den Upgrade-Prozess sind in der Regel 1.000 Millicore CPU (1.000 mCPU) und 2–3 GiB RAM für jeden Satz von Lebenszyklus-Controllern erforderlich. 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 Lebenszyklus-Controllern. Um die zusätzlichen Rechenressourcen zu reduzieren, die während eines Upgrades erforderlich sind, sollten Sie Nutzercluster auf derselben Version halten.

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

Administratorcluster Nutzercluster 1 Nutzercluster 2
1.13.3 1.13.0 1.13.2

Für jede verwendete Version wird ein Satz von Lebenszyklus-Controllern im Administratorcontroller bereitgestellt. In diesem Beispiel gibt es drei Sätze von Lebenszyklus-Controllern: 1.13.3, 1.13.0 und 1.13.2. Jeder Satz von Lebenszyklus-Controllern verbraucht insgesamt 1.000 mCPU und 3 GiB RAM. Der aktuelle Gesamtresourcenverbrauch dieser Lebenszyklus-Controller beträgt 3.000 mCPU und 9 GiB RAM.

Wenn Nutzercluster 2 auf 1.13.3 aktualisiert wird, gibt es jetzt zwei Sätze von Lebenszyklus-Controllern: 1.13.3 und 1.13.0:

Administratorcluster Nutzercluster 1 Nutzercluster 2
1.13.3 1.13.0 1.13.3

Die Lebenszyklus-Controller verbrauchen jetzt insgesamt 2.000 mCPU und 6 GiB RAM.

Wenn Nutzercluster 1 auf 1.13.3 aktualisiert wird, wird die 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 Lebenszyklus-Controllern, 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 Sätze von Lebenszyklus-Controllern verwendet, sodass 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 Lebenszyklus-Controller 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. Um dieses Problem zu beheben, aktualisieren Sie einige der Nutzercluster auf dieselbe Version, um die Versionen zu konsolidieren und die Anzahl der verwendeten Lebenszyklus-Controller zu reduzieren. Wenn Ihr Upgrade bereits stecken geblieben ist, können Sie auch kubectl edit deployment verwenden, um die ausstehenden Bereitstellungen zu bearbeiten und die CPU- und RAM-Anforderungen zu senken, damit sie in die Steuerungsebene des Administratorclusters passen.

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

Cluster Erforderliche Ressourcen des Administratorclusters
Nutzercluster-Upgrade Upgrade auf dieselbe Version anderer Cluster: Nicht zutreffend

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

Für Nutzercluster in einem Hybridcluster gelten dieselben Ressourcen anforderungen.
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 Cluster, bevor Sie mit dem Upgrade beginnen, mit dem Befehl bmctl backup cluster.

Da die Sicherungsdatei vertrauliche Informationen enthält, müssen Sie sie sicher speichern.

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

Führen Sie bmctl check cluster für den Cluster aus, um den Status eines Clusters vor einem Upgrade zu prüfen. 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 ausführen, um Ihre Cluster zu aktualisieren, werden einige Preflight-Prüfungen ausgeführt. Der Upgrade-Prozess wird beendet, wenn diese Prüfungen nicht erfolgreich sind. 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 entleert. 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.36 kein Budget für Pod-Störungen (PDBs) berücksichtigt. Arbeitslasten werden möglicherweise in einem beeinträchtigten Zustand ausgeführt. Das am wenigsten genutzte Replikat wäre total replica number - concurrent upgrade number.

API-Kompatibilität

Prüfen Sie bei einem Upgrade auf eine Nebenversion die API-Kompatibilität Ihrer Arbeitslast mit der neueren Nebenversion von Kubernetes. Aktualisieren Sie die Arbeitslast bei Bedarf auf eine kompatible Version. Das GKE-Entwicklungsteam stellt nach Möglichkeit eine Anleitung zur Identifizierung von Arbeitslasten bereit, die inkompatible APIs verwenden, z. B. entfernte Kubernetes APIs.

Wenn Sie Cloud Service Mesh, Config Sync oder Policy Controller verwenden, prüfen Sie, ob die installierte Version mit der neuen Version von Google Distributed Cloud kompatibel ist. Informationen zur Versionskompatibilität finden Sie unter Version und Upgrade-Support.

Nutzung von Webhooks prüfen

Prüfen Sie, ob Ihr Cluster Webhooks hat, insbesondere Pod-Ressourcen für Audit-Zwecke 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 Bereitstellung mit Hochverfügbarkeit (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 Vorschau-Features auf Ihren Produktionsclustern. Es wird nicht garantiert, dass Cluster, die Vorschaufunktionen 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 Pod-Dichte während eines Upgrades zu ändern.

Prüfen, ob sich Knoten der Steuerungsebene und Load-Balancer-Knoten nicht im Wartungsmodus befinden

Prüfen Sie, ob sich Knoten der Steuerungsebene und Load-Balancer-Knoten vor Beginn eines Upgrades nicht im Wartungsmodus befinden. Wenn sich ein Knoten im Wartungsmodus befindet, wird das Upgrade angehalten, um sicherzustellen, dass die Knotenpools der Steuerungsebene und des Load-Balancers ausreichend verfügbar sind.

Nächste Schritte