Diese Reihe von Anleitungen richtet sich an IT-Administratoren und Operatoren, die moderne Anwendungsumgebungen in Google Kubernetes Engine (GKE) Enterprise Edition bereitstellen, ausführen und verwalten möchten. Im weiteren Verlauf dieser Anleitungen erfahren Sie, wie Sie mit der Beispiel-Mikrodienstanwendung "Cymbal Bank" Monitoring und Benachrichtigungen konfigurieren, Arbeitslasten skalieren und Fehler simulieren:
- Cluster erstellen und Beispielanwendung bereitstellen
- Mit Google Cloud Managed Service for Prometheus überwachen
- Arbeitslasten skalieren
- Fehler simulieren (diese Anleitung)
Übersicht und Ziele
Anwendungen sollten Ausfälle und Ausfälle tolerieren. Mit dieser Möglichkeit können Nutzer auch dann auf Ihre Anwendungen zugreifen, wenn ein Problem auftritt. Die Beispielanwendung Cymbal Bank ist so konzipiert, dass sie Fehler bewältigen und weiterhin ausgeführt wird, ohne dass Sie Probleme beheben müssen. Um diese Ausfallsicherheit zu gewährleisten, verteilen regionale GKE-Cluster Rechenknoten auf Zonen. Der Kubernetes-Controller reagiert automatisch auf Dienstprobleme innerhalb des Clusters.
In dieser Anleitung erfahren Sie, wie Sie einen Fehler in Google Cloud simulieren und wie die Anwendungsdienste in Ihrem Cluster der Google Kubernetes Engine (GKE) Enterprise Edition reagieren. Sie erfahren, wie Sie die folgenden Aufgaben ausführen:
- Prüfen Sie die Verteilung von Knoten und Services.
- Einen Knoten- oder Zonenfehler simulieren.
- Prüfen Sie, ob Services auf den verbleibenden Knoten weiterhin ausgeführt werden.
Kosten
Wenn Sie GKE Enterprise aktivieren und die Beispielanwendung "Cymbal Bank" für diese Reihe von Anleitungen bereitstellen, fallen für GKE Enterprise in Google Cloud Gebühren pro Cluster an. Weitere Informationen finden Sie auf der Preisseite, bis Sie GKE Enterprise deaktivieren oder das Projekt löschen.
Sie sind auch für andere Google Cloud-Kosten verantwortlich, die während der Ausführung der Beispielanwendung "Cymbal Bank" anfallen, z. B. Gebühren für Compute Engine-VMs.
Hinweise
Für das Simulieren eines Fehlers müssen Sie die erste Anleitung befolgen, um einen GKE-Cluster zu erstellen, der Autopilot verwendet, und die auf Mikrodiensten basierende Cymbal Bank bereitzustellen.
Wir empfehlen Ihnen, diese Anleitungen für Cymbal Bank der Reihe nach durchzugehen. Mit den Anleitungen lernen Sie neue Fähigkeiten kennen und nutzen zusätzliche Google Cloud-Produkte und -Dienste.
Verteilung der Knoten und Services prüfen
Auf der GCP ist eine Region ein bestimmter geografischer Standort, an dem Sie Ihre Ressourcen hosten können. Regionen haben mindestens drei Zonen. Beispiel:us-central1 Region bezeichnet eine Region im Mittleren Westen der USA mit mehreren Zonen, z. B.:us-central1-a ,us-central1-b , undus-central1-c “ Zonen haben Netzwerkverbindungen mit hoher Bandbreite und niedriger Latenz zu anderen Zonen in derselben Region.
Zum Bereitstellen fehlertoleranter Anwendungen mit Hochverfügbarkeit empfiehlt Google, die Anwendungen in mehreren Zonen und mehreren Regionen bereitzustellen. Dieser Ansatz trägt zum Schutz vor unerwarteten Ausfällen von Komponenten in einer Zone oder Region bei.
Beim Erstellen Ihres GKE Enterprise-Clusters in der ersten Anleitung wurden einige Standardkonfigurationswerte verwendet. Standardmäßig erstellt und führt ein GKE Enterprise-Cluster, der Autopilot verwendet, Knoten aus, die sich über Zonen der von Ihnen angegebenen Region erstrecken. Dieser Ansatz bedeutet, dass die Beispielanwendung "Cymbal Bank" bereits über mehrere Zonen bereitgestellt wird. Dadurch werden unerwartete Ausfälle geschützt.
Prüfen Sie die Verteilung der Knoten in Ihrem GKE Enterprise-Cluster:
kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'Das Ergebnis ähnelt der folgenden Beispielausgabe, die zeigt, dass die Knoten auf alle drei Zonen in der Region verteilt sind:
NAME ZONE INT_IP scalable-apps-pool-2-node5 us-central1-c 10.148.0.6 scalable-apps-pool-2-node6 us-central1-c 10.148.0.7 scalable-apps-pool-2-node2 us-central1-a 10.148.0.8 scalable-apps-pool-2-node1 us-central1-a 10.148.0.9 scalable-apps-pool-2-node3 us-central1-b 10.148.0.5 scalable-apps-pool-2-node4 us-central1-b 10.148.0.4Prüfen Sie die Verteilung der Cymbal Bank-Beispielanwendungsdienste auf Ihren GKE Enterprise-Clusterknoten:
kubectl get pods -o wideDie folgende Beispielausgabe zeigt, dass die Services auf die Knoten im Cluster verteilt sind. Diese Ausgabe zeigt aus dem vorherigen Schritt, wie die Knoten verteilt werden, und zeigt, dass die Services zonenübergreifend in der Region ausgeführt werden:
NAME READY STATUS RESTARTS AGE IP NODE accounts-db-0 1/1 Running 0 6m30s 10.28.1.5 scalable-apps-pool-2-node3 balancereader-7dc7d9ff57-shwg5 1/1 Running 0 6m30s 10.28.5.6 scalable-apps-pool-2-node1 contacts-7ddc76d94-qv4x5 1/1 Running 0 6m29s 10.28.4.6 scalable-apps-pool-2-node2 frontend-747b84bff4-xvjxq 1/1 Running 0 6m29s 10.28.3.6 scalable-apps-pool-2-node6 ledger-db-0 1/1 Running 0 6m29s 10.28.5.7 scalable-apps-pool-2-node1 ledgerwriter-f6cc7889d-mttmb 1/1 Running 0 6m29s 10.28.1.6 scalable-apps-pool-2-node3 loadgenerator-57d4cb57cc-7fvrc 1/1 Running 0 6m29s 10.28.4.7 scalable-apps-pool-2-node2 transactionhistory-5dd7c7fd77-cmc2w 1/1 Running 0 6m29s 10.28.3.7 scalable-apps-pool-2-node6 userservice-cd5ddb4bb-zfr2g 1/1 Running 0 6m28s 10.28.5.8 scalable-apps-pool-2-node1
Ausfall simulieren
Google entwickelt Zonen, um das Risiko von korrelierten Ausfällen zu minimieren, die durch Ausfälle der physischen Infrastruktur, wie Strom, Kühlung oder Netzwerke verursacht werden. Es können jedoch unerwartete Probleme auftreten. Wenn ein Knoten oder eine Zone nicht mehr verfügbar ist, möchten Sie, dass Services weiterhin auf anderen Knoten oder in Zonen in derselben Region ausgeführt werden.
Der Kubernetes-Controller überwacht den Status der Knoten, Dienste und Deployments in Ihrem Cluster. Bei einem unerwarteten Ausfall startet der Controller die betroffenen Ressourcen neu und der Traffic wird an funktionierende Knoten weitergeleitet.
Wenn Sie in dieser Anleitung einen Ausfall simulieren möchten, sperren und leeren Sie Knoten in einer Ihrer Zonen. Dieser Ansatz simuliert, was geschieht, wenn ein Knoten ausfällt oder wenn eine ganze Zone ein Problem hat. Der Kubernetes-Controller sollte erkennen, dass einige Services nicht mehr verfügbar sind und auf Knoten in anderen Zonen neu gestartet werden muss:
Knoten in einer der Zonen sperren und per Drain beenden. Das folgende Beispiel bezieht sich auf die beiden Knoten in
us-central1-a:kubectl drain scalable-apps-pool-2-node1 \ --delete-emptydir-data --ignore-daemonsets kubectl drain scalable-apps-pool-2-node2 \ --delete-emptydir-data --ignore-daemonsetsDieser Befehl markiert die Knoten als nicht mehr planbar, sodass Pods auf diesen Knoten nicht mehr ausgeführt werden können. Kubernetes weist Pods anderen Knoten in funktionierenden Zonen zu.
Simulierte Fehlerantwort prüfen
In einer vorherigen Anleitung dieser Reihe haben Sie gelernt, wie Sie die verwaltete Prometheus-Instanz für Ihren GKE Enterprise-Cluster konfigurieren, um einige der Dienste zu überwachen und Benachrichtigungen zu generieren. wenn ein Problem auftritt. Wenn Pods auf Knoten in der Zone ausgeführt wurden, in der Sie einen Ausfall simuliert haben, erhalten Sie Slack-Benachrichtigungen von den von Prometheus generierten Benachrichtigungen. Dieses Verhalten zeigt, wie Sie eine moderne Anwendungsumgebung erstellen können, die den Zustand Ihrer Deployments überwacht, Sie benachrichtigt, wenn ein Problem auftritt, und sich automatisch an Laständerungen oder Fehler anpassen kann.
Ihr GKE Enterprise-Cluster reagiert automatisch auf den simulierten Ausfall. Alle Dienste auf den betroffenen Knoten werden auf den verbleibenden Knoten neu gestartet.
Prüfen Sie die Verteilung der Knoten in Ihrem GKE Enterprise-Cluster noch einmal:
kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'Das Ergebnis ähnelt der folgenden Beispielausgabe, die zeigt, dass die Knoten jetzt nur auf zwei der Zonen in der Region verteilt sind:
NAME ZONE INT_IP scalable-apps-pool-2-node5 us-central1-c 10.148.0.6 scalable-apps-pool-2-node6 us-central1-c 10.148.0.7 scalable-apps-pool-2-node3 us-central1-b 10.148.0.5 scalable-apps-pool-2-node4 us-central1-b 10.148.0.4Der Kubernetes-Controller erkennt, dass zwei der Knoten nicht mehr verfügbar sind, und verteilt Services auf die verfügbaren Knoten neu. Alle Services sollten weiterhin ausgeführt werden.
Prüfen Sie die Verteilung der Cymbal Bank-Beispielanwendungsdienste auf Ihren GKE Enterprise-Clusterknoten:
kubectl get pods -o wideDie folgende Beispielausgabe zeigt, dass die Services auf die verbleibenden Knoten im Cluster verteilt sind. Diese Ausgabe zeigt aus dem vorherigen Schritt, wie die Knoten verteilt werden, dass die Services jetzt nur in zwei Zonen der Region ausgeführt werden:
NAME READY STATUS RESTARTS AGE IP NODE accounts-db-0 1/1 Running 0 28m 10.28.1.5 scalable-apps-pool-2-node3 balancereader-7dc7d9ff57-shwg5 1/1 Running 0 9m21s 10.28.5.6 scalable-apps-pool-2-node5 contacts-7ddc76d94-qv4x5 1/1 Running 0 9m20s 10.28.4.6 scalable-apps-pool-2-node4 frontend-747b84bff4-xvjxq 1/1 Running 0 28m 10.28.3.6 scalable-apps-pool-2-node6 ledger-db-0 1/1 Running 0 9m24s 10.28.5.7 scalable-apps-pool-2-node3 ledgerwriter-f6cc7889d-mttmb 1/1 Running 0 28m 10.28.1.6 scalable-apps-pool-2-node3 loadgenerator-57d4cb57cc-7fvrc 1/1 Running 0 9m21s 10.28.4.7 scalable-apps-pool-2-node5 transactionhistory-5dd7c7fd77-cmc2w 1/1 Running 0 28m 10.28.3.7 scalable-apps-pool-2-node6 userservice-cd5ddb4bb-zfr2g 1/1 Running 0 9m20s 10.28.5.8 scalable-apps-pool-2-node1Sehen Sie sich den
AGEder Services an. In der vorherigen Beispielausgabe haben einige der Services ein jüngeres Alter als andere in der Beispielanwendung "Cymbal Bank". Diese jüngeren Dienste wurden zuvor auf einem der Knoten ausgeführt, auf denen Sie den Ausfall simuliert haben. Der Kubernetes-Controller hat diese Services auf den verfügbaren Knoten neu gestartet.
In einem realen Szenario würden Sie das Problem beheben oder warten, bis das zugrunde liegende Wartungsproblem behoben ist. Wenn Sie Prometheus so konfiguriert haben, dass Slack-Nachrichten basierend auf Benachrichtigungen gesendet werden, werden diese Benachrichtigungen angezeigt. Optional können Sie auch die Schritte aus der vorherigen Anleitung zum Skalieren von Ressourcen wiederholen, um zu sehen, wie Ihr GKE Enterprise-Cluster mit erhöhter Last reagiert, wenn nur zwei Zonen mit der Region verfügbar sind. Der Cluster sollte mit den beiden verfügbaren verbleibenden Zonen vertikal skaliert werden.
Bereinigen
Löschen Sie das von Ihnen erstellte Projekt, damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden.
- Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.
- Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
- Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.
Nächste Schritte
Bevor Sie eine eigene GKE Enterprise-Clusterumgebung erstellen, ähnlich der, die Sie in dieser Reihe von Anleitungen gelernt haben, lesen Sie einige der Produktionsaspekte.