GKE on VMware wurde entwickelt, um den Umfang von Fehlern zu begrenzen und Funktionen zu priorisieren, die für die Geschäftskontinuität wichtig 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 zu priorisieren, die Sie beheben sollten.
Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an Cloud Customer Care.Die Hauptfunktion von GKE on VMware umfasst die folgenden Kategorien:
- Arbeitslasten ausführen: Vorhandene Arbeitslasten können weiterhin ausgeführt werden. Dies ist der wichtigste Aspekt, wenn es darum geht, die Geschäftskontinuität aufrechtzuerhalten. Selbst wenn in Ihrem Cluster ein Problem auftritt, werden die vorhandenen Arbeitslasten unter Umständen weiterhin ohne Unterbrechung 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, auch wenn im Cluster ein Problem vorliegt.
- Nutzercluster verwalten: Sie können Knoten verwalten sowie Nutzercluster aktualisieren, aktualisieren und löschen. Das ist weniger wichtig als der Anwendungslebenszyklus. Wenn auf den vorhandenen Knoten Kapazität verfügbar ist, wirkt sich dies nicht auf die Nutzerarbeitslasten aus, wenn Nutzercluster nicht geändert werden können.
- Administratorcluster verwalten: Sie können den Administratorcluster aktualisieren und upgraden. Dies ist die am wenigsten wichtige Überlegung, da der Administratorcluster keine Nutzerarbeitslasten hostet. Wenn bei Ihrem Administratorcluster ein Problem auftritt, werden Ihre Anwendungsarbeitslasten ohne Unterbrechung weiter ausgeführt.
In den folgenden Abschnitten werden diese Kategorien von Hauptfunktionen verwendet, um die Auswirkungen bestimmter Arten von Fehlerszenarien zu beschreiben.
Fehlermodi
Die folgenden Arten von Fehlern können die Leistung von GKE on VMware-Clustern beeinträchtigen.
ESXi-Hostfehler
In diesem Fehlerszenario funktioniert ein ESXi-Host, auf dem VM-Instanzen ausgeführt werden, die Kubernetes-Knoten hosten, möglicherweise nicht mehr oder wird netzwerkpartitioniert.
| Arbeitslasten ausführen | Arbeitslasten verwalten | Nutzercluster verwalten | Administratorcluster verwalten | |
|---|---|---|---|---|
| Störungen | Mögliche Unterbrechung und automatische Wiederherstellung | Mögliche Unterbrechung und automatische Wiederherstellung | Störung und automatische Wiederherstellung | Störung und automatische Wiederherstellung |
| Erläuterung | Die Pods, die auf den vom ausgefallenen Host gehosteten VMs ausgeführt werden, werden unterbrochen und automatisch auf andere fehlerfreie VMs verschoben. Wenn Nutzeranwendungen freie Arbeitslastkapazität haben und auf mehrere Knoten verteilt sind, kann die Unterbrechung von Clients, die Wiederholungsversuche implementieren, nicht beobachtet werden. |
Wenn der Hostfehler sich auf die VM der Steuerungsebene in einem Nutzercluster ohne Hochverfügbarkeit oder auf mehreren VMs einer Steuerungsebene in einem Hochverfügbarkeitsnutzercluster auswirkt, kommt es zu einer Unterbrechung. | Wenn der Hostfehler die VM der Steuerungsebene oder die Worker-VMs im Administratorcluster beeinträchtigt, kommt es zu einer Unterbrechung. | Wenn der Hostfehler die VM der Steuerungsebene im Administratorcluster beeinträchtigt, kommt es zu einer Unterbrechung. |
| Wiederherstellung | vSphere HA startet die VMs automatisch auf fehlerfreien Hosts neu. | vSphere HA startet die VMs automatisch auf fehlerfreien Hosts neu. | vSphere HA startet die VMs automatisch auf fehlerfreien Hosts neu. | vSphere HA startet die VMs automatisch auf fehlerfreien Hosts neu. |
| Prävention | Stellen Sie Arbeitslasten auf Hochverfügbarkeitsweise bereit, um Unterbrechungen zu minimieren. | Verwenden Sie HA-Nutzercluster, um die Möglichkeit einer Unterbrechung zu minimieren. | — | — |
VM-Fehler
In diesem Fehlerszenario kann eine VM unerwartet gelöscht, ein Bootlaufwerk beschädigt oder eine VM aufgrund von Betriebssystemproblemen manipuliert werden.
| Arbeitslasten ausführen | Arbeitslasten verwalten | Nutzercluster verwalten | Administratorcluster verwalten | |
|---|---|---|---|---|
| Störungen | Mögliche Unterbrechung und automatische Wiederherstellung | Mögliche Unterbrechung und automatische Wiederherstellung | Störung und automatische/manuelle Wiederherstellung | Störung und manuelle Wiederherstellung |
| Erläuterung | Die Pods, die auf den fehlgeschlagenen Worker-VMs ausgeführt werden, werden unterbrochen und von Kubernetes automatisch auf andere fehlerfreie VMs verschoben. Wenn Nutzeranwendungen freie Arbeitslastkapazität haben und auf mehrere Knoten verteilt sind, kann die Unterbrechung von Clients, die Wiederholungsversuche implementieren, nicht beobachtet werden. |
Wenn die VM der Steuerungsebene in einem Nutzercluster ohne Hochverfügbarkeit oder in mehr als einer Steuerung-VM in einem HA-Nutzercluster fehlschlägt, kommt es zu einer Unterbrechung. | Wenn die VM der Steuerungsebene oder die Worker-VMs im Administratorcluster fehlschlagen, besteht eine Unterbrechung. | Wenn die VM der Steuerungsebene im Administratorcluster fehlschlägt, kommt es zu einer Unterbrechung. |
| Wiederherstellung | Die ausgefallene VM wird automatisch wiederhergestellt, wenn im Nutzercluster die automatische Knotenreparatur aktiviert ist. | Die ausgefallene VM wird automatisch wiederhergestellt, wenn die automatische Knotenreparatur im Administratorcluster aktiviert ist. | Die ausgefallene Worker-VM im Administratorcluster wird automatisch wiederhergestellt, wenn die automatische Knotenreparatur im Administratorcluster aktiviert ist. Informationen zum Wiederherstellen der VM der Steuerungsebene des Administratorclusters finden Sie unter VM der Steuerungsebene des Administratorclusters reparieren. |
Informationen zum Wiederherstellen der VM der Steuerungsebene des Administratorclusters finden Sie unter VM der Steuerungsebene des Administratorclusters reparieren. |
| Prävention | Stellen Sie Arbeitslasten auf Hochverfügbarkeitsweise bereit, um Unterbrechungen zu minimieren. | Verwenden Sie HA-Nutzercluster, um die Möglichkeit einer Unterbrechung zu minimieren. | — | — |
Speicherfehler
In diesem Fehlerszenario kann der Inhalt einer VMDK-Datei aufgrund eines nicht effizienten Herunterfahrens einer VM beschädigt sein oder ein Datenspeicherfehler kann zum Verlust von etcd-Daten und PersistentVolumes (PVs) führen.
etcd-Fehler
| Arbeitslasten ausführen | Arbeitslasten verwalten | Nutzercluster verwalten | Administratorcluster verwalten | |
|---|---|---|---|---|
| Störungen | Keine Unterbrechung | Mögliche Unterbrechung und manuelle Wiederherstellung | Störung und manuelle Wiederherstellung | Störung und manuelle Wiederherstellung |
| Erläuterung | — | Wenn der etcd-Speicher in einem Nicht-HA-Nutzercluster oder in einem etcd-Replikat in einem HA-Nutzercluster fehlschlägt, kommt es zu einer Unterbrechung. | Wenn der etcd-Speicher in einem Nicht-HA-Nutzercluster oder in einem etcd-Replikat in einem HA-Nutzercluster fehlschlägt, kommt es zu einer Unterbrechung. Wenn das etcd-Replikat in einem Administratorcluster fehlschlägt, kommt es zu einer Unterbrechung. |
Wenn das etcd-Replikat in einem Administratorcluster fehlschlägt, kommt es zu einer Unterbrechung. |
| Prävention | — | GKE on VMware bietet einen manuellen Prozess zur Wiederherstellung nach einem Fehler. | GKE on VMware bietet einen manuellen Prozess zur Wiederherstellung nach einem Fehler. | GKE on VMware bietet einen manuellen Prozess zur Wiederherstellung nach einem Fehler. |
PV-Fehler bei der Nutzeranwendung
| Arbeitslasten ausführen | Arbeitslasten verwalten | Nutzercluster verwalten | Administratorcluster verwalten | |
|---|---|---|---|---|
| Störungen | Mögliche Störung | Keine Unterbrechung | Keine Unterbrechung | Keine Unterbrechung |
| Erläuterung | Dies betrifft die Arbeitslasten, die das fehlgeschlagene PV verwenden. Stellen Sie Arbeitslasten auf Hochverfügbarkeitsweise bereit, um Unterbrechungen zu minimieren. |
— | — | — |
Fehler beim Load-Balancer
In diesem Fehlerszenario kann sich ein Ausfall des Load-Balancers auf Nutzerarbeitslasten auswirken, die Dienste vom Typ LoadBalancer verfügbar machen.
| Arbeitslasten ausführen | Arbeitslasten verwalten | Nutzercluster verwalten | Administratorcluster verwalten | |
|---|---|---|---|---|
| Störung und manuelle Wiederherstellung | ||||
| Erläuterung |
Es dauert einige Sekunden, bis der Standby-Load-Balancer die VIP-Verbindung zur Administratorsteuerung wiederhergestellt. Die Dienstunterbrechung kann bei Verwendung von Seesaw bis zu 2 Sekunden und bei F5 bis zu 300 Sekunden dauern. Die Dauer der Failover-Unterbrechung von MetalLB wächst mit zunehmender Anzahl der Load-Balancer-Knoten. Bei weniger als 5 Knoten dauert die Unterbrechung innerhalb von 10 Sekunden. |
|||
| Wiederherstellung | Seesaw HA erkennt den Fehler automatisch und führt ein Failover mit der Sicherungsinstanz aus. GKE on VMware bietet einen manuellen Prozess zur Wiederherstellung nach einem Seesaw-Fehler. |
|||
Defekten Cluster wiederherstellen
In den folgenden Abschnitten wird beschrieben, wie Sie einen fehlerhaften Cluster wiederherstellen.
Wiederherstellung nach ESXi-Hostfehlern
GKE on VMware nutzt vSphere HA, um die Wiederherstellung nach einem ESXi-Hostfehler zu ermöglichen. vSphere HA kann ESXi-Hosts kontinuierlich überwachen und die VMs auf anderen Hosts bei Bedarf automatisch neu starten. Dies ist für Nutzer von GKE on VMware transparent.
Wiederherstellung nach VM-Fehlern
Zu den VM-Fehlern gehören:
Unerwartetes Löschen einer VM.
Beschädigung des VM-Bootlaufwerks, z. B. ein Bootlaufwerk, das aufgrund von Spam-Journallogs schreibgeschützt wird.
VM-Startfehler aufgrund von Problemen mit dem Laufwerk oder der Netzwerkeinrichtung mit geringer Leistung, z. B. wenn eine VM nicht gestartet werden kann, weil ihr keine IP-Adresse zugewiesen werden kann.
Docker-Overlay-Dateisystem beschädigt.
Verlust der VM zur Administratorsteuerungsebene aufgrund eines Upgradefehlers.
Probleme mit dem Betriebssystem.
GKE on VMware bietet einen automatischen Wiederherstellungsmechanismus für die Administrator-Add-on-Knoten, Nutzersteuerungsebenen und Nutzerknoten. Diese Funktion zur automatischen Knotenreparatur kann pro Administratorcluster und Nutzercluster aktiviert werden.
Die VM zur Administratorsteuerung ist speziell so ausgelegt, dass sie nicht von einem Kubernetes-Cluster verwaltet wird. Die Verfügbarkeit wirkt sich nicht auf die Geschäftskontinuität aus. Wenn Sie VM-Fehler auf der Administrator-Steuerungsebene wiederherstellen möchten, wenden Sie sich an Cloud Customer Care.
Wiederherstellung nach Speicherfehlern
Einige der Speicherfehler können durch vSphere-HA und vSAN behoben werden, ohne GKE on VMware zu beeinträchtigen. Bestimmte Speicherfehler können jedoch auf vSphere-Ebene auftreten, die zu Datenbeschädigungen oder ‐verlusten bei verschiedenen GKE on VMware-Komponenten führen.
Die zustandsorientierten Informationen zu einem Cluster und Nutzerarbeitslasten werden an folgenden Orten gespeichert:
- etcd: Jeder Cluster (Administrator- und Nutzercluster) hat eine etcd-Datenbank, in der der Status (Kubernetes-Objekte) des Clusters gespeichert ist.
- PersistentVolumes: Werden sowohl von Systemkomponenten als auch von Nutzerarbeitslasten verwendet.
Wiederherstellung nach etcd-Datenschäden oder -verlust
Etcd ist die Datenbank, die in Kubernetes zum Speichern aller Clusterstatus verwendet wird, einschließlich des Nutzeranwendungsmanifests. Die Lebenszyklusvorgänge der Anwendung würden nicht mehr funktionieren, wenn die etcd-Datenbank des Nutzerclusters beschädigt oder verloren geht. Die Lebenszyklusvorgänge des Nutzerclusters würden nicht mehr funktionieren, wenn die etcd-Datenbank des Administratorclusters beschädigt oder verloren geht.
etcd bietet keinen zuverlässigen integrierten Mechanismus zur Erkennung von Datenkorruption. Sehen Sie sich die Logs der etcd-Pods an, wenn Sie vermuten, dass die etcd-Daten beschädigt sind oder verloren gegangen.
Wenn ein etcd Pod mit dem Status "pending/error/crashe loop" nicht immer beschädigt ist, bedeutet das nicht, dass die etcd-Daten beschädigt sind oder verloren gehen. Dies kann an den Fehlern auf den VMs liegen, auf denen die etcd-Pods gehostet werden. Sie sollten die etcd-Wiederherstellung nur für Datenkorrelation oder Verlust durchführen.
Damit Sie in einem früheren Clusterstatus Daten durch beschädigte oder beschädigte Daten wiederherstellen können, müssen die etcd-Daten nach jedem Lebenszyklusvorgang im Cluster gesichert werden (z. B. Erstellen, Aktualisieren oder Aktualisieren). , um die Option zu aktivieren. Informationen zum Sichern der etcd-Daten finden Sie unter Administratorcluster sichern und Nutzercluster sichern.
Durch die Wiederherstellung von etcd-Daten wird der Cluster in einen früheren Zustand gesetzt. Wenn vor der Bereitstellung einer Anwendung eine Sicherung erstellt wird und diese Sicherung dann zum Wiederherstellen des Clusters verwendet wird, wird die kürzlich bereitgestellte Anwendung nicht im wiederhergestellten Cluster ausgeführt. Wenn Sie beispielsweise den etcd-Snapshot eines Administratorclusters verwenden, der vor dem Erstellen eines Nutzerclusters Snapshot erstellt wurde, wird die Steuerungsebene des Nutzerclusters im wiederhergestellten Administratorcluster entfernt. Daher empfehlen wir, den Cluster nach jedem kritischen Clustervorgang zu sichern.
Die Beschädigung oder Verlust von etcd-Daten können in den folgenden Szenarien auftreten:
Ein einzelner Knoten eines etcd-Clusters (drei Nutzer) wird aufgrund von Datenkorruption oder Verlust dauerhaft heruntergefahren. In diesem Fall ist nur ein einzelner Knoten fehlerhaft und das etcd-Quorum ist noch vorhanden. Dieses Szenario kann in einem Hochverfügbarkeitscluster auftreten, bei dem die Daten eines der etcd-Replikate beschädigt werden oder verloren gehen. Das Problem kann ohne Datenverlust behoben werden, indem das fehlgeschlagene etcd-Replikat durch ein neues im bereinigten Zustand ersetzt wird. Weitere Informationen finden Sie unter Fehlgeschlagenes etcd-Replikat ersetzen.
Zwei Knoten eines etcd-Clusters (drei Nutzercluster) werden aufgrund von Datenfehler oder Verlusten dauerhaft beschädigt. Das Quorum geht verloren, sodass es nicht hilft, die fehlgeschlagenen etcd-Replikate durch neue zu ersetzen. Der Clusterstatus muss aus Sicherungsdaten wiederhergestellt werden. Weitere Informationen finden Sie unter Nutzercluster aus einer Sicherung (HA) wiederherstellen.
Ein etcd-Cluster mit einem Knoten (Administratorcluster oder Nicht-HA-Nutzercluster) wird aufgrund von Datenkorruption oder Verlust dauerhaft entfernt. Das Quorum geht verloren, daher müssen Sie einen neuen Cluster aus der Sicherung erstellen. Weitere Informationen finden Sie unter Nutzercluster aus einer Sicherung (nicht-HA) wiederherstellen.
Wiederherstellung nach Datenverlust oder Verlust der Nutzeranwendung
Sie können bestimmte Speicherlösungen von Partnern verwenden, um PersistentVolumes der Nutzeranwendung zu sichern und wiederherzustellen. Eine Liste der Speicherpartner, die für GKE on VMware qualifiziert sind, finden Sie unter Anthos Ready Storage-Partner.
Wiederherstellung nach Load-Balancer-Fehlern
Bei einem gebündelten Seesaw-Load-Balancer können Sie eine Wiederherstellung nach Fehlern ausführen, indem Sie den Load-Balancer neu erstellen. Um den Load-Balancer neu zu erstellen, führen Sie ein Upgrade der Seesaw auf dieselbe Version durch, wie unter Upgrade des Load-Balancers für Ihren Administratorcluster ausführen beschrieben.
Wenn Fehler beim Load-Balancer des Administratorclusters auftreten, ist die Steuerungsebene möglicherweise nicht erreichbar. Führen Sie das Upgrade auf der VM der Administrator-Steuerungsebene aus, auf der Sie Zugriff auf die Steuerungsebene haben.
Für integrierte Load-Balancer (F5) wenden Sie sich an den F5-Support.
Für gebündelte MetalLB-Load-Balancer werden Clusterknoten als Load-Balancer verwendet. Bei Load-Balancer-Problemen wird keine automatische Knotenreparatur ausgelöst. Sie können den Knoten mit dem manuellen Prozess reparieren.