Auswirkungen von Ausfällen in Google Distributed Cloud verstehen

Google Distributed Cloud ist darauf ausgelegt, 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 sich ein Fehler auf die Funktionalität Ihrer Cluster auswirkt. Diese Informationen können Ihnen helfen, bei Problemen die Bereiche für die Fehlerbehebung zu priorisieren.

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

Die Kernfunktionalität von Google Distributed Cloud umfasst 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. Selbst wenn bei Ihrem Cluster ein Problem auftritt, werden die vorhandenen Arbeitslasten möglicherweise ohne Unterbrechung weiter ausgeführt.
  • Arbeitslasten verwalten: Sie können Arbeitslasten erstellen, aktualisieren und löschen. Dies ist der zweitwichtigste Aspekt beim Skalieren von Arbeitslasten, wenn der Traffic zunimmt, selbst wenn es beim Cluster ein Problem gibt.
  • Nutzercluster verwalten: Sie können Knoten verwalten sowie Nutzercluster aktualisieren, aktualisieren und löschen. Dies ist weniger wichtig als die Überlegungen zum Anwendungslebenszyklus. Wenn auf den vorhandenen Knoten Kapazität verfügbar ist, hat die Möglichkeit, Nutzercluster nicht zu ändern, keine Auswirkungen auf die Nutzerarbeitslasten.
  • Administratorcluster verwalten: Sie können den Administratorcluster aktualisieren und upgraden.
    • Bei Bereitstellungen mit separaten Administrator- und Nutzerclustern ist dies unwichtig, da der Administratorcluster keine Nutzerarbeitslasten hostet. Wenn bei Ihrem Administratorcluster ein Problem auftritt, werden Ihre Anwendungsarbeitslasten in anderen Clustern ohne Unterbrechung weiter ausgeführt.
    • Wenn Sie andere Bereitstellungsmodelle verwenden, z. B. Hybrid- oder eigenständige Bereitstellung, führt der Administratorcluster Anwendungsarbeitslasten aus. Wenn beim 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 von Hauptfunktionen verwendet, um die Auswirkungen bestimmter Arten von Fehlerszenarien zu beschreiben. Wenn eine Störung als Teil eines Fehlerszenarios auftritt, wird nach Möglichkeit auch die Dauer (Reihenfolge) der Störung angegeben.

Knotenfehler

Ein Knoten in Google Distributed Cloud funktioniert möglicherweise nicht mehr oder ist im Netzwerk unerreichbar. Je nach Knotenpool und Cluster, zu dem die ausgefallene Maschine gehört, gibt es verschiedene Fehlermodi.

Knoten der Steuerungsebene

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

Arbeitslasten ausführen Arbeitslasten verwalten Nutzercluster verwalten Administratorcluster verwalten
Unterbrechung (Dauer) Keine Störung Mögliche Störung (unbekannt) Mögliche Störung (unbekannt) Mögliche Störung (unbekannt)
Erklärung — Wenn der Knotenausfall einen einzelnen Knoten der Steuerungsebene in einem nicht hochverfügbaren Nutzercluster betrifft oder nicht weniger als die Hälfte der Knoten der Steuerungsebene in einem Hochverfügbarkeitsnutzercluster betrifft, kommt es zu einer Störung. Das Quorum der Steuerungsebene des Nutzerclusters geht verloren. Wenn der Knotenausfall einen einzelnen Knoten der Steuerungsebene in einem Administratorcluster ohne Hochverfügbarkeit oder mindestens die Hälfte der Knoten der Steuerungsebene in einem Hochverfügbarkeitsadministratorcluster betrifft, kommt es zu einer Störung. Das Quorum der Steuerungsebene des Administratorclusters geht verloren. Wenn der Knotenausfall einen einzelnen Knoten der Steuerungsebene in einem Administratorcluster ohne Hochverfügbarkeit oder mindestens die Hälfte der Knoten der Steuerungsebene in einem Hochverfügbarkeitsadministratorcluster betrifft, kommt es zu einer Störung. Das Quorum der Steuerungsebene des Administratorclusters geht verloren.
Wiederherstellung — Weitere Informationen finden Sie unter Wie sich nach einem Quorumverlust wiederherstellen lässt. Weitere Informationen finden Sie unter Wie sich nach einem Quorumverlust wiederherstellen lässt. Weitere Informationen finden Sie unter Wie sich nach einem Quorumverlust wiederherstellen lässt.
Prävention — Stellen Sie Nutzercluster im Hochverfügbarkeitsmodus bereit, um das Risiko von Unterbrechungen zu minimieren. Stellen Sie Administratorcluster im Hochverfügbarkeitsmodus bereit, um das Risiko von Unterbrechungen zu minimieren. Stellen Sie Administratorcluster im Hochverfügbarkeitsmodus bereit, um das Risiko von Unterbrechungen zu minimieren.

