Best Practices für Google Distributed Cloud-Clusterupgrades

In diesem Dokument werden Best Practices und Überlegungen für das Upgrade von Google Distributed Cloud beschrieben. Sie erfahren, wie Sie sich auf Clusterupgrades vorbereiten und welche Best Practices Sie vor dem Upgrade befolgen sollten. Diese Best Practices helfen, die mit Clusterupgrades verbundenen Risiken zu reduzieren.

Wenn Sie mehrere Umgebungen wie test, development und production haben, empfehlen wir, mit der am wenigsten kritischen Umgebung, z. B. test, zu beginnen und die Upgradefunktionalität zu prüfen. Nachdem Sie überprüft haben, ob das Upgrade erfolgreich war, fahren Sie mit der nächsten Umgebung fort. Wiederholen Sie diesen Vorgang, bis Sie ein Upgrade Ihrer Produktionsumgebungen durchführen. Mit diesem Ansatz können Sie von einem kritischen Punkt zum nächsten wechseln und prüfen, ob das Upgrade und Ihre Arbeitslasten korrekt ausgeführt werden.

Checkliste für die Umstellung

Wir empfehlen Ihnen, alle in diesem Dokument beschriebenen Best Practices zu befolgen. Verwenden Sie die folgende Checkliste, um Ihren Fortschritt zu verfolgen. Jedes Element in der Liste ist mit einem Abschnitt in diesem Dokument mit weiteren Informationen verknüpft:

Wenn 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 störend sein. Bevor Sie mit dem Upgrade beginnen, sollten Sie sorgfältig planen, ob Ihre Umgebung und Anwendungen bereit und vorbereitet sind.

Den Zeitaufwand schätzen und ein Wartungsfenster planen

Die Zeit für das Upgrade eines Clusters hängt von der Anzahl der Knoten und der darauf ausgeführten Arbeitslastdichte ab. Verwenden Sie ein Wartungsfenster mit genügend Zeit, um ein Clusterupgrade erfolgreich abzuschließen.

Verwenden Sie 10 minutes * the number of nodes für das Upgrade eines einzelnen gleichzeitigen Knotens, um eine grobe Schätzung für das Upgrade zu berechnen.

Wenn Sie beispielsweise 50 Knoten in einem Cluster haben, beträgt die gesamte Upgradezeit 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, prüfen Sie vor und nach dem Upgrade den Support für GKE Enterprise-Versionen und -Upgrades und prüfen Sie die unterstützten Versionen mit Google Distributed Cloud.

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

Auslastung der Clusterressourcen prüfen

Prüfen Sie die aktuelle Ressourcennutzung des Clusters, damit Pods evakuiert werden können, wenn der Knoten entleert wird, und dass der Cluster, der aktualisiert wird, genügend Ressourcen enthält, 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 Nutzung der Clusterressourcen abzurufen. Dashboards bieten jedoch eine detailliertere Ansicht der im Laufe der Zeit verbrauchten Ressourcen. Anhand dieser Ressourcennutzungsdaten können Sie ermitteln, wann ein Upgrade je nach ausgeführter Arbeitslast und Anwendungsfällen die geringste Störung verursachen würde, z. B. an Wochenenden oder Abenden.

Der Zeitpunkt für das Upgrade des Administratorclusters ist möglicherweise weniger wichtig als für die Nutzercluster, da ein Administratorclusterupgrade in der Regel keine Anwendungsausfallzeit zur Folge hat. Es ist jedoch weiterhin wichtig, die verfügbaren Ressourcen zu prüfen, bevor Sie mit dem Upgrade eines Administratorclusters beginnen. Außerdem kann ein Upgrade des Administratorclusters ein gewisses Risiko mit sich bringen. Daher wird es möglicherweise zu Zeiten mit geringerer Aktivität empfohlen, in denen 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. Der Upgradeprozess erfordert in der Regel 1.000 Millicore CPU (1.000 mCPU) und 2–3 GiB RAM für jeden Satz von Lebenszyklus-Controllern. Beachten Sie, dass die CPU-Einheit „mCPU“ für „Tausendstel eines Kerns“ steht. 1.000 Millicore entsprechen also einem Kern auf jedem Knoten und jeder Gruppe von Lebenszyklus-Controllern. Wenn Sie die zusätzlichen Rechenressourcen reduzieren möchten, die während eines Upgrades erforderlich sind, versuchen Sie, Nutzercluster auf derselben Version zu halten.

Im 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

Eine Reihe von Lebenszyklus-Controllern wird im Admin-Controller für jede verwendete Version bereitgestellt. In diesem Beispiel gibt es drei Gruppen von Lebenszyklus-Controllern: 1.13.3, 1.13.0 und 1.13.2. Jeder Satz Lebenszyklus-Controller 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 Gruppen 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 alle in 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 Lebenszyklus-Controller, die insgesamt 1.000 mCPU und 3 GiB RAM nutzen.

