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 lernen, wie Sie sich auf Clusterupgrades vorbereiten, und welche Best Practices Sie vor dem Upgrade beachten sollten. Diese Best Practices helfen, die mit Clusterupgrades verbundenen Risiken zu reduzieren.

Wenn Sie mehrere Umgebungen haben, z. B. Test, Entwicklung und Produktion, empfehlen wir, mit der am wenigsten kritischen Umgebung zu beginnen, z. B. Test, und prüfen die Upgradefunktionalität. Nachdem Sie geprü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 durchgeführt haben. Auf diese Weise können Sie von einem kritischen Punkt zum nächsten übergehen und prüfen, ob das Upgrade und Ihre Arbeitslasten korrekt ausgeführt werden.

Checkliste für die Umstellung

Wir empfehlen, alle Best Practices in diesem Dokument 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:

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 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

Wie lange das Upgrade eines Clusters dauert, hängt von der Anzahl der Knoten und der Arbeitslastdichte ab, die auf ihnen ausgeführt wird. Nutzen Sie ein ausreichend langes Wartungsfenster, um ein Clusterupgrade erfolgreich abzuschließen.

Verwenden Sie 10 minutes * the number of nodes für das Upgrade einzelner gleichzeitiger Knoten, um eine grobe Schätzung für das Upgrade zu berechnen.

Wenn sich in einem Cluster beispielsweise 50 Knoten befinden, beträgt die gesamte Upgradezeit etwa fünfhundert Minuten: 10 minutes * 50 nodes = 500 minutes.

Kompatibilität anderer GKE Enterprise-Komponenten prüfen

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

Die Kompatibilitätsprüfung basiert auf dem Administrator- oder Nutzercluster, in dem Anthos 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 sich im Cluster, der aktualisiert wird, genügend Ressourcen für das Upgrade haben. Verwenden Sie die benutzerdefinierten Dashboards in Google Cloud-Beobachtbarkeit, 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 können jedoch eine detailliertere Ansicht der im Laufe der Zeit verbrauchten Ressourcen liefern. Diese Daten zur Ressourcennutzung können Ihnen Aufschluss darüber geben, wann ein Upgrade die geringste Unterbrechung verursachen würde, z. B. an Wochenenden oder Abenden, abhängig von der ausgeführten Arbeitslast und den 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 normalerweise nicht zu Ausfallzeiten der Anwendung führt. Sie sollten jedoch trotzdem unbedingt prüfen, ob verfügbare Ressourcen verfügbar sind, bevor Sie mit dem Upgrade des Administratorclusters beginnen. Außerdem kann ein Upgrade des Administratorclusters ein gewisses Risiko mit sich bringen. Daher wird es möglicherweise empfohlen, wenn der Verwaltungszugriff auf den Cluster weniger kritisch ist, wenn die Nutzung weniger aktiv 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 Upgradeprozess sind in der Regel 1.000 Millicore CPU (1.000 mCPU) und 2–3 GiB RAM für die einzelnen Lebenszyklus-Controller erforderlich. Die CPU-Einheit „mCPU“ steht für „Tausendstel eines Kerns“. 1.000 Millicore entsprechen also einem Kern auf jedem Knoten für jede Gruppe von Lebenszyklus-Controllern. Versuchen Sie, die Nutzercluster auf derselben Version zu belassen, um die während eines Upgrades erforderlichen zusätzlichen Rechenressourcen zu reduzieren.

Im folgenden Beispielbereitstellung befinden sich die beiden Nutzercluster in verschiedenen 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 eine Reihe von Lebenszyklus-Controllern bereitgestellt. In diesem Beispiel gibt es drei Gruppen von Lebenszyklus-Controllern: 1.13.3, 1.13.0 und 1.13.2. Jeder Satz der Lebenszyklus-Controller benötigt insgesamt 1.000 mCPU und 3 GiB RAM. Der aktuelle Ressourcenverbrauch dieser Lebenszyklus-Controller beträgt derzeit 3.000 mCPU und 9 GiB RAM.

