Auswirkungen von Ausfällen in Google Distributed Cloud verstehen

Google Distributed Cloud wurde entwickelt, um das Ausmaß von Fehlern zu begrenzen und Funktionen zu priorisieren, die für die Geschäftskontinuität entscheidend sind. In diesem Dokument wird erläutert, wie die Funktionalität Ihrer Cluster im Falle eines Fehlers betroffen ist. Diese Informationen können Ihnen dabei helfen, Bereiche bei der Fehlerbehebung zu priorisieren, wenn Sie ein Problem haben.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

Zu den Hauptfunktionen von Google Distributed Cloud gehören die folgenden Kategorien:

  • Arbeitslasten ausführen: Vorhandene Arbeitslasten können weiter ausgeführt werden. Dies ist der wichtigste Aspekt für die Aufrechterhaltung des Geschäftsbetriebs. Auch wenn in Ihrem Cluster ein Problem auftritt, werden die vorhandenen Arbeitslasten möglicherweise weiterhin ohne Unterbrechung ausgeführt.
  • Arbeitslasten verwalten: Sie können Arbeitslasten erstellen, aktualisieren und löschen. Dies ist der zweitwichtigste Aspekt, um Arbeitslasten zu skalieren, wenn der Traffic zunimmt, auch wenn der Cluster ein Problem hat.
  • Nutzercluster verwalten: Sie können Knoten verwalten, Nutzercluster aktualisieren, upgraden und löschen. Dies ist weniger wichtig als die Überlegungen zum Anwendungslebenszyklus. Wenn auf den vorhandenen Knoten Kapazität vorhanden ist, wirkt sich die Unfähigkeit, Nutzercluster zu ändern, nicht auf Nutzerarbeitslasten aus.
  • Administratorcluster verwalten: Sie können den Administratorcluster aktualisieren und upgraden.
    • Bei Bereitstellungen mit separaten Administrator- und Nutzerclustern ist dies die unwichtigste Überlegung, da der Administratorcluster keine Nutzerarbeitslasten hostet. Wenn in Ihrem Administratorcluster ein Problem auftritt, werden Ihre Anwendungsarbeitslasten in anderen Clustern weiterhin ohne Unterbrechung ausgeführt.
    • Wenn Sie andere Bereitstellungsmodelle verwenden, z. B. Hybrid- oder Standalone-Modelle, führt der Administratorcluster Anwendungsarbeitslasten aus. Wenn im Administratorcluster ein Problem auftritt und die Steuerungsebene ausgefallen ist, können Sie auch keine Anwendungsarbeitslasten oder Nutzerclusterkomponenten verwalten.

In den folgenden Abschnitten werden diese Kategorien der Hauptfunktionen verwendet, um die Auswirkungen bestimmter Arten von Fehlerszenarien zu beschreiben. Wenn es als Teil eines Fehlerszenarios zu Unterbrechungen kommt, wird auch die Dauer (Reihenfolge) der Unterbrechung angegeben, falls möglich.

Knotenfehler

Ein Knoten in Google Distributed Cloud funktioniert möglicherweise nicht mehr oder ist auf dem Netzwerk nicht mehr erreichbar. Abhängig vom Knotenpool und Cluster der ausgefallenen Maschine gibt es verschiedene Fehlermodi.

Knoten der Steuerungsebene

In der folgenden Tabelle wird das Verhalten von Knoten beschrieben, die Teil der Kontrollebene in Google Distributed Cloud sind:

