Les clusters Anthos sur solution Bare Metal nettest
identifient 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 des clusters Anthos sur solution Bare Metal sur Red HatEnterprise Linux (RHEL) ou CentOS. Utilisez nettest.yaml
si vous exécutez des clusters Anthos sur solution Bare Metal 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.
À 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 conteneursprometheus
etnettest
.prometheus
collecte les métriques à partir decloudprober
.nettest
interrogeprometheus
et affiche les résultats du test du réseau dans le journal.
nettest-engine
: fichier ConfigMap permettant de configurer le conteneurnettest
dans 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 OS :
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest.yaml
Pour RHEL ou OS CentOS :
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/vers un pod du nœud. - Adresse IP du nœud : connexion vers/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-à-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:80
est 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