Best Practices für GKE on Bare Metal-Clusterupgrades

In diesem Dokument werden Best Practices und Überlegungen für das Upgrade von GKE on Bare Metal beschrieben. Sie erfahren, wie Sie sich auf Clusterupgrades vorbereiten, und welche Best Practices Sie vor dem Upgrade beachten sollten. Diese Best Practices helfen, die mit Clusterupgrades einhergehenden Risiken zu reduzieren.

Wenn Sie mehrere Umgebungen haben, z. B. test, development und production, empfehlen wir, mit der am wenigsten kritischen Umgebung zu beginnen, z. B. test, 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 ausführen. Auf diese Weise 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, alle Best Practices in diesem Dokument zu befolgen. Mithilfe der folgenden Checkliste können Sie Ihren Fortschritt verfolgen. Jeder Eintrag 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

Die Zeit für das Upgrade eines Clusters hängt von der Anzahl der Knoten und der Arbeitslastdichte ab, die auf ihnen ausgeführt wird. Nutzen Sie ein Wartungsfenster mit ausreichend Zeit, um ein Clusterupgrade erfolgreich abzuschließen.

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

Wenn ein Cluster beispielsweise 50 Knoten hat, würde die gesamte Upgradezeit etwa fünfhundert Minuten betragen: 10 minutes * 50 nodes = 500 minutes.

Kompatibilität anderer Anthos-Komponenten prüfen

Wenn in Ihrem Cluster Anthos-Komponenten wie Anthos Service Mesh oder Config Management ausgeführt werden, prüfen Sie die Anthos-Kompatibilitätsmatrix und prüfen Sie die unterstützten Versionen mit GKE on Bare Metal vor und nach dem Upgrade.

Die Kompatibilitätsprüfung basiert auf dem Administrator- oder Nutzercluster, in dem Anthos Service Mesh oder Config Management 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 ob sich in dem Cluster, der aktualisiert wird, genügend Ressourcen für die Verwaltung des Upgrades befinden. Verwenden Sie die benutzerdefinierten Dashboards in der Operations-Suite von Google Cloud, 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 Ressourcennutzungsdaten können Ihnen Aufschluss darüber geben, wann ein Upgrade die geringste Unterbrechung verursachen würde, z. B. an Wochenenden oder Abenden. Dies hängt von der ausgeführten Arbeitslast und den Anwendungsfällen ab.

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 einer Anwendungsausfallzeit führt. Bevor Sie mit dem Upgrade eines Administratorclusters beginnen, müssen Sie jedoch trotzdem prüfen, ob kostenlose Ressourcen verfügbar sind. Außerdem kann das Upgrade des Administratorclusters mit einem gewissen Risiko verbunden sein. Daher wird es möglicherweise empfohlen, wenn der Verwaltungszugriff auf den Cluster weniger kritisch ist, wenn die Nutzung weniger aktiv genutzt wird.

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 die einzelnen Lebenszyklus-Controller. 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. Behalten Sie die Version der Nutzercluster bei, um die zusätzlichen Rechenressourcen zu reduzieren, die während eines Upgrades erforderlich sind.

Im folgenden Beispiel für eine Bereitstellung befinden sich die beiden Nutzercluster in unterschiedlichen 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 von Lebenszyklus-Controllern verbraucht insgesamt 1.000 mCPU und 3 GiB RAM. Der aktuelle Ressourcenverbrauch dieser Lebenszyklus-Controller beträgt 3.000 mCPU und 9 GiB RAM.

Wenn Nutzercluster 2 auf 1.13.3 aktualisiert wird, sind jetzt zwei Lebenszyklus-Controller 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, werden jetzt alle Geräte 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 einen Satz Lebenszyklus-Controller, die insgesamt 1.000 mCPU und 3 GiB RAM verbrauchen.

Im folgenden Beispiel sind alle Nutzercluster dieselbe Version. Wenn der Administratorcluster aktualisiert wird, werden nur zwei Gruppen von Lebenszyklus-Controllern verwendet, wodurch der Verbrauch der 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, sehen Sie möglicherweise Pods wie anthos-cluster-operator, capi-controller-manager, cap-controller-manager oder cap-kubeadm-bootstraper im Status Pending. Zur Behebung 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 auch kubectl edit deployment verwenden, um die ausstehenden Bereitstellungen zu 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 Rechenressourcen für verschiedene Upgradeszenarien aufgeführt:

Cluster Administratorcluster-Ressourcen erforderlich
Nutzerclusterupgrade Upgrade auf dieselbe Version anderer Cluster: –

Führen Sie ein Upgrade auf eine andere Version eines anderen Administrator- oder Nutzerclusters durch: 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) Surge mit 1.000 mCPU und 3 GiB RAM Ressourcen werden nach der Verwendung zurückgegeben.
Eigenständig Surge mit 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 die 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 richtig konfiguriert sind oder bei denen Pods hängen geblieben sind.

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 das Upgrade beendet. Es empfiehlt sich, diese Probleme proaktiv mit dem Befehl bmctl check cluster zu identifizieren und zu beheben, anstatt sich auf die Preflight-Prüfungen zu verlassen, die Cluster vor möglichen Schäden schützen.

Bereitstellungen von Nutzerarbeitslasten prüfen

Bei 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 das Leeren der Arbeitslast zu einer Störung 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, berücksichtigt der Draining-Prozess des Upgrades auf bis zu 1.14 keine Budgets für Pod-Störungen (PDBs). Arbeitslasten können eingeschränkt ausgeführt werden. Das Replikat mit der geringsten Leistung ist total replica number - concurrent upgrade number.

API-Kompatibilität

Prüfen Sie, ob die API-Kompatibilität der Arbeitslast mit neuerer Nebenversion von Kubernetes kompatibel ist, wenn Sie ein Upgrade einer Nebenversion durchführen. Führen Sie bei Bedarf ein Upgrade der Arbeitslast auf eine kompatible Version durch. Wenn möglich, bietet das Anthos-Entwicklerteam Anleitungen zum Identifizieren von Arbeitslasten, die inkompatible APIs wie verworfene Kubernetes 1.22 APIs verwenden.

Wenn Sie Anthos Service Mesh, Config Management oder andere GKE Enterprise-Komponenten verwenden, prüfen Sie, ob die installierte Version mit der neuen Version von GKE on Bare Metal kompatibel ist. Informationen zur Versionskompatibilität von GKE Enterprise-Komponenten finden Sie unter Unterstützung für Anthos-Versionen und -Upgrades.

Verwendung von Webhooks prüfen

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

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. Ab GKE on Bare Metal-Version 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) und CentOS 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.

GKE on Bare Metal unterstützt SELinux nur in RHEL- und CentOS-Systemen.

Konfiguration der Pod-Dichte nicht ändern

GKE on Bare Metal 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 angehalten, damit die Knotenpools der Steuerungsebene und des Load-Balancers ausreichend verfügbar sind.

Nächste Schritte