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)
Übersicht und Ziele
Anwendungen sollten Ausfälle und Fehler tolerieren können. So können Nutzer auch bei Problemen weiterhin auf Ihre Anwendungen zugreifen. Die Beispielanwendung „Cymbal Bank“ ist so konzipiert, dass sie Fehler beheben und weiter ausgeführt werden kann, ohne dass Sie Fehler beheben müssen. Um diese Ausfallsicherheit zu gewährleisten, verteilen GKE-Regionalcluster Compute-Knoten auf Zonen und der Kubernetes-Controller reagiert automatisch auf Dienstprobleme innerhalb des Clusters.
In dieser Anleitung erfahren Sie, wie Sie einen Ausfall in Google Cloud simulieren und sehen, wie die Anwendungsdienste in Ihrem GKE-Cluster reagieren. Erfahren Sie, wie Sie die folgenden Aufgaben ausführen:
- Prüfen Sie die Verteilung von Knoten und Diensten.
- Einen Knoten- oder Zonenfehler simulieren.
- Prüfen Sie, ob die Dienste weiterhin auf den verbleibenden Knoten ausgeführt werden.
Kosten
Wenn Sie GKE aktivieren und die Beispielanwendung „Cymbal Bank“ für diese Reihe von Anleitungen bereitstellen, fallen für GKE in Google Cloud Gebühren pro Cluster an. Weitere Informationen finden Sie auf der Preisseite, bis Sie GKE deaktivieren oder das Projekt löschen.
Sie sind auch für andere Google Cloud-Kosten verantwortlich, die während der Ausführung der CDN-Beispielanwendung entstehen, z. B. Gebühren für Compute Engine-VMs.
Vorbereitung
Um zu erfahren, wie Sie einen Ausfall simulieren, müssen Sie die erste Anleitung ausführen, um einen GKE-Cluster zu erstellen, der Autopilot verwendet und die auf Mikrodiensten basierende Cymbal Bank-Beispielanwendung bereitstellt.
Wir empfehlen, diese Anleitungen für skalierbare Anwendungen der Reihe nach durchzugehen. Während Sie die einzelnen Anleitungen durcharbeiten, lernen Sie neue Fähigkeiten kennen und nutzen zusätzliche Google Cloud-Produkte und -Dienste.
Verteilung von Knoten und Diensten prüfen
In Google Cloud 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 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 Zone oder Region.
Beim Erstellen des GKE-Clusters in der ersten Anleitung wurden einige Standardkonfigurationswerte verwendet. Standardmäßig erstellt ein GKE-Cluster, der Autopilot verwendet, Knoten, die sich über Zonen der von Ihnen angegebenen Region erstrecken, und führt diese aus. Bei diesem Ansatz wird die Beispielanwendung "Cymbal Bank" bereits über mehrere Zonen bereitgestellt, wodurch unerwartete Ausfälle geschützt werden.
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 ä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-Clusterknoten:
kubectl get pods -o wideDie folgende Beispielausgabe zeigt, dass die Dienste auf Knoten im Cluster verteilt sind. Diese Ausgabe zeigt, dass die Services in zonenübergreifend in der Region ausgeführt werden, um im vorherigen Schritt zu prüfen, wie die Knoten verteilt 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 Dienste weiterhin auf anderen Knoten oder in Zonen in derselben Region ausgeführt werden.
Der Kubernetes-Controller überwacht den Status der Knoten, Dienste und Bereitstellungen 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 und beenden Sie Knoten in einer Ihrer Zonen. Mit diesem Ansatz wird simuliert, was passiert, wenn ein Knoten ausfällt oder ein Problem in einer ganzen Zone auftritt. 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-aausgerichtet: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 mehr planbar markiert, sodass Pods nicht mehr auf diesen Knoten ausgeführt werden können. Kubernetes verschiebt Pods auf andere Knoten in funktionierenden Zonen.
Simulierte Fehlerantwort prüfen
In einem vorherigen Tutorial dieser Reihe haben Sie gelernt, wie Sie die verwaltete Prometheus-Instanz für Ihren GKE-Cluster konfigurieren, um einige der Dienste zu überwachen und bei Problemen Benachrichtigungen zu generieren. 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 auf Laständerungen oder -fehler anpassen kann.
Ihr GKE-Cluster reagiert automatisch auf den simulierten Ausfall. Alle Services auf betroffenen Knoten werden auf den verbleibenden Knoten neu gestartet.
Prüfen Sie die Verteilung der Knoten in Ihrem GKE-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 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 auf die verfügbaren Knoten. Alle Services sollten weiterhin ausgeführt werden.
Prüfen Sie die Verteilung der Cymbal Bank-Beispielanwendungsdienste auf Ihren GKE-Clusterknoten:
kubectl get pods -o wideDie folgende Beispielausgabe zeigt, dass die Dienste auf die verbleibenden Knoten im Cluster verteilt sind. Aus dem vorherigen Schritt zur Überprüfung der Verteilung der Knoten geht hervor, dass die Dienste jetzt nur noch in zwei Zonen in 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 Dienste an. In der vorherigen Beispielausgabe sind einige der Dienstleistungen jünger als andere in der Beispielanwendung der Cymbal Bank. Diese jüngeren Services wurden zuvor auf einem der Knoten ausgeführt, auf denen Sie einen Ausfall simuliert haben. Der Kubernetes-Controller hat diese Dienste auf 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-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.
Bereinigen
Löschen Sie das erstellte Projekt, damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Nächste Schritte
Bevor Sie mit dem Erstellen einer eigenen GKE-Clusterumgebung beginnen, die der in dieser Reihe von Anleitungen beschriebenen ähnelt, lesen Sie einige der Überlegungen zur Produktion.