Vérifier la connectivité du cluster avec nettest

Le service nettest de Google Distributed Cloud identifie les problèmes de connectivité dans les objets Kubernetes de vos clusters, tels que les pods, les nœuds, les services et certaines cibles externes. nettest ne vérifie pas les connexions entre les cibles externes et les pods, les nœuds ou les services. Ce document explique comment déployer et exécuter nettest avec l'un des fichiers manifestes, nettest.yaml ou nettest_rhel.yaml, dans le dépôt GitHub anthos-samples. Utilisez nettest_rhel.yaml si vous exécutez Google Distributed Cloud sur Red HatEnterprise Linux (RHEL). Utilisez nettest.yaml si vous exécutez Google Distributed Cloud sur Ubuntu.

Ce document explique également comment interpréter les journaux générés par nettest pour identifier les problèmes de connectivité avec vos clusters.

Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

À propos de nettest

L'outil de diagnostic nettest comprend les objets Kubernetes suivants. Chaque objet est spécifié dans les fichiers manifestes YAML nettest.

• cloudprober : DaemonSet et un service chargé de collecter l'état de la connexion réseau, tels que le taux d'erreur et la latence.
• echoserver : DaemonSet et un service chargés de répondre à cloudprober, en leur fournissant les métriques de connectivité réseau.
• nettest : pod contenant les conteneurs prometheus et nettest.
  • prometheus collecte les métriques à partir de cloudprober.
  • nettest interroge prometheus et affiche les résultats du test du réseau dans le journal.
• nettest-engine : fichier ConfigMap permettant de configurer le conteneur nettest dans le pod nettest.

Le fichier manifeste spécifie également l'espace de noms nettest et un compte de service dédié (avec ClusterRole et ClusterRoleBinding) pour isoler nettest des autres ressources du cluster.

Exécuter nettest

Déployez nettest en exécutant la commande suivante pour votre système d'exploitation. Lorsque le pod nettest démarre, le test s'exécute automatiquement. L'exécution du test prend environ cinq minutes.

Pour Ubuntu:

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

Pour RHEL:

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

Remarque :Si vous utilisez un registre privé, vous devez modifier le fichier manifeste avant de le déployer. Téléchargez le fichier manifeste. Remplacez toutes les instances de gcr.io/anthos-baremetal-release et gcr.io/google_containers dans le fichier manifeste par les détails de votre miroir de registre local. Déployez ensuite le fichier manifeste pour commencer les tests.

Obtenir les résultats du test

Une fois le test terminé, ce qui prend environ cinq minutes après le déploiement du fichier manifeste nettest, exécutez la commande suivante pour afficher les résultats nettest :

kubectl -n nettest logs nettest -c nettest

Pendant l'exécution de nettest, les messages suivants sont envoyés à stdout :

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

Remarque :Le message connection refused est attendu.

Si nettest s'exécute correctement sans identifier d'échec de connectivité, l'entrée de journal suivante s'affiche :

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

Si nettest a trouvé des problèmes de connexion, il écrit des entrées de journal comme suit :

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

Bien que le seuil par défaut soit de 1 % (1.000000), les taux d'erreur jusqu'à 5 % peuvent être ignorés en toute sécurité. Par exemple, le taux d'erreur pour la connectivité entre les adresses IP 192.168.3.248 et echoserver-hostnetwork_10.200.0.2_8080 dans l'exemple précédent est d'environ deux pourcent (2.007046). Voici un exemple de problème de connectivité signalé que vous pouvez ignorer.

Interpréter les résultats du test

Lorsque nettest a terminé et détecte un problème de connectivité, l'entrée suivante s'affiche dans les journaux du pod nettest :

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

Ici, {src} et {dst} peuvent être soit :

• Adresse IP du pod echoserver: connexion vers ou depuis un pod du nœud.
• Adresse IP du nœud: connexion vers ou depuis le nœud.
• Adresse IP du service (voir le texte suivant pour plus de détails)

En outre, {dst} peut également être :

• google.com : une connexion externe.

• dns : une connexion à un service non-hostNetwork via DNS, c'est-à-dire echoserver-non-hostnetwork.nettest.svc.cluster.local.

  Les détails de l'adresse IP du service se trouvent dans des entrées de vérification au format JSON, comme dans l'exemple suivant. L'exemple de vérification suivant montre que 172.26.27.229:80 est l'adresse de service-clusterip. Il existe deux vérifications avec cette valeur targets, une pour le pod (pod-service-clusterip) et une pour le nœud (node-service-clusterip).

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

Valider vos corrections

Une fois tous les problèmes de connectivité signalés, supprimez le pod nettest et appliquez à nouveau le fichier manifeste nettest pour exécuter à nouveau les tests de connectivité.

Par exemple, pour réexécuter nettest pour Ubuntu, exécutez les commandes suivantes :

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

Effectuer un nettoyage de nettest

Lorsque vous avez terminé les tests, exécutez les commandes suivantes pour supprimer toutes les ressources nettest :

Remarque :Le nettoyage supprime tous les journaux nettest.

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

Étapes suivantes

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.