Wenn Nutzercluster 2 auf 1.13.3 aktualisiert wird, sind jetzt zwei Gruppen von Lebenszyklus-Controllern vorhanden: 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 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 Gruppen von Lebenszyklus-Controllern verwendet, wodurch die Nutzung 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 werden.

Wenn die Knoten der Steuerungsebene während des Upgrades keine zusätzlichen Rechenressourcen haben, werden Pods wie anthos-cluster-operator, capi-controller-manager, cap-controller-manager oder cap-kubeadm-bootstraper möglicherweise im Status Pending angezeigt. Zum Beheben dieses Problems 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 die ausstehenden Bereitstellungen auch mit kubectl edit deployment 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 Administratorcluster-Ressourcen erforderlich
Nutzerclusterupgrade Upgrade auf dieselbe Version anderer Cluster: nicht verfügbar

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

Nutzercluster in einem Hybridcluster haben dieselben Ressourcenanforderungen.
Administratorclusterupgrade (mit Nutzercluster) 1.000 mCPU und 3 GiB RAM
Hybridclusterupgrade (ohne Nutzercluster) 1.000 mCPU und 3 GiB RAM zu viel. Ressourcen werden nach ihrer Verwendung zurückgegeben.
Eigenständig 200 mCPU und 1 GiB RAM zu viel. Ressourcen werden nach ihrer Verwendung zurückgegeben.

Cluster sichern

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

Da die Sicherungsdatei vertrauliche Informationen enthält, sollten Sie die Sicherungsdatei 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. Mit dem Befehl werden erweiterte Prüfungen ausgeführt, z. B. um Knoten zu identifizieren, die nicht ordnungsgemäß konfiguriert sind oder bei denen Pods hängen geblieben sind.

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 Upgradeprozess beendet. Wir empfehlen, diese Probleme proaktiv mit dem Befehl bmctl check cluster zu identifizieren und zu beheben, statt sich auf die Preflight-Prüfungen zu verlassen, die zum Schutz von Clustern vor möglichen Schäden vorhanden sind.

Arbeitslastbereitstellungen von Nutzern überprüfen

Für Nutzerarbeitslasten sind zwei Bereiche zu berücksichtigen: 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 der Arbeitslastausgleich zu Störungen der Dienste führen, die im Cluster ausgeführt werden. Sie können Ihre Arbeitslasten mit mehreren Replikaten ausführen. Die Replikatnummer muss über der Anzahl gleichzeitiger Knoten liegen.

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

API-Kompatibilität

Prüfen Sie die API-Kompatibilität der Arbeitslast-API mit einer neueren Nebenversion von Kubernetes, wenn Sie ein Upgrade der Nebenversion ausführen. Führen Sie bei Bedarf ein Upgrade der Arbeitslast auf eine kompatible Version durch. Das GKE Enterprise-Engineering-Team gibt nach Möglichkeit Anleitungen zum Identifizieren von Arbeitslasten, die inkompatible APIs wie entfernte Kubernetes APIs verwenden.

Wenn Sie Anthos 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 Unterstützung für GKE Enterprise-Versionen und -Upgrades.

Verwendung von Webhooks prüfen

Prüfen Sie, ob Ihr Cluster Webhooks enthält, insbesondere Pod-Ressourcen für Auditing-Zwecke wie Policy Controller. Der Draining-Prozess während des Clusterupgrades kann den Policy Controller-Webhook-Dienst unterbrechen. Dies kann dazu führen, dass 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 kennenlernen

Die Vorschaufunktionen können sich ändern und werden nur zu Test- und Bewertungszwecken bereitgestellt. Verwenden Sie in Ihren Produktionsclustern keine Vorschaufunktionen. 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 können Sie SELinux vor oder nach der 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 maximal 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 Steuerungsebene und die Load-Balancer-Knoten nicht im Wartungsmodus befinden

Achten Sie darauf, dass die Steuerungsebenen- und Load-Balancer-Knoten nicht gewartet werden, bevor Sie ein Upgrade starten. Wenn sich ein Knoten im Wartungsmodus befindet, wird das Upgrade pausiert, damit die Knotenpools der Steuerungsebene und des Load-Balancers ausreichend verfügbar sind.

Nächste Schritte