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 auch bei Problemen auf Ihre Anwendungen zugreifen. Die Beispielanwendung „Cymbal Bank“ ist so konzipiert, dass sie Fehler verarbeiten und weiter ausgeführt werden kann, ohne dass Sie Fehler beheben müssen. Um diese Resilienz zu gewährleisten, werden in regionalen GKE-Clustern Compute-Knoten 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 sehen wie die Anwendungsdienste in Ihrem GKE-Cluster reagieren. Sie lernen, wie Sie die folgenden Aufgaben ausführen:
- Verteilung von Knoten und Diensten prüfen
- Knoten- oder Zonenfehler simulieren
- Prüfen, ob die Dienste auf den verbleibenden Knoten weiter 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 Gebühren pro Cluster an. Weitere Informationen finden Sie auf unserer Preisseite bis Sie GKE deaktivieren oder das Projekt löschen. Google Cloud
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.
Hinweis
Wenn Sie einen Fehler simulieren möchten, müssen Sie die erste Anleitung zum Erstellen eines GKE-Cluster ausführen, der den Autopilot-Modus verwendet und die auf Mikrodiensten basierende Beispielanwendung „Cymbal Bank“ bereitstellen.
Wir empfehlen Ihnen, diese Reihe von Anleitungen für skalierbare Anwendungen in der richtigen Reihenfolge 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: Die
us-central1 Region bezeichnet eine Region im Mittleren Westen der USA
mit mehreren Zonen wie 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 Hochverfügbarkeit empfiehlt Google, die Anwendungen in mehreren Zonen und mehreren Regionen bereitzustellen. Dieser Ansatz schützt vor unerwarteten Ausfällen von Komponenten in einer Zone oder Region.
Als Sie Ihren GKE-Cluster in der ersten Anleitung erstellt haben, wurden einige Standardkonfigurationswerte verwendet. Standardmäßig werden in einem GKE-Cluster mit Autopilot Knoten erstellt und ausgeführt, die sich über mehrere Zonen der von Ihnen angegebenen Region erstrecken. Das bedeutet, dass die Beispielanwendung „Cymbal Bank“ bereits in mehreren Zonen bereitgestellt ist, 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 Beispielanwendung „Cymbal Bank“ auf die Knoten Ihres GKE-Cluster:
kubectl get pods -o wideDie folgende Beispielausgabe zeigt, dass die Dienste auf die Knoten im Cluster verteilt sind. Aus dem vorherigen Schritt, in dem Sie geprüft haben, wie die Knoten verteilt sind, geht hervor, dass die Dienste in den Zonen 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 auf anderen Knoten oder in anderen Zonen in derselben Region weiter 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 von Ihren Zonen und beenden Sie sie per Drain. So wird simuliert, was passiert, wenn ein Knoten ausfällt oder wenn es ein Problem mit einer ganzen Zone gibt. 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-averwendet: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 Pods nicht mehr auf diesen Knoten ausgeführt werden können. Kubernetes plant Pods auf anderen Knoten in funktionierenden Zonen neu.
Reaktion auf den simulierten Fehler prüfen
In einer vorherigen Anleitung dieser Reihe, haben Sie erfahren, wie Sie die verwaltete Prometheus-Instanz für Ihren GKE-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 Status Ihrer Deployments überwacht, Sie bei Problemen benachrichtigt und sich automatisch an Laständerungen oder Ausfälle anpassen kann.
Ihr GKE-Cluster reagiert automatisch auf den simulierten Ausfall. Alle Dienste auf betroffenen Knoten werden auf den 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 Beispielanwendung „Cymbal Bank“ 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. Aus dem vorherigen Schritt, in dem Sie geprüft haben, wie die Knoten verteilt sind, geht hervor, dass die Dienste jetzt nur noch 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 das
AGEder Dienste an. In der vorherigen Beispielausgabe sind einige der Dienste jünger als andere in der Beispielanwendung „Cymbal Bank“. Diese jüngeren Dienste wurden zuvor auf einem der Knoten ausgeführt, auf denen 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.
Bereinigen
Löschen Sie das 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
In der nächsten Anleitung erfahren Sie, wie Sie das Änderungsmanagement mit Config Sync zentralisieren.