nettest de GKE sur Bare Metal identifie les problèmes de connectivité au niveau des 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 GKE sur Bare Metal sur Red HatEnterprise Linux (RHEL). Utilisez nettest.yaml si vous exécutez GKE sur une solution Bare Metal sous 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.
À 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 conteneursprometheusetnettest.prometheuscollecte les métriques à partir decloudprober.nettestinterrogeprometheuset affiche les résultats du test du réseau dans le journal.
nettest-engine: fichier ConfigMap permettant de configurer le conteneurnettestdans le podnettest.
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
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
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 depuis ou vers un pod sur le nœud. - Adresse IP du nœud: la 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-hostNetworkvia DNS, c'est-à-direechoserver-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:80est l'adresse deservice-clusterip. Il existe deux vérifications avec cette valeurtargets, 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 réexécuter 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 :
kubectl delete namespace nettest
kubectl delete clusterroles nettest:nettest
kubectl delete clusterrolebindings nettest:nettest