Clusterkonnektivität mit „nettest“ prüfen

GKE on Bare Metal nettest identifiziert Verbindungsprobleme in den Kubernetes-Objekten in Ihren Clustern, z. B. 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 GKE auf Bare Metal unter Red HatEnterprise Linux (RHEL) oder CentOS ausführen. Verwenden Sie nettest.yaml, wenn Sie GKE auf Bare Metal 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.

Ü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-Betriebssystem:

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

Für RHEL- oder CentOS-Betriebssystem:

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, 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 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