Arbeitslasten ausführen Arbeitslasten verwalten Nutzercluster verwalten Administratorcluster verwalten
Störung (Dauer) Keine Unterbrechung Mögliche Unterbrechung (unbekannt) Mögliche Unterbrechung (unbekannt) Mögliche Unterbrechung (unbekannt)
Erklärung – Wenn der Knotenfehler sich auf den einzelnen Knoten der Steuerungsebene in einem Nutzercluster ohne Hochverfügbarkeit (HA) auswirkt oder wenn er sich auf nicht weniger als die Hälfte der Knoten der Steuerungsebene in einem hochverfügbaren Nutzercluster auswirkt, kommt es zu einer Unterbrechung. Das Quorum der Steuerungsebene des Nutzerclusters geht verloren. Wenn der Knotenfehler sich auf den einzelnen Knoten der Steuerungsebene in einem Administratorcluster ohne Hochverfügbarkeit auswirkt oder wenn er sich auf nicht weniger als die Hälfte der Knoten der Steuerungsebene in einem hochverfügbaren Administratorcluster auswirkt, kommt es zu einer Unterbrechung. Das Quorum der Steuerungsebene des Administratorclusters geht verloren. Wenn der Knotenfehler sich auf den einzelnen Knoten der Steuerungsebene in einem Administratorcluster ohne Hochverfügbarkeit auswirkt oder wenn er sich auf nicht weniger als die Hälfte der Knoten der Steuerungsebene in einem hochverfügbaren Administratorcluster auswirkt, kommt es zu einer Unterbrechung. Das Quorum der Steuerungsebene des Administratorclusters geht verloren.
Wiederherstellung – Weitere Informationen finden Sie unter Wiederherstellung nach einem Quorumverlust. Weitere Informationen finden Sie unter Wiederherstellung nach einem Quorumverlust. Weitere Informationen finden Sie unter Wiederherstellung nach einem Quorumverlust.
vermeiden – Stellen Sie Nutzercluster im Hochverfügbarkeitsmodus bereit, um die Wahrscheinlichkeit von Unterbrechungen zu minimieren. Stellen Sie Administratorcluster im Hochverfügbarkeitsmodus bereit, um die Wahrscheinlichkeit von Unterbrechungen zu minimieren. Stellen Sie Administratorcluster im Hochverfügbarkeitsmodus bereit, um die Wahrscheinlichkeit von Unterbrechungen zu minimieren.

Load Balancer-Knoten

In der folgenden Tabelle wird das Verhalten von Knoten beschrieben, auf denen die Load Balancer in der Google Distributed Cloud gehostet werden. Diese Anleitung gilt nur für gebündelte Load-Balancer mit dem Layer-2-Modus. Prüfen Sie beim manuellen Load-Balancing die Fehlermodi Ihrer externen Load-Balancer:

Arbeitslasten ausführen Arbeitslasten verwalten Nutzercluster verwalten Administratorcluster verwalten
Störung (Dauer) Mögliche Unterbrechung (variiert) Mögliche Unterbrechung (variiert) Mögliche Unterbrechung (variiert) Mögliche Unterbrechung (variiert)
Erklärung Wenn externe Arbeitslasten erfordern, dass der Load-Balancer der Datenebene mit Arbeitslasten im Cluster kommuniziert, und Sie nur einen Load-Balancer-Knoten haben, kommt es zu einer Unterbrechung. Die virtuelle IP-Adresse der Steuerungsebene des Nutzerclusters befindet sich auf einem Load-Balancer-Knoten. Wenn der Load-Balancer-Knotenpool des Nutzerclusters nicht hochverfügbar ist, kommt es zu einer Unterbrechung. Die virtuelle IP-Adresse der Steuerungsebene des Administratorclusters befindet sich auf einem Load Balancer-Knoten. Wenn der Load Balancer-Knotenpool des Administratorclusters nicht hochverfügbar ist, kommt es zu einer Unterbrechung. Die virtuelle IP-Adresse der Steuerungsebene des Administratorclusters befindet sich auf einem Load Balancer-Knoten. Wenn der Load Balancer-Knotenpool des Administratorclusters nicht hochverfügbar ist, kommt es zu einer Unterbrechung.
Wiederherstellung

Wenn mehrere Load-Balancer-Knoten vorhanden sind, erfolgt ein MetalLB-Failover innerhalb weniger Sekunden.

Wenn keine Hochverfügbarkeit vorliegt, können Sie zusätzliche Load-Balancer-Knoten bereitstellen.

Bei Hochverfügbarkeit erfolgt das Failover automatisch im Bereich von Sekunden.

Wenn keine Hochverfügbarkeit vorliegt, können Sie zusätzliche Load-Balancer-Knoten bereitstellen.

Bei Hochverfügbarkeit erfolgt das Failover automatisch im Bereich von Sekunden.

