O GKE em bare metal 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 do GitHub anthos-samples (em inglês). Use nettest_rhel.yaml
se você executar o GKE em Bare Metal no
Red HatEnterprise Linux (RHEL). Use nettest.yaml
se você executar
o GKE 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 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
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ã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 solucionar todos os problemas de conectividade informados, remova o pod nettest
e aplique novamente o manifesto nettest
para executar novamente 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