Im folgenden Beispiel haben alle Nutzercluster dieselbe Version. Wenn der Administratorcluster aktualisiert wird, werden nur zwei Gruppen von Lebenszyklus-Controllern verwendet, um den Verbrauch der Rechenressourcen zu reduzieren:

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, werden möglicherweise Pods wie anthos-cluster-operator, capi-controller-manager, cap-controller-manager oder cap-kubeadm-bootstraper im Status Pending angezeigt. Um dieses Problem zu lösen, führen Sie ein Upgrade einiger Nutzercluster auf dieselbe Version durch, 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 auch kubectl edit deployment verwenden, um die ausstehenden Deployments zu bearbeiten, um die CPU- und RAM-Anfragen zu reduzieren, sodass sie in die Steuerungsebene des Administratorclusters passen.

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

Cluster Erforderliche Administratorclusterressourcen
Nutzerclusterupgrade 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 upgraden (mit Nutzercluster) 1.000 mCPU und 3 GiB RAM
Hybrid-Clusterupgrade (ohne Nutzercluster) 1.000 mCPU und 3 GiB RAM. Ressourcen werden nach der Verwendung zurückgegeben.
Eigenständig 200 mCPU und 1 GiB RAM. Ressourcen werden nach der Verwendung zurückgegeben.

Cluster sichern

Bevor Sie ein Upgrade starten, sichern Sie Cluster mit dem Befehl bmctl backup cluster.

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

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

Führen Sie bmctl check cluster auf dem Cluster aus, um den Status eines Clusters vor einem Upgrade zu prüfen. Der Befehl führt erweiterte Prüfungen aus, z. B. um Knoten zu identifizieren, die nicht richtig konfiguriert sind oder Pods enthalten, die sich nicht im Status befinden.

Wenn Sie den Befehl bmctl upgrade cluster ausführen, um Ihre Cluster zu aktualisieren, werden einige Preflight-Prüfungen ausgeführt. Wenn diese Prüfungen nicht erfolgreich sind, wird der Upgradeprozess beendet. Es empfiehlt sich, diese Probleme proaktiv mit dem Befehl bmctl check cluster zu identifizieren und zu beheben, anstatt sich auf die vorhandenen Preflight-Prüfungen zu verlassen, die Cluster vor möglichen Schäden schützen.

Bereitstellungen von Nutzerarbeitslasten prüfen

Bei Nutzerarbeitslasten gibt es zwei Bereiche: Draining und API-Kompatibilität.

Arbeitslastausgleich

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

Um ein hängen gebliebenes Upgrade zu vermeiden, werden beim Draining-Prozess für ein Upgrade auf bis zu 1,29 keine Budgets für Pod-Störungen (PDBs) berücksichtigt. Arbeitslasten werden möglicherweise in einem eingeschränkten Zustand ausgeführt. Das Replikat mit der geringsten Bereitstellung ist total replica number - concurrent upgrade number.

API-Kompatibilität

Prüfen Sie im Hinblick auf die API-Kompatibilität die Kompatibilität der Arbeitslast-API mit neuerer Nebenversion von Kubernetes, wenn Sie ein Nebenversionsupgrade durchführen. Führen Sie bei Bedarf ein Upgrade der Arbeitslast auf eine kompatible Version durch. Wenn möglich, erhalten Sie vom GKE Enterprise-Entwicklungsteam eine Anleitung zum Identifizieren von Arbeitslasten mit inkompatiblen APIs, z. B. entfernten 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 Versionskompatibilität von GKE Enterprise-Komponenten finden Sie unter Support zu GKE Enterprise-Versionen und -Upgrades.

Verwendung von Webhooks prüfen

Prüfen Sie, ob der Cluster Webhooks enthält, insbesondere Pod-Ressourcen für Prüfzwecke wie Policy Controller. Der Ausgleichsprozess während des Clusterupgrades kann zu einer Unterbrechung des Policy Controller-Webhook-Dienstes führen, wodurch das Upgrade hängen bleibt oder lange dauert. Wir empfehlen, diese Webhooks vorübergehend zu deaktivieren oder eine hochverfügbare Bereitstellung zu verwenden.

Verwendung von Vorschaufunktionen prüfen

Die Vorschaufunktionen können sich ändern und werden nur zu Test- und Bewertungszwecken bereitgestellt. Verwenden Sie keine Vorschaufunktionen in Ihren Produktionsclustern. Wir können nicht garantieren, 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. Ab Google Distributed Cloud-Release 1.9.0 oder höher können Sie SELinux vor oder nach der Clustererstellung oder Clusterupgrades aktivieren oder deaktivieren. SELinux ist in 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 maximalen 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.

Knoten der Steuerungsebene und des Load-Balancers dürfen sich nicht im Wartungsmodus befinden

Achten Sie darauf, dass die Knoten der Steuerungsebene und des Load-Balancers nicht gewartet werden, bevor Sie ein Upgrade starten. 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