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

Mit strukturierten Best Practices für Upgrades für Google Distributed Cloud können Sie Dienstunterbrechungen minimieren und Betriebsrisiken reduzieren. Die Validierung vor dem Upgrade trägt dazu bei, dass Ihre Cluster und Arbeitslasten während des gesamten Versionsübergangs stabil bleiben.

Wenn Sie Umgebungen mit den Stufen Test, Entwicklung und Produktion haben, sollten Sie die Upgrades nacheinander durchführen und mit der am wenigsten kritischen Stufe beginnen. Wenn Sie den Clusterzustand und das Verhalten der Arbeitslast in jeder Phase prüfen, können Sie potenzielle Probleme erkennen, bevor Sie Produktionssysteme aktualisieren.

Checkliste für Upgrades

Wir empfehlen, alle Best Practices in diesem Dokument zu befolgen. Anhand der folgenden Checkliste können Sie Ihren Fortschritt verfolgen. Jeder Eintrag in der Liste ist mit einem Abschnitt in diesem Dokument verknüpft, der weitere Informationen enthält:

Nachdem diese Prüfungen abgeschlossen sind, können Sie mit dem Upgrade beginnen. 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 Clusterupgrades hängt von der Anzahl der Knoten und der Dichte der darauf ausgeführten Arbeitslasten ab. Verwenden Sie für ein erfolgreiches Clusterupgrade ein Wartungsfenster mit ausreichend Zeit.

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 Versions- und Upgrade-Unterstützung und 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.

Auslastung der Clusterressourcen 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. Sie können die Ressourcennutzung für Ihren Cluster mithilfe der benutzerdefinierten Dashboards in Google Cloud Observability prüfen.

Sie können Befehle wie kubectl top nodes verwenden, um die aktuelle Clusterressourcennutzung 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 weiterhin wichtig, vor dem Upgrade eines Administratorclusters 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 Upgradevorgang 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 Millikerne entsprechen also einem Kern auf jedem Knoten für jeden Satz von Lebenszyklus-Controllern. Wenn Sie die zusätzlichen Rechenressourcen minimieren möchten, die für Upgrades erforderlich sind, sollten Sie versuchen, die Nutzercluster auf derselben Version zu 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

Im Administrator-Controller wird für jede verwendete Version ein Satz von Lebenszyklus-Controllern 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 Gesamtressourcenverbrauch 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 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 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 Steuerungsebene 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 Lebenszyklus-Controller zu reduzieren. Wenn das Upgrade bereits hängen geblieben ist, können Sie mit kubectl edit deployment auch die ausstehenden Bereitstellungen bearbeiten, um die CPU- und RAM-Anfragen zu reduzieren, damit sie in die Steuerungsebene des Administratorclusters passen.

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

Cluster Erforderliche Administratorcluster-Ressourcen
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
Upgrade des Hybridclusters (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

Bevor Sie mit dem Upgrade beginnen, sichern Sie die Cluster mit dem Befehl bmctl backup cluster.

Da die Sicherungsdatei vertrauliche Informationen enthält, sollten Sie sie sicher speichern.

Prüfen, ob Cluster richtig konfiguriert sind und funktionieren

Führen Sie bmctl check cluster für den Cluster aus, um den Zustand 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 Upgradeprozess 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 per Drain beendet. 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 und das Replikat mit der geringsten Bereitstellung 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. Führen Sie bei Bedarf ein Upgrade der Arbeitslast auf eine kompatible Version durch. Nach Möglichkeit stellt das GKE-Engineering-Team Anleitungen 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 Unterstützung für 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 zu verwenden.

Informationen zur Verwendung von Funktionen in der Vorabversion

Die Vorschaufunktionen können sich ändern und werden nur zu Test- und Bewertungszwecken bereitgestellt. Verwenden Sie keine Funktionen in der Vorabversion auf Ihren Produktionsclustern. Es wird nicht garantiert, dass Cluster, die Funktionen in der Vorabversion verwenden, aktualisiert werden können. In einigen Fällen werden Upgrades für Cluster, die Funktionen in der Vorabversion 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.

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 vor dem Start eines Upgrades nicht gewartet werden. 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