Google Distributed Cloud nettest
identifiziert Verbindungsprobleme in den Kubernetes-Objekten in Ihren Clustern wie Pods, Knoten, Diensten und einigen externen Zielen. nettest
prüft keine Verbindungen von externen Zielen zu Pods, Knoten oder Diensten. In diesem Dokument wird beschrieben, wie Sie nettest
mit einem der Manifeste nettest.yaml
oder nettest_rhel.yaml
im GitHub-Repository für anthos-samples bereitstellen und ausführen. Verwenden Sie nettest_rhel.yaml
, wenn Sie Google Distributed Cloud unter Red HatEnterprise 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.
Informationen zu 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 aufcloudprober
zuständig ist und die Messwerte für die Netzwerkverbindung bereitstellt.nettest
: Ein Pod, der die Containerprometheus
undnettest
enthält.prometheus
erfasst Messwerte auscloudprober
.nettest
fragtprometheus
ab und zeigt die Netzwerktestergebnisse im Log an.
nettest-engine
: eine ConfigMap zum Konfigurieren des Containersnettest
im 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:
echoserver
Pod-IP: die Verbindung zu oder von einem Pod auf dem Knoten.- Knoten-IP: die Verbindung zum oder 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:80
die Adresse fürservice-clusterip
ist. 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