Load-Balancer-Knoten

In der folgenden Tabelle wird das Verhalten von Knoten beschrieben, die die Load-Balancer in Google Distributed Cloud hosten. Diese Anleitung gilt nur für gebündelte Load-Balancer mit dem Ebene-2-Modus. Sehen Sie sich für das manuelle Load-Balancing die Fehlermodi Ihrer externen Load-Balancer an:

Arbeitslasten ausführen Arbeitslasten verwalten Nutzercluster verwalten Administratorcluster verwalten
Unterbrechung (Dauer) Mögliche Störung (variiert) Mögliche Störung (variiert) Mögliche Störung (variiert) Mögliche Störung (variiert)
Erklärung Wenn externe Arbeitslasten auf den Load-Balancer der Datenebene angewiesen sind, um mit Arbeitslasten im Cluster zu kommunizieren, und Sie nur einen Load-Balancer-Knoten haben, kommt es zu Störungen. Die virtuelle IP-Adresse der Steuerungsebene des Nutzerclusters befindet sich auf einem Load-Balancer-Knoten. Wenn der Load-Balancer-Knotenpool des Nutzerclusters keine Hochverfügbarkeit hat, kommt es zu einer Störung. Die virtuelle IP-Adresse der Steuerungsebene des Administratorclusters befindet sich auf einem Load-Balancer-Knoten. Wenn der Load-Balancer-Knotenpool des Administratorclusters keine Hochverfügbarkeit hat, kommt es zu einer Störung. Die virtuelle IP-Adresse der Steuerungsebene des Administratorclusters befindet sich auf einem Load-Balancer-Knoten. Wenn der Load-Balancer-Knotenpool des Administratorclusters keine Hochverfügbarkeit hat, kommt es zu einer Störung.
Wiederherstellung

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

Wenn kein Hochverfügbarkeit vorhanden ist, sollten Sie zusätzliche Load-Balancer-Knoten bereitstellen.

Bei Hochverfügbarkeit erfolgt der Failover automatisch und in der Größenordnung von Sekunden.

Wenn keine Hochverfügbarkeit vorhanden ist, sollten Sie zusätzliche Load-Balancer-Knoten bereitstellen.

Bei Hochverfügbarkeit erfolgt der Failover automatisch und in der Größenordnung von Sekunden.

Wenn kein Hochverfügbarkeit vorhanden ist, sollten Sie zusätzliche Load-Balancer-Knoten bereitstellen.

Bei Hochverfügbarkeit erfolgt der Failover automatisch und in der Größenordnung von Sekunden.

Wenn kein Hochverfügbarkeit vorhanden ist, sollten Sie zusätzliche Load-Balancer-Knoten bereitstellen.
Prävention Stellen Sie Load-Balancer-Knotenpools im Hochverfügbarkeitsmodus bereit, um die Gefahr von Unterbrechungen zu minimieren. Stellen Sie Load-Balancer-Knotenpools im Hochverfügbarkeitsmodus bereit, um die Gefahr von Unterbrechungen zu minimieren. Stellen Sie Load-Balancer-Knotenpools im Hochverfügbarkeitsmodus bereit, um die Gefahr von Unterbrechungen zu minimieren. Stellen Sie Load-Balancer-Knotenpools im Hochverfügbarkeitsmodus bereit, um die Gefahr von Unterbrechungen zu minimieren.

Worker-Knoten

