O Google Distributed Cloud nettest identifica 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 se você executar o Google Distributed Cloud no
Red Hat Enterprise Linux (RHEL). Use nettest.yaml se você executar
o Google Distributed Cloud 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 acloudprobercom as métricas de conectividade de rede.nettest: um pod que contém os contêineresprometheusenettest.prometheuscoleta métricas decloudprober.nettestconsultaprometheuse exibe os resultados do teste de rede no registro.
nettest-engine: um ConfigMap para configurar o contêinernettestno 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 Ubuntu:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest.yaml
Para RHEL:
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 ou para um pod no nó. - IP do nó: a conexão de ou 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ãohostNetworkpor 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
A seguir
Se precisar de mais ajuda, entre em contato com o Cloud Customer Care. Consulte também Receber suporte para mais informações sobre recursos de suporte, incluindo:
- Requisitos para abrir um caso de suporte.
- Ferramentas para ajudar na solução de problemas, como configuração do ambiente, registros e métricas.
- Componentes compatíveis.