Clusterkonnektivität mit „nettest“ prüfen

Google Distributed Cloud nettest identifiziert Verbindungsprobleme in den Kubernetes-Objekten in Ihren Clustern, wie Pods, Knoten, Dienste und einige externe Ziele. nettest prüft keine Verbindungen von externen Zielen zu Pods, Knoten oder Diensten. In diesem Dokument wird beschrieben, wie nettest mit einem der Manifeste nettest.yaml oder nettest_rhel.yaml im GitHub-Repository anthos-samples bereitgestellt und ausgeführt wird. Verwenden Sie nettest_rhel.yaml, wenn Sie Google Distributed Cloud unter Red Hat Enterprise Linux (RHEL) ausführen. Verwenden Sie nettest.yaml, wenn Sie Google Distributed Cloud unter Ubuntu ausführen.

In diesem Dokument wird auch beschrieben, wie Sie die von nettest generierten Logs interpretieren, um Verbindungsprobleme mit Ihren Clustern zu identifizieren.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

Über nettest

Das Diagnosetool nettest besteht aus den folgenden Kubernetes-Objekten. Jedes Objekt wird in den YAML-Manifestdateien von nettest angegeben.

• cloudprober: Ein DaemonSet und ein Dienst, der für die Erfassung des Netzwerkverbindungsstatus zuständig ist, z. B. Fehlerrate und Latenz.
• echoserver: Ein DaemonSet und ein Dienst, der für die Reaktion auf cloudprober zuständig ist und die Messwerte für die Netzwerkverbindung bereitstellt.
• nettest: Ein Pod, der die Container prometheus und nettest enthält.
  • prometheus erfasst Messwerte aus cloudprober.
  • nettest fragt prometheus ab und zeigt die Netzwerktestergebnisse im Log an.
• nettest-engine: eine ConfigMap zum Konfigurieren des Containers nettest im Pod nettest.

Das Manifest gibt auch den Namespace nettest und ein dediziertes ServiceAccount (zusammen mit ClusterRole und ClusterRoleBinding) an, um nettest von anderen Clusterressourcen zu isolieren.

„Nettest“ ausführen

Stellen Sie nettest mit dem folgenden Befehl für Ihr Betriebssystem bereit. Wenn der Pod nettest gestartet wird, wird der Test automatisch ausgeführt. Der Test dauert etwa fünf Minuten.

Für Ubuntu:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest.yaml

Für RHEL:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest_rhel.yaml

Hinweis: Wenn Sie eine private Registry verwenden, müssen Sie das Manifest ändern, bevor Sie es bereitstellen. Laden Sie die Manifestdatei herunter. Ersetzen Sie alle Instanzen von gcr.io/anthos-baremetal-release und gcr.io/google_containers im Manifest durch Details für Ihre lokale Registry-Spiegelung. Stellen Sie dann das Manifest bereit, um mit dem Testen zu beginnen.

Testergebnisse abrufen

Führen Sie nach Abschluss des Tests, der etwa fünf Minuten nach der Bereitstellung des Manifests nettest erfolgt sein sollte, den folgenden Befehl aus, um die Ergebnisse von nettest aufzurufen:

kubectl -n nettest logs nettest -c nettest

Während nettest ausgeführt wird, werden Nachrichten wie die folgenden an stdout gesendet:

I0413 03:33:04.879141       1 collectorui.go:130] Listening on ":8999"
I0413 03:33:04.879258       1 prometheus.go:172] Running prometheus controller
E0413 03:33:04.879628       1 prometheus.go:178] Prometheus controller: failed to
retries probers: Get "http://127.0.0.1:9090/api/v1/targets": dial tcp 127.0.0.1:9090:
connect: connection refused

Hinweis: Die Nachricht connection refused wird erwartet.

Wenn nettest erfolgreich ausgeführt wird, ohne Verbindungsfehler zu erkennen, wird der folgende Logeintrag angezeigt:

I0211 21:58:34.689290       1 validate_metrics.go:78] Metric validation passed!

Wenn nettest Verbindungsprobleme gefunden hat, schreibt es Logeinträge wie die folgenden:

E0211 06:40:11.948634       1 collector.go:65] Engine error: step validateMetrics failed:
"Error rate in percentage": probe from "10.200.0.3" to "172.26.115.210:80" has value 100.000000,
threshold is 1.000000
"Error rate in percentage": probe from "10.200.0.3" to "172.26.27.229:80" has value 100.000000,
threshold is 1.000000
"Error rate in percentage": probe from "192.168.3.248" to "echoserver-hostnetwork_10.200.0.2_8080"
has value 2.007046, threshold is 1.000000

Obwohl der Standardschwellenwert ein Prozent (1.000000) beträgt, können Fehlerraten von bis zu fünf Prozent ignoriert werden. Beispielsweise beträgt die Fehlerrate für die Konnektivität von der IP-Adresse 192.168.3.248 zu echoserver-hostnetwork_10.200.0.2_8080 im vorherigen Beispiel etwa zwei Prozent (2.007046). Dies ist ein Beispiel für ein gemeldetes Konnektivitätsproblem, das Sie ignorieren können.

Testergebnisse interpretieren

Wenn nettest abgeschlossen ist und ein Konnektivitätsproblem gefunden wird, wird der folgende Eintrag in den nettest-Pod-Logs angezeigt:

"Error rate in percentage": probe from {src} to {dst} has value 100.000000, threshold is 1.000000

Hier können {src} und {dst} entweder sein:

• Pod-IP von echoserver: Die Verbindung zu/von einem Pod auf dem Knoten.
• Knoten-IP: Die Verbindung zum/vom Knoten.
• Dienst-IP: Details finden Sie im folgenden Text.

Darüber hinaus kann {dst} Folgendes sein:

• google.com: Eine externe Verbindung.

• dns: Die Verbindung zu einem Nicht-hostNetwork-Dienst über DNS, also echoserver-non-hostnetwork.nettest.svc.cluster.local.

  Die Details für die Dienst-IP finden Sie im Log als JSON-formatierte Prüfungseinträge, wie im folgenden Beispiel. Das folgende Prüfungsbeispiel zeigt, dass 172.26.27.229:80 die Adresse für service-clusterip ist. Es gibt zwei Prüfungen mit diesem targets-Wert, eine für den Pod (pod-service-clusterip) und eine für den Knoten (node-service-clusterip).

  probe {
    name: "node-service-clusterip"
    …
    targets {
      host_names: "172.26.27.229:80"
    }
  

Problembehebungen validieren

Wenn Sie alle gemeldeten Verbindungsprobleme behoben haben, entfernen Sie den Pod nettest und wenden Sie das Manifest nettest noch einmal an, um die Tests für die Konnektivität noch einmal auszuführen.

Mit den folgenden Befehle führen Sie beispielsweise nettest für Ubuntu noch einmal aus:

kubectl -n nettest delete pod nettest
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest.yaml

Bereinigen von nettest

Wenn Sie die Tests abgeschlossen haben, führen Sie die folgenden Befehle aus, um alle nettest-Ressourcen zu entfernen:

Hinweis: Durch das Bereinigen werden alle nettest-Logs entfernt.

kubectl delete namespace nettest
kubectl delete clusterroles nettest:nettest
kubectl delete clusterrolebindings nettest:nettest

Nächste Schritte

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.