Verifique a conetividade do cluster com o nettest

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 ao cloudprober, fornecendo-lhe as métricas de conetividade de rede.
  • nettest: um Pod que contém os contentores prometheus e nettest.
    • O item prometheus recolhe métricas de cloudprober.
    • nettest consultas prometheus e apresenta os resultados do teste de rede no registo.
  • nettest-engine: um ConfigMap para configurar o contentor nettest no pod nettest.

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:

  • 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ão hostNetwork 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 valor targets, 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.