Diese Reihe von Anleitungen richtet sich an IT-Administratoren und Operatoren, die moderne Anwendungsumgebungen bereitstellen, ausführen und verwalten möchten, die in Google Kubernetes Engine (GKE) ausgeführt werden. In diesen Anleitungen erfahren Sie, wie Sie Monitoring und Benachrichtigungen konfigurieren, Arbeitslasten skalieren und Fehler simulieren – und zwar anhand der Beispiel-Mikrodienstanwendung „Cymbal Bank“:
- Cluster erstellen und Beispielanwendung bereitstellen
- Mit Google Cloud Managed Service for Prometheus überwachen
- Arbeitslasten skalieren
- Fehler simulieren (diese Anleitung)
- Änderungsmanagement zentralisieren
Übersicht und Ziele
Anwendungen sollten Ausfälle und Fehler tolerieren können. So können Nutzer weiterhin auf Ihre Anwendungen zugreifen, auch wenn es ein Problem gibt. Die Beispielanwendung „Cymbal Bank“ ist so konzipiert, dass sie Fehler beheben und weiter ausgeführt werden kann, ohne dass Sie Fehlerbehebung und Korrekturen vornehmen müssen. Um diese Ausfallsicherheit zu gewährleisten, werden Compute-Knoten in regionalen GKE-Clustern auf Zonen verteilt und der Kubernetes-Controller reagiert automatisch auf Dienstprobleme im Cluster.
In dieser Anleitung erfahren Sie, wie Sie einen Fehler in Google Cloud simulieren und wie die Anwendungsdienste in Ihrem GKE-Cluster darauf reagieren. Sie lernen, wie Sie die folgenden Aufgaben ausführen:
- Verteilung von Knoten und Diensten prüfen
- Simulieren Sie einen Knoten- oder Zonenausfall.
- Prüfen Sie, ob die Dienste auf den verbleibenden Knoten weiterhin ausgeführt werden.
Verteilung von Knoten und Diensten prüfen
In Google Cloudist eine Region ein bestimmter geografischer Standort, an dem Sie Ihre Ressourcen hosten können. Regionen haben mindestens drei Zonen. Beispiel: Die Region us-central1 bezeichnet eine Region im Mittleren Westen der USA mit mehreren Zonen, z. B. us-central1-a, us-central1-b und us-central1-c. Zonen haben Netzwerkverbindungen mit hoher Bandbreite und niedriger Latenz zu anderen Zonen in derselben Region.
Zum Bereitstellen fehlertoleranter Anwendungen mit hoher Verfügbarkeit empfiehlt Google, die Anwendungen in mehreren Zonen und mehreren Regionen bereitzustellen. Dieser Ansatz dient als Schutzmaßnahme gegen unerwartete Ausfälle von Komponenten in einer einzelnen Zone oder Region.
Als Sie im ersten Tutorial Ihren GKE-Cluster erstellt haben, wurden einige Standardkonfigurationswerte verwendet. Standardmäßig werden in einem GKE-Cluster, in dem Autopilot verwendet wird, Knoten erstellt und ausgeführt, die sich über Zonen der von Ihnen angegebenen Region erstrecken. Das bedeutet, dass die Beispielanwendung „Cymbal Bank“ bereits in mehreren Zonen bereitgestellt wird, was vor unerwarteten Ausfällen schützt.
Prüfen Sie die Verteilung der Knoten in Ihrem GKE-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 sieht etwa so aus wie in der folgenden Beispielausgabe, in der 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 Dienste der Cymbal Bank-Beispielanwendung auf die Knoten Ihres GKE-Cluster:
kubectl get pods -o wideDie folgende Beispielausgabe zeigt, dass die Dienste auf Knoten im Cluster verteilt sind. Die Ausgabe aus dem vorherigen Schritt zeigt, wie die Knoten verteilt sind. Hier sehen Sie, dass die Dienste 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, sollen die Dienste 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.
Um in dieser Anleitung einen Ausfall zu simulieren, sperren Sie Knoten in einer Ihrer Zonen und beenden Sie per Drain. Mit diesem Ansatz wird simuliert, was passiert, wenn ein Knoten ausfällt oder eine ganze Zone ein Problem hat. Der Kubernetes-Controller sollte erkennen, dass einige Dienste nicht mehr verfügbar sind und auf Knoten in anderen Zonen neu gestartet werden müssen:
Knoten in einer der Zonen sperren und per Drain beenden. Im folgenden Beispiel werden die beiden Knoten in
us-central1-aals Ziel festgelegt:kubectl drain scalable-apps-pool-2-node1 \ --delete-emptydir-data --ignore-daemonsets kubectl drain scalable-apps-pool-2-node2 \ --delete-emptydir-data --ignore-daemonsetsMit diesem Befehl werden die Knoten als „nicht planbar“ markiert, sodass keine Pods mehr auf diesen Knoten ausgeführt werden können. Kubernetes plant Pods auf andere Knoten in funktionierenden Zonen um.
Simulierte Reaktion auf Fehler prüfen
In einem früheren Teil dieser Reihe haben Sie erfahren, wie Sie die verwaltete Prometheus-Instanz für Ihren GKE-Cluster so konfigurieren, dass sie einige der Dienste überwacht und bei Problemen Benachrichtigungen generiert. 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 bei Problemen benachrichtigt und sich automatisch an Laständerungen oder Fehler anpassen kann.
Ihr GKE-Cluster reagiert automatisch auf den simulierten Ausfall. Alle Dienste auf betroffenen Knoten werden auf verbleibenden Knoten neu gestartet.
Prüfen Sie noch einmal die Verteilung der Knoten in Ihrem GKE-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 sieht etwa so aus wie in der folgenden Beispielausgabe, in der die Knoten jetzt nur noch 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 die Dienste neu auf die verfügbaren Knoten. Alle Dienste sollten weiterhin ausgeführt werden.
Prüfen Sie die Verteilung der Dienste der Cymbal Bank-Beispielanwendung auf die Knoten Ihres GKE-Cluster:
kubectl get pods -o wideDie folgende Beispielausgabe zeigt, dass die Dienste auf die verbleibenden Knoten im Cluster verteilt sind. Die Ausgabe aus dem vorherigen Schritt zeigt, wie die Knoten verteilt sind. Die Dienste werden jetzt nur noch in zwei Zonen in der Region ausgeführt:
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 die
AGEder Dienste an. In der vorherigen Beispielausgabe sind einige der Dienste jünger als andere in der Beispielanwendung von Cymbal Bank. Diese neueren Dienste wurden zuvor auf einem der Knoten ausgeführt, auf dem Sie einen Fehler simuliert haben. Der Kubernetes-Controller hat diese Dienste auf verfügbaren Knoten neu gestartet.
In der Praxis 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-Cluster mit erhöhter Last reagiert, wenn nur zwei Zonen mit der Region verfügbar sind. Der Cluster sollte mit den beiden verbleibenden Zonen skaliert werden.