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 auf Ubuntu ausführen.
In diesem Dokument wird auch beschrieben, wie Sie die von nettest generierten Logs interpretieren, um Verbindungsprobleme mit Ihren Clustern zu identifizieren.
Ü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 aufcloudproberzuständig ist und die Messwerte für die Netzwerkverbindung bereitstellt.nettest: Ein Pod, der die Containerprometheusundnettestenthält.prometheuserfasst Messwerte auscloudprober.nettestfragtprometheusab und zeigt die Netzwerktestergebnisse im Log an.
nettest-engine: eine ConfigMap zum Konfigurieren des Containersnettestim Podnettest.
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
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
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, alsoechoserver-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:80die Adresse fürservice-clusteripist. Es gibt zwei Prüfungen mit diesemtargets-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 Konnektivitätstests 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:
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. Weitere Informationen zu Supportressourcen finden Sie unter Support. Dazu gehören:
- Anforderungen für das Eröffnen eines Supportfalls.
- Tools zur Fehlerbehebung, z. B. Ihre Umgebungskonfiguration, Logs und Messwerte.
- Unterstützte Komponenten.