Os clusters do Anthos em bare metal nettest
identificam problemas de conectividade nos
objetos Kubernetes nos clusters, como pods, nós, serviços e alguns
destinos externos. No entanto, vale lembrar que nettest
não verifica as conexões de destinos externos com
pods, nós ou serviços. Este documento descreve como implantar e executar nettest
com um dos manifestos, nettest.yaml
ou nettest_rhel.yaml
, no repositório GitHub anthos-samples. Use nettest_rhel.yaml
ao executar clusters do Anthos em bare metal no
Red HatEnterprise Linux (RHEL) ou no CentOS. Use nettest.yaml
ao executar
os clusters do Anthos em bare metal no Ubuntu.
Este documento também descreve como interpretar os registros gerados por nettest
para identificar problemas de conectividade com os clusters.
Sobre nettest
A ferramenta de diagnóstico nettest
consiste nos objetos do Kubernetes a seguir. Cada
objeto é especificado nos arquivos de manifesto YAML nettest
.
cloudprober
: um DaemonSet e um serviço responsável por coletar o status da conexão de rede, como taxa de erros e latência.echoserver
: um DaemonSet e um serviço responsável por responder acloudprober
com as métricas de conectividade de rede.nettest
: um pod que contém os contêineresprometheus
enettest
.prometheus
coleta métricas decloudprober
.nettest
consultaprometheus
e exibe os resultados do teste de rede no registro.
nettest-engine
: um ConfigMap para configurar o contêinernettest
no podnettest
.
O manifesto também especifica o namespace nettest
e uma ServiceAccount dedicada (com ClusterRole e ClusterRoleBinding) para isolar nettest
de outros recursos de clusters.
Executar nettest
Implante nettest
executando o seguinte comando para o sistema operacional.
Quando o pod nettest
é iniciado, o teste é executado automaticamente. O teste leva cerca
de cinco minutos para ser concluído.
Para o SO Ubuntu:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest.yaml
Para RHEL ou SO CentOS:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest_rhel.yaml
Ver os resultados do teste
Depois que o teste for concluído, o que leva cerca de cinco minutos após a implantação do manifesto nettest
, execute o seguinte comando para ver os resultados de nettest
:
kubectl -n nettest logs nettest -c nettest
Enquanto nettest
está em execução, ele envia mensagens como as seguintes para 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
Se nettest
for executado sem identificar falhas de conectividade,
você verá a seguinte entrada de registro:
I0211 21:58:34.689290 1 validate_metrics.go:78] Metric validation passed!
Se nettest
encontrar problemas de conexão, gravará entradas de registro como estas:
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
Embora o limite padrão seja de 1% (1.000000
), as taxas de erro de até
5% podem ser ignoradas com segurança. Por exemplo, a taxa de erros de conectividade
do endereço IP 192.168.3.248
para echoserver-hostnetwork_10.200.0.2_8080
no
exemplo anterior é de aproximadamente 2% (2.007046
). Este é um
exemplo de um problema de conectividade informado que você pode ignorar.
Interpretar os resultados do teste
Quando nettest
terminar e encontrar um problema de conectividade, você verá a seguinte
entrada nos registros do pod nettest
:
"Error rate in percentage": probe from {src} to {dst} has value 100.000000, threshold is 1.000000
Aqui, {src}
e {dst}
podem ser:
- IP do pod
echoserver
: a conexão de/para um pod no nó. - IP do nó: a conexão de/para o nó.
- IP do serviço (veja detalhes no texto a seguir).
Além disso, {dst}
também pode ser:
google.com
: uma conexão externa.dns
: a conexão com um serviço nãohostNetwork
por meio do DNS, que éechoserver-non-hostnetwork.nettest.svc.cluster.local
.Os detalhes do IP do serviço estão nas entradas de sondagem formatadas em JSON no registro, como no exemplo a seguir. O exemplo de sondagem a seguir mostra que
172.26.27.229:80
é o endereço deservice-clusterip
. Há duas sondagens com esse valortargets
, uma para o pod (pod-service-clusterip
) e outra para o nó (node-service-clusterip
).probe { name: "node-service-clusterip" … targets { host_names: "172.26.27.229:80" }
Validar as correções
Depois de resolver todos os problemas de conectividade relatados, remova o pod nettest
e aplique novamente o manifesto nettest
para executar mais uma vez os testes de conectividade.
Por exemplo, para executar novamente o nettest
para Ubuntu, use os seguintes comandos:
kubectl -n nettest delete pod nettest
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest.yaml
Limpar nettest
Quando terminar o teste, execute os seguintes comandos para remover todos os recursos de nettest
:
kubectl delete namespace nettest
kubectl delete clusterroles nettest:nettest
kubectl delete clusterrolebindings nettest:nettest