In der folgenden Tabelle wird das Verhalten von Worker-Knoten in Google Distributed Cloud beschrieben:

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

Die Pods, die auf dem ausgefallenen Knoten ausgeführt werden, werden unterbrochen und automatisch auf andere fehlerfreie Knoten verschoben, wobei das Standardzeitlimit 5 Minuten für die Bereinigung liegt.

Wenn Nutzeranwendungen freie Arbeitslastkapazität haben und auf mehrere Knoten verteilt sind, können Clients, die Wiederholungsversuche implementieren, die Störung nicht beobachten.

Pods werden auf fehlerfreien Knoten automatisch 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 Fehlerzonen verteilt sind, und fehlgeschlagene Arbeitslasten auf die neuen Knoten verschieben. — — —
Prävention

Knoten bereitstellen, die auf mehrere Fehlerzonen verteilt sind

Stellen Sie Arbeitslasten mit mehreren Replikaten bereit, die auf mehrere Fehlerzonen verteilt sind, um das Risiko von Unterbrechungen zu minimieren.

 — — —

Speicherfehler

Der Speicher in Google Distributed Cloud funktioniert möglicherweise nicht mehr oder ist im Netzwerk unerreichbar. Je nach Speicher, der ausgefallen ist, gibt es verschiedene Fehlermodi.

etcd

Der Inhalt der Verzeichnisse /var/lib/etcd und /var/lib/etcd-events kann beschädigt werden, wenn der Knoten zu schnell heruntergefahren wird oder ein zugrunde liegender Speicherfehler auftritt. In der folgenden Tabelle ist das Verhalten der Hauptfunktion aufgrund von etcd-Fehlern dargestellt:

Arbeitslasten ausführen Arbeitslasten verwalten Nutzercluster verwalten Administratorcluster verwalten
Unterbrechung (Dauer) Keine Störung Mögliche Störung (unbekannt) Mögliche Störung (unbekannt) Mögliche Störung (unbekannt)
Erklärung Vorhandene Arbeitslasten, die nicht von der Kubernetes-Steuerungsebene abhängen, funktionieren weiterhin ohne Unterbrechung. Wenn etcd in einem Nutzercluster einer einzelnen Steuerungsebene oder bei mindestens der Hälfte der Knoten der Steuerungsebene in einem HA-Nutzercluster fehlschlägt, kommt es zu einer Störung. Das Quorum der Steuerungsebene des Nutzerclusters geht verloren. Wenn etcd in einem Administratorcluster einer einzelnen Steuerungsebene oder bei mindestens der Hälfte der Knoten der Steuerungsebene in einem Hochverfügbarkeitsadministratorcluster fehlschlägt, kommt es zu einer Störung. Das Quorum der Steuerungsebene des Administratorclusters geht verloren. Wenn etcd in einem Administratorcluster einer einzelnen Steuerungsebene oder bei mindestens der Hälfte der Knoten der Steuerungsebene in einem Hochverfügbarkeitsadministratorcluster fehlschlägt, kommt es zu einer Störung. Das Quorum der Steuerungsebene des Administratorclusters geht verloren.
Wiederherstellung — Weitere Informationen finden Sie unter Wie sich nach einem Quorumverlust wiederherstellen lässt. Weitere Informationen finden Sie unter Wie sich nach einem Quorumverlust wiederherstellen lässt. Weitere Informationen finden Sie unter Wie sich nach einem Quorumverlust wiederherstellen lässt.
Prävention — Stellen Sie Nutzercluster im Hochverfügbarkeitsmodus bereit, um das Risiko von Unterbrechungen zu minimieren. Stellen Sie Administratorcluster im Hochverfügbarkeitsmodus bereit, um das Risiko von Unterbrechungen zu minimieren. Stellen Sie Administratorcluster im Hochverfügbarkeitsmodus bereit, um das Risiko von Unterbrechungen zu minimieren.

Nutzeranwendung PersistentVolume

In der folgenden Tabelle wird das Verhalten der Hauptfunktion aufgrund des Fehlers eines PersistentVolume beschrieben:

