O Google Distributed Cloud nettest identifica problemas de conetividade nos objetos Kubernetes nos seus clusters, como pods, nós, serviços e alguns destinos externos. nettest não verifica as ligações de destinos externos a pods, nós ou serviços. Este documento descreve como implementar e executar o
nettest com um dos manifestos, nettest.yaml ou nettest_rhel.yaml, no
repositório
anthos-samples
do GitHub. Use nettest_rhel.yaml se executar o Google Distributed Cloud no
Red Hat Enterprise Linux (RHEL). Use nettest.yaml se executar o Google Distributed Cloud no Ubuntu.
Este documento também descreve como interpretar os registos gerados pelo nettest
para identificar problemas de conetividade com os seus clusters.
Acerca de nettest
A ferramenta de diagnóstico nettest consiste nos seguintes objetos do Kubernetes. Cada objeto é especificado nos ficheiros de manifesto YAML nettest.
cloudprober: um DaemonSet e um serviço responsáveis pela recolha do estado da ligação de rede, como a taxa de erros e a latência.echoserver: um DaemonSet e um serviço responsáveis por responder aocloudprober, fornecendo-lhe as métricas de conetividade de rede.nettest: um Pod que contém os contentoresprometheusenettest.- O item
prometheusrecolhe métricas decloudprober. nettestconsultasprometheuse apresenta os resultados do teste de rede no registo.
- O item
nettest-engine: um ConfigMap para configurar o contentornettestno podnettest.
O manifesto também especifica o espaço de nomes nettest e uma ServiceAccount dedicada (juntamente com ClusterRole e ClusterRoleBinding) para isolar nettest de outros recursos do cluster.
Executar nettest
Implemente nettest executando o seguinte comando para o seu sistema operativo.
Quando o nettest Pod é iniciado, o teste é executado automaticamente. O teste demora cerca de cinco minutos a concluir.
Para Ubuntu:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest.yaml
Para o RHEL:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest_rhel.yaml
Receba os resultados do teste
Após a conclusão do teste, que deve demorar cerca de cinco minutos após a implementação do manifesto, execute o seguinte comando para ver os resultados:nettestnettest
kubectl -n nettest logs nettest -c nettest
Enquanto o nettest está em execução, envia mensagens como as seguintes para o 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 o comando nettest for executado com êxito sem identificar falhas de conetividade,
é apresentada a seguinte entrada no registo:
I0211 21:58:34.689290 1 validate_metrics.go:78] Metric validation passed!
Se nettest encontrar problemas de ligação, escreve entradas de registo semelhantes às seguintes:
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 predefinido seja de um por cento (1.000000), as taxas de erro até cinco por cento podem ser ignoradas com segurança. Por exemplo, a taxa de erro de conetividade do endereço IP 192.168.3.248 para echoserver-hostnetwork_10.200.0.2_8080 no exemplo anterior é de aproximadamente dois por cento (2.007046). Este é um exemplo de um problema de conetividade comunicado que pode ignorar.
Interprete os resultados do teste
Quando o nettest termina e encontra um problema de conetividade, vê a seguinte entrada nos registos do nettest:
"Error rate in percentage": probe from {src} to {dst} has value 100.000000, threshold is 1.000000
Aqui, {src} e {dst} podem ser:
echoserverIP do pod: a ligação a ou a partir de um pod no nó.- IP do nó: a ligação ao nó ou a partir do nó.
- IP do serviço (consulte o texto seguinte para ver detalhes)
Além disso, {dst} também pode ser:
google.com: uma ligação externa.dns: a ligação a um serviço nãohostNetworkatravés de DNS, ou seja,echoserver-non-hostnetwork.nettest.svc.cluster.local.Os detalhes do IP do serviço estão em entradas de sondagem formatadas em JSON no registo, como no exemplo seguinte. O exemplo de teste seguinte mostra que
172.26.27.229:80é o endereço deservice-clusterip. Existem duas sondas com este 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" }
Valide as correções
Quando tiver resolvido todos os problemas de conetividade comunicados, remova o nettest Pod
e volte a aplicar o manifesto nettest para executar novamente os testes de conetividade.
Por exemplo, para executar novamente nettest para o Ubuntu, execute 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
Limpe nettest
Quando terminar os testes, execute os seguintes comandos para remover todos os recursos:nettest
kubectl delete namespace nettest
kubectl delete clusterroles nettest:nettest
kubectl delete clusterrolebindings nettest:nettest
O que se segue?
Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud. Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte:
- Requisitos para abrir um registo de apoio ao cliente.
- Ferramentas para ajudar a resolver problemas, como a configuração do ambiente, os registos e as métricas.
- Componentes suportados.