Lernpfad: Skalierbare Anwendungen – Fehler simulieren

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 Enterprise-Cluster erstellt haben, wurden einige Standardkonfigurationswerte verwendet. Standardmäßig werden in einem GKE Enterprise-Cluster, der Autopilot verwendet, Knoten erstellt und ausgeführt, die sich über die Zonen der von Ihnen angegebenen Region erstrecken. Bei diesem Ansatz wird die Beispielanwendung der Cymbal Bank bereits in mehreren Zonen bereitgestellt, was zum Schutz vor unerwarteten Ausfällen beiträgt.

1. 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 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.4
   

2. Prüfen Sie die Verteilung der Dienste der Beispielanwendung „Cymbal Bank“ auf die Knoten Ihres GKE Enterprise-Clusters:

   kubectl get pods -o wide
   

   Die folgende Beispielausgabe zeigt, dass die Dienste auf Knoten im Cluster verteilt sind. Die Ausgabe aus dem vorherigen Schritt zeigt, wie die Knoten verteilt sind. Die Ausgabe unten zeigt, 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-a als 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-daemonsets
  

  Mit 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 einer früheren Anleitung in 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 bei Problemen benachrichtigt und sich automatisch an Laständerungen oder Fehler anpassen kann.

Ihr GKE Enterprise-Cluster reagiert automatisch auf den simulierten Ausfall. Alle Dienste auf betroffenen Knoten werden auf verbleibenden Knoten neu gestartet.

1. Prüfen Sie noch einmal die Verteilung der Knoten auf Ihren 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 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.4
   

2. Der 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 Enterprise-Clusters:

   kubectl get pods -o wide
   

   Die 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-node1
   

3. Sehen Sie sich die AGE der 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 Enterprise-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.