Arbeitslasten ausführen Arbeitslasten verwalten Nutzercluster verwalten Administratorcluster verwalten
Unterbrechung (Dauer) Mögliche Störung (unbekannt) Keine Störung Keine Störung Keine Störung
Erklärung Die Arbeitslasten, die den fehlgeschlagenen PersistentVolume are affected. verwenden — — —
Wiederherstellung — — — —
Prävention Stellen Sie die Nutzerarbeitslast im Hochverfügbarkeitsmodus bereit, um das Risiko von Unterbrechungen zu minimieren. — — —

Beschädigtes Laufwerk mit Fluent Bit

Die Beschädigung einer Fluent-Bit-Festplatte wirkt sich nicht auf die Hauptfunktionen aus, beeinträchtigt jedoch die Fähigkeit, Logs in Google Cloud zu erfassen und zu prüfen.

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

Fluent Bit verfügt über einen Mechanismus, der die beschädigten Teile herausfiltert und löscht. Dieses Feature ist in der in Google Distributed Cloud verwendeten fluent-Bit-Version (Version 1.8.3) verfügbar.

Von LoadBalancer IP-Adresse

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

Zur Wiederherstellung nach dieser IP-Adressausschöpfung weisen Sie dem Adresspool weitere IP-Adressen zu. Ändern Sie dazu die benutzerdefinierte Clusterressource.

Ablauf des Zertifikats

Google Distributed Cloud generiert während der Clusterinstallation eine selbst signierte Zertifizierungsstelle. Die Zertifizierungsstelle läuft nach 10 Jahren ab und ist für die Erstellung von Zertifikaten verantwortlich, die nach einem Jahr ablaufen. Rotieren Sie Zertifikate regelmäßig, um Ausfallzeiten des Clusters zu vermeiden. Sie können Zertifikate rotieren, indem Sie den Cluster upgraden. Dies ist die empfohlene Methode. Wenn Sie Ihren Cluster nicht aktualisieren können, haben Sie die Möglichkeit, eine On-Demand-CA-Rotation durchzufü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
Unterbrechung (Dauer) Keine Störung Mögliche Störung (unbekannt) Mögliche Störung (unbekannt) Mögliche Störung (unbekannt)
Erklärung Wenn die Nutzerarbeitslasten nicht mit den Komponenten der Kubernetes-Steuerungsebene kommunizieren, kommt es nicht zu Unterbrechungen. Wenn die Zertifizierungsstellen für Nutzercluster ablaufen, kommt es zu einer Störung. Wenn die Zertifizierungsstellen für Administratorcluster ablaufen, kommt es zu einer Störung. Wenn die Zertifizierungsstellen für Nutzercluster ablaufen, kommt es zu einer Störung.
Wiederherstellung —

Führen Sie die Schritte zur manuellen Verlängerung von Zertifikaten auf dem Nutzercluster aus.

Führen Sie die Schritte zur manuellen Verlängerung von Zertifikaten auf dem Nutzercluster aus.

Führen Sie die Schritte zur manuellen Verlängerung von Zertifikaten auf dem Nutzercluster aus.
Prävention Das Einrichten überwacht den Ablauf des Zertifikats. Ein Beispielmesswert kubelet_certificate_manager_server_expiration_seconds finden Sie in der Liste der Messwerte.

Fehler beim Upgrade

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

Wenn das Upgrade auf der Steuerungsebene des Nutzerclusters fehlschlägt, kommt es NICHT zu einer Unterbrechung der vorhandenen Arbeitslasten.

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, wenn auf den fehlerfreien Knoten zusätzliche Kapazität vorhanden ist.

 Das Upgrade wird beendet, wenn einer der Knoten der Steuerungsebene nicht aktualisiert werden kann. Der Cluster funktioniert weiterhin, wenn das Upgrade fehlschlägt, wenn der Nutzercluster mit Hochverfügbarkeit ausgestattet 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 fortsetzen. Das Upgrade kann wiederholt werden. Weitere Informationen finden Sie unter Upgradeprobleme diagnostizieren und fortsetzen.
Prävention — — Weitere Informationen finden Sie unter Sicherung vor dem Upgrade erstellen. Weitere Informationen finden Sie unter Sicherung vor dem Upgrade erstellen.

Nächste Schritte