Wenn keine Hochverfügbarkeit vorliegt, können Sie zusätzliche Load-Balancer-Knoten bereitstellen.

Bei Hochverfügbarkeit erfolgt das Failover automatisch im Bereich von Sekunden.

Wenn keine Hochverfügbarkeit vorliegt, können Sie zusätzliche Load-Balancer-Knoten bereitstellen.
vermeiden Stellen Sie Load-Balancer-Knotenpools im Hochverfügbarkeitsmodus bereit, um die Möglichkeit einer Unterbrechung zu minimieren. Stellen Sie Load-Balancer-Knotenpools im Hochverfügbarkeitsmodus bereit, um die Möglichkeit einer Unterbrechung zu minimieren. Stellen Sie Load-Balancer-Knotenpools im Hochverfügbarkeitsmodus bereit, um die Möglichkeit einer Unterbrechung zu minimieren. Stellen Sie Load-Balancer-Knotenpools im Hochverfügbarkeitsmodus bereit, um die Möglichkeit von Unterbrechungen zu minimieren.

Worker-Knoten

In der folgenden Tabelle wird das Verhalten von Arbeitsknoten in Google Distributed Cloud beschrieben:

Arbeitslasten ausführen Arbeitslasten verwalten Nutzercluster verwalten Administratorcluster verwalten
Störung (Dauer) Mögliche Unterbrechung (Bereich von Sekunden) Keine Unterbrechung Keine Unterbrechung Keine Unterbrechung
Erklärung

Die Pods, die auf dem ausgefallenen Knoten ausgeführt werden, werden unterbrochen und automatisch auf andere intakte Knoten umverteilt. Das Standardzeitlimit für das Auslagern beträgt 5 Minuten.

Wenn Nutzeranwendungen freie Arbeitslastkapazität haben und auf mehrere Knoten verteilt sind, kann die Unterbrechung von Clients, die Wiederholungsversuche implementieren, nicht beobachtet werden.

Die Pods werden automatisch auf fehlerfreien Knoten neu gestartet.

Wenn der Cluster keine freien Kapazitäten hat, kann die Unterbrechung andauern, bis dem Cluster neue Knoten hinzugefügt werden.

 – – –
Wiederherstellung Wenn der Cluster keine freien Kapazitäten hat, müssen Sie weitere Knoten bereitstellen, die auf mehrere Ausfallzonen verteilt sind, und fehlgeschlagene Arbeitslasten auf die neuen Knoten verschieben. – – –
vermeiden

Stellen Sie Knoten bereit, die über mehrere Ausfallzonen verteilt sind.

Stellen Sie Arbeitslasten mit mehreren Replikaten bereit, die auf mehrere Ausfallzonen verteilt sind, um die Möglichkeit einer Unterbrechung zu minimieren.

 – – –

Speicherfehler

Der Speicher in Google Distributed Cloud funktioniert möglicherweise nicht mehr oder ist auf dem Netzwerk nicht mehr erreichbar. Je nach Speicher, der ausfällt, gibt es verschiedene Fehlermodi.

etcd

Der Inhalt der Verzeichnisse /var/lib/etcd und /var/lib/etcd-events kann beschädigt werden, wenn der Knoten nicht richtig heruntergefahren wurde oder ein zugrunde liegender Speicherfehler vorliegt. In der folgenden Tabelle wird das Verhalten der Hauptfunktion aufgrund von etcd-Fehlern beschrieben:

