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 contentoresprometheus
enettest
.- O item
prometheus
recolhe métricas decloudprober
. nettest
consultasprometheus
e apresenta os resultados do teste de rede no registo.
- O item
nettest-engine
: um ConfigMap para configurar o contentornettest
no 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:nettest
nettest
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:
echoserver
IP 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ãohostNetwork
atravé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 sondagem 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 técnico.
- Ferramentas para ajudar a resolver problemas, como a configuração do ambiente, os registos e as métricas.
- Componentes suportados.