Arbeitslasten ausführen Arbeitslasten verwalten Nutzercluster verwalten Administratorcluster verwalten
Störung (Dauer) Keine Unterbrechung Mögliche Unterbrechung (unbekannt) Mögliche Unterbrechung (unbekannt) Mögliche Unterbrechung (unbekannt)
Erklärung Wenn die vorhandenen Arbeitslasten nicht auf der Kubernetes-Steuerungsebene basieren, funktionieren sie weiterhin ohne Unterbrechung. Wenn etcd in einem einzelnen Nutzercluster der Steuerungsebene ausfällt oder auf mindestens der Hälfte der Knoten der Steuerungsebene eines Hochverfügbarkeits-Nutzerclusters fehlschlägt, kommt es zu einer Unterbrechung. Das Quorum der Steuerungsebene des Nutzerclusters geht verloren. Wenn etcd in einem einzelnen Administratorcluster der Steuerungsebene ausfällt oder auf mindestens der Hälfte der Knoten der Steuerungsebene in einem Hochverfügbarkeits-Administratorcluster fehlschlägt, kommt es zu einer Unterbrechung. Das Quorum der Steuerungsebene des Administratorclusters geht verloren. Wenn etcd in einem einzelnen Administratorcluster der Steuerungsebene ausfällt oder auf mindestens der Hälfte der Knoten der Steuerungsebene in einem Hochverfügbarkeits-Administratorcluster fehlschlägt, kommt es zu einer Unterbrechung. Das Quorum der Steuerungsebene des Administratorclusters geht verloren.
Wiederherstellung – Weitere Informationen finden Sie unter Wiederherstellung nach einem Quorumverlust. Weitere Informationen finden Sie unter Wiederherstellung nach einem Quorumverlust. Weitere Informationen finden Sie unter Wiederherstellung nach einem Quorumverlust.
vermeiden – Stellen Sie Nutzercluster im Hochverfügbarkeitsmodus bereit, um die Wahrscheinlichkeit von Unterbrechungen zu minimieren. Stellen Sie Administratorcluster im Hochverfügbarkeitsmodus bereit, um die Möglichkeit von Unterbrechungen zu minimieren. Stellen Sie Administratorcluster im Hochverfügbarkeitsmodus bereit, um die Möglichkeit von Unterbrechungen zu minimieren.

Nutzeranwendung PersistentVolume

In der folgenden Tabelle ist das Verhalten der Hauptfunktion aufgrund des Fehler eines PersistentVolume beschrieben:

Arbeitslasten ausführen Arbeitslasten verwalten Nutzercluster verwalten Administratorcluster verwalten
Störung (Dauer) Mögliche Unterbrechung (unbekannt) Keine Unterbrechung Keine Unterbrechung Keine Unterbrechung
Erklärung Die Arbeitslasten, die das fehlgeschlagene PersistentVolume are affected. verwenden – – –
Wiederherstellung – – – –
vermeiden Um die Möglichkeit einer Unterbrechung zu minimieren, stellen Sie die Nutzerarbeitslast im Hochverfügbarkeitsmodus bereit. – – –

Beschädigtes Fluent Bit-Laufwerk

Die Beschädigung eines Fluent Bit-Laufwerks hat keine Auswirkungen auf die Hauptfunktionen. Sie wirkt sich allerdings auf das Erfassen und Prüfen von Logs in Google Cloud aus.

Das SIGSEGV-Ereignis kann manchmal in Logs von stackdriver-log-forwarder beobachtet werden. Dieser Fehler kann durch die beschädigten zwischengespeicherten Logs auf dem Laufwerk verursacht werden.

Fluent Bit hat einen Mechanismus, um die defekten Blöcke herauszufiltern und zu verwerfen. Diese Funktion ist in der Fluent Bit-Version (v1.8.3) verfügbar, die in Google Distributed Cloud verwendet wird.

LoadBalancer-IP-Adressen verbraucht

Wenn alle IP-Adressen in den zugewiesenen Pools derzeit belegt sind, können neu erstellte LoadBalancer-Dienste keine LoadBalancer-IP-Adresse erhalten. Dieses Szenario wirkt sich auf die Fähigkeit der Clients des Dienstes aus, mit den LoadBalancer-Diensten zu kommunizieren.

Zur Wiederherstellung nach einer solchen IP-Adressen-Ausschöpfung weisen Sie dem Adresspool weitere IP-Adressen zu, indem Sie die benutzerdefinierte Clusterressource ändern.

Ablaufdatum des Zertifikats

Google Distributed Cloud generiert eine selbst signierte Zertifizierungsstelle (CA) während des Clusterinstallationsprozesses. Die Zertifizierungsstelle hat eine Gültigkeitsdauer von 10 Jahren und ist für die Generierung von Zertifikaten verantwortlich, die nach einem Jahr ablaufen. Rotieren Sie die Zertifikate regelmäßig, um Clusterausfälle zu vermeiden. Sie können Zertifikate rotieren, indem Sie ein Upgrade des Clusters ausführen. Dies ist die empfohlene Methode. Wenn Sie den Cluster nicht upgraden können, haben Sie die Möglichkeit, eine On-Demand-CA-Rotation auszuführen. Weitere Informationen zu Clusterzertifikaten finden Sie unter PKI-Zertifikate und -Anforderungen in der Kubernetes-Dokumentation.

Wenn die Clusterzertifikate abgelaufen sind, müssen sie manuell verlängert werden.

Arbeitslasten ausführen Arbeitslasten verwalten Nutzercluster verwalten Administratorcluster verwalten
Störung (Dauer) Keine Unterbrechung Mögliche Unterbrechung (unbekannt) Mögliche Unterbrechung (unbekannt) Mögliche Unterbrechung (unbekannt)
Erklärung Wenn die Nutzerarbeitslasten nicht mit den Komponenten der Kubernetes-Steuerungsebene kommunizieren, kommt es zu keinen Unterbrechungen. Wenn die Zertifizierungsstellen für Nutzercluster ablaufen, kommt es zu einer Unterbrechung. Wenn die Zertifizierungsstellen für Administratorcluster ablaufen, kommt es zu einer Unterbrechung. Wenn die Zertifizierungsstellen für Nutzercluster ablaufen, kommt es zu einer Unterbrechung.
Wiederherstellung –

Folgen Sie der Anleitung zur manuellen Verlängerung von Zertifikaten auf dem Nutzercluster.

Folgen Sie der Anleitung zur manuellen Verlängerung von Zertifikaten auf dem Nutzercluster.

Folgen Sie der Anleitung zur manuellen Verlängerung von Zertifikaten auf dem Nutzercluster.
vermeiden Richten Sie Monitore für das Ablaufdatum des Zertifikats ein. Ein Beispiel für einen Messwert kubelet_certificate_manager_server_expiration_seconds können Sie in der Liste der Messwerte finden.

Upgradefehler

Arbeitslasten ausführen Arbeitslasten verwalten Nutzercluster verwalten Administratorcluster verwalten
Störung (Dauer) Keine Unterbrechung Keine Unterbrechung Mögliche Unterbrechung (unbekannt) Mögliche Unterbrechung (unbekannt)
Erklärung

Wenn das Upgrade auf der Steuerungsebene des Nutzerclusters fehlschlägt, kommt es bei bestehenden Arbeitslasten zu KEINER Unterbrechung.

Wenn das Upgrade auf einem bestimmten Worker-Knoten fehlschlägt, werden die Arbeitslasten auf diesem Knoten per Drain beendet und auf andere fehlerfreie Knoten verschoben, sofern die fehlerfreien Knoten über zusätzliche Kapazität verfügen.

 Das Upgrade wird beendet, wenn bei einem der Knoten der Steuerungsebene kein Upgrade durchgeführt werden kann. Der Cluster funktioniert weiterhin, wenn das Upgrade fehlschlägt, sofern der Nutzercluster hochverfügbar ist. Wenn das Upgrade auf der Steuerungsebene des Administratorclusters fehlschlägt, kommt es zu einer Unterbrechung, bis das Upgrade abgeschlossen ist. Wenn das Upgrade auf der Steuerungsebene des Administratorclusters fehlschlägt, kommt es zu einer Unterbrechung, bis das Upgrade abgeschlossen ist.
Wiederherstellung – – Das Upgrade kann wiederholt werden. Weitere Informationen finden Sie unter Upgradeprobleme diagnostizieren und Upgrade fortsetzen. Das Upgrade kann wiederholt werden. Weitere Informationen finden Sie unter Upgradeprobleme diagnostizieren und Upgrade fortsetzen.
vermeiden – – Weitere Informationen finden Sie unter Vor dem Upgrade eine Sicherung erstellen. Weitere Informationen finden Sie unter Vor dem Upgrade eine Sicherung erstellen.

Nächste Schritte