Resolver problemas de observabilidade de rede do GKE

Este documento fornece instruções e procedimentos de diagnóstico para diagnosticar problemas de rede em clusters do Google Kubernetes Engine (GKE) usando a observabilidade do GKE Dataplane V2, o Hubble e o Cloud Monitoring.

Para uma visão geral da arquitetura e práticas recomendadas conceituais, consulte Práticas recomendadas para observabilidade de rede.

Árvore de decisão para solução de problemas e conceitos principais

Antes de analisar os procedimentos, use a matriz de decisão a seguir para identificar qual camada da pilha de rede do GKE provavelmente está causando seu problema e navegue até a seção correspondente.

Sintoma ou pergunta de diagnóstico Nível suspeito Procedimento recomendado
Os pods não conseguem resolver domínios externos ou serviços internos do Kubernetes (tempos limite de DNS, NXDOMAIN, SERVFAIL). Nível 1: pod e serviço (DNS) Diagnosticar falhas na resolução de DNS
Os serviços não podem se comunicar; há tempos limite de conexão ou pacotes descartados entre os pods. Nível 1: pod e serviço (descartes de política ou pacote) Diagnosticar descartes de pacotes e bloqueios de NetworkPolicy
As réplicas de carga de trabalho têm carga de tráfego desigual ou os pods registram altas taxas de redefinições de TCP (RST). Nível 1: pod e serviço (balanceamento de carga ou transporte) Diagnosticar desequilíbrio de tráfego e redefinições de TCP
Latência geral, tempos limite intermitentes ou reinicializações de CNI em todos os nós. Nível 2: nó e CNI (kernel) Triagem para latência no nível do nó e gargalos da CNI
Os pods não podem acessar recursos fora do GKE (Cloud SQL, APIs externas ou outras VPCs). Nível 3: VPC e roteamento Isolar problemas de conectividade do GKE em relação à VPC ou a problemas externos
Precisa de simulação de caminho automatizada para verificar se as regras de firewall, rotas ou NetworkPolicies bloqueiam o tráfego. Nível 3: VPC e roteamento (simulação) Diagnosticar a conectividade usando os Testes de Conectividade
Need to identify which workloads send traffic to the internet and undergo NAT. Nível 4: gateway externo e custo Identificar o tráfego NAT (saída para a Internet)
Altos custos de transferência de dados entre zonas ou necessidade de visualizar os principais comunicadores sem escrever consultas SQL. Nível 4: gateway externo e custo Analisar os custos e o desempenho do tráfego do cluster usando o Flow Analyzer

Conceitos básicos de rede

Se você não conhece o Kubernetes ou o Google Cloud networking, lembre-se destes conceitos básicos:

  • eBPF (Filtro de Pacote Berkeley Estendido): uma tecnologia de sistema operacional que permite executar programas seguros de monitoramento e roteamento diretamente no kernel do Linux. O GKE Dataplane V2 usa o eBPF para rotear pacotes e aplicar NetworkPolicies com sobrecarga mínima de desempenho.
  • Mascaramento de IP (SNAT): o processo de reescrever o endereço IP de origem de um pacote. Quando um pod do GKE (que tem um endereço IP particular) se comunica com a Internet ou recursos externos da VPC, o GKE mascara (reescreve) o endereço IP do pod para o endereço IP do nó para que os sistemas externos saibam como encaminhar a resposta.
  • Rastreamento de conexão (Conntrack): um recurso do kernel que rastreia todas as conexões de rede ativas. Nos clusters do GKE Dataplane V2, esse rastreamento é dividido entre duas tabelas: o conntrack padrão do kernel Linux (usado pelo ip-masq-agent) e uma tabela conntrack gerenciada pelo Cilium e pelo GKE Dataplane V2 armazenada em um mapa eBPF. Se um nó processar muitas conexões simultâneas, qualquer uma dessas tabelas de rastreamento poderá ficar cheia (exaustão de conntrack), fazendo com que o nó descarte silenciosamente novos pacotes.
  • Hubble:o mecanismo de observabilidade do GKE Dataplane V2. Ele é executado no eBPF e oferece visibilidade em tempo real dos fluxos de tráfego, das quedas de pacotes e da avaliação de NetworkPolicy.

Nível 1: observabilidade de pod e serviço (aplicativo)

O nível de pod e serviço abrange a comunicação de rede entre pods, serviços e DNS do cluster. Problemas nesse nível geralmente se manifestam como tempos limite de conexão do aplicativo, falhas na resolução de nomes ou distribuição desigual de carga.

Diagnosticar falhas de resolução de DNS

Revise o escopo de diagnóstico e os pré-requisitos antes de resolver problemas de DNS:

  • Área de foco:comunicação entre pods e CoreDNS ou NodeLocal DNSCache, latência de DNS, tempos limite de resolução de DNS upstream e validação de NetworkPolicy de FQDN.
  • Pré-requisitos:métricas do GKE Dataplane V2 ativadas; acesso ao kubectl.
  • Compatibilidade com CNI:GKE Dataplane V2 (Datapath avançado) e CNI padrão do GKE.
  • Sintoma:os pods registram dial tcp: lookup <domain>: i/o timeout, NXDOMAIN ou latência intermitente em chamadas de API de saída.
  • Objetivo:determinar se a falha de DNS se origina dentro do cluster (kube-dns ou saturação do NodeLocal DNSCache), uma NetworkPolicy que bloqueia a porta UDP ou TCP 53 ou uma degradação da rede upstream.

Etapa 1: verificação básica de acessibilidade

Antes de resolver problemas nas camadas de DNS, verifique se o destino pode ser acessado diretamente usando o endereço IP dele de dentro do pod afetado:

# 1. Test raw IP reachability (bypasses DNS entirely)
kubectl exec -it my-pod -n default -- curl -v --connect-timeout 5 http://10.240.0.10:8080

# 2. Test domain resolution
kubectl exec -it my-pod -n default -- curl -v --connect-timeout 5 http://my-service.default.svc.cluster.local:8080
  • Se a conexão por IP for bem-sucedida, mas o domínio falhar:o problema está isolado na camada de resolução de DNS. Prossiga para a etapa 2.
  • Se os dois falharem:o problema é o roteamento no nível da rede ou a aplicação da política. Prossiga para Diagnosticar descartes de pacotes e bloqueios de NetworkPolicy.
Verificar o pré-preenchimento de DNS da FQDN NetworkPolicy

Se o cluster usar NetworkPolicies baseadas em FQDN (FQDNNetworkPolicy), verifique se o nome de domínio está explicitamente permitido. Se um pod consultar um domínio externo que não está pré-preenchido no cache do proxy DNS do GKE Dataplane V2 ou não é permitido pela política, o GKE Dataplane V2 vai bloquear o tráfego de saída para o endereço IP resolvido:

# Verify whether UDP or TCP port 53 egress is permitted in the Pod's namespace
kubectl get networkpolicy -n default -o yaml | grep -A 5 -B 2 "port: 53"

Etapa 2: verificar as métricas de DNS no Cloud Monitoring

O GKE expõe métricas de DNS integradas no Cloud Monitoring com o prefixo kubernetes.io/networking/dns/.

Para verificar as métricas de DNS no Cloud Monitoring, faça o seguinte:

  1. No Google Cloud console, acesse Cloud Monitoring > Painéis.
  2. Selecione o painel predefinido Observabilidade do DNS do GKE: visualização do cluster ou navegue até o Metrics Explorer e filtre por kubernetes.io/networking/dns/.
  3. Avalie os seguintes indicadores principais (para o NodeLocal DNSCache, substitua kubedns por node_local_dns no caminho da métrica):
Nome da métrica Limite de alerta Causa raiz
kubernetes.io/networking/dns/kubedns/max_concurrent_rejected_request_count > 0 Limite de consultas simultâneas atingido. kube-dns ou o NodeLocal DNSCache está descartando consultas.
kubernetes.io/networking/dns/kubedns/dns_request_latencies p99 > 100ms Alta latência de resolução de DNS de ponta a ponta em kube-dns ou NodeLocal DNSCache.
kubernetes.io/networking/dns/kubedns/forwarding_request_latencies p99 > 100ms Latência ou saturação do servidor DNS upstream.
Sequência de triagem de desempenho e tempo limite de DNS

Siga esta sequência de triagem para diagnosticar latência de DNS, falhas de cache e tempos limite upstream:

  1. Verifique a proporção de ocorrência em cache:consulta kubernetes.io/networking/dns/kubedns/dns_cache_request_count (ou node_local_dns/dns_cache_request_count) agrupada pelo rótulo cache_status. Se cache_status="hit" for baixo e cache_status="miss" for alto, talvez os aplicativos estejam emitindo consultas não FQDN (como my-service em vez de my-service.default.svc.cluster.local), causando travessia de caminhos de pesquisa em todas as entradas em /etc/resolv.conf.
  2. Avalie a latência upstream:um valor alto de forwarding_request_latencies indica problemas com o servidor DNS upstream (por exemplo, DNS corporativo local alcançado pelo Cloud Interconnect ou pela Cloud VPN, ou limites do Cloud DNS).

  3. Auditar substituições de DNS personalizadas:inspecione os ConfigMaps kube-dns personalizados para stubs ou encaminhamentos upstream mal configurados:

    kubectl get configmap kube-dns -n kube-system -o yaml

Etapa 3: transmitir tráfego DNS ao vivo com a CLI do Hubble

Use o alias auxiliar da CLI do Hubble para inspecionar solicitações e respostas de DNS em tempo real transmitidas do kernel do nó:

# 1. Ensure the helper alias is set in your terminal session
alias gke-hubble="kubectl exec -it -n gke-managed-dpv2-observability deployment/hubble-relay -c hubble-cli -- hubble"

# 2. Observe live DNS (Port 53) traffic for a specific Pod
gke-hubble observe --pod default/my-pod --port 53

Etapa 4: validar a correção

Se ocorreram rejeições de consultas simultâneas, aplique o NodeLocal DNSCache para absorver buscas DNS de alta frequência diretamente no nó sem atingir os limites kube-dns em todo o cluster:

# Verify NodeLocal DNSCache DaemonSet is running
kubectl get daemonset node-local-dns -n kube-system

Diagnosticar quedas de pacotes e bloqueios de NetworkPolicy

Revise o escopo de diagnóstico e os pré-requisitos antes de investigar descartes de pacotes e negações de políticas:

  • Área de foco:quedas de tráfego entre objetos de pod ou entre objetos de pod e serviço, aplicação de NetworkPolicy, motivos de queda de eBPF do kernel.
  • Pré-requisitos:observabilidade de fluxo do GKE Dataplane V2 ativada e registro em log do NetworkPolicy configurado.
  • Compatibilidade com CNI:somente GKE Dataplane V2.
  • Sintoma:as tentativas de conexão do aplicativo falham com Connection timed out ou Connection reset by peer.
  • Objetivo:identificar o motivo exato da NetworkPolicy ou do eBPF para descartar pacotes sem mudanças por tentativa e erro nas políticas de segurança.

Etapa 1: monitorar as métricas de queda do Hubble

Quando o GKE Dataplane V2 descarta um pacote, ele emite a métrica hubble_drop_total marcada com o motivo do descarte e os metadados de origem e destino. Para monitorar as métricas de queda do Hubble, faça o seguinte:

  1. Se ainda não estiver configurado, implante um recurso PodMonitoring do Google Cloud Managed Service para Prometheus para coletar métricas do Hubble:

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: hubble-metrics
  namespace: gke-managed-dpv2-observability
spec:
  selector:
    matchLabels:
      k8s-app: cilium
  endpoints:
  - port: hubble-metrics
    interval: 30s

  2. Execute a consulta a seguir em Cloud Monitoring > Metrics Explorer para ver as quedas por motivo:

    sum by (reason) (rate(hubble_drop_total[5m])) > 0

  3. Interprete os códigos reason comuns:

    • Policy denied: uma NetworkPolicy do Kubernetes está bloqueando a conexão de forma explícita ou implícita.
    • CT: Map insertion failed: a tabela de rastreamento de conexão (conntrack) está esgotada.
    • Unsupported L3 protocol: pacote não IPv4 ou IPv6 ou cabeçalho corrompido.

Etapa 2: verificar os registros do NetworkPolicy no Cloud Logging

O registro do NetworkPolicy exporta registros JSON estruturados para todas as decisões de política. Para consultar os registros do NetworkPolicy no Cloud Logging, faça o seguinte:

  1. No console do Google Cloud , acesse Cloud Logging > Análise de registros.

  2. Execute a seguinte consulta:

    resource.type="k8s_node"
log_name:"projects/PROJECT_ID/logs/events"
jsonPayload.connection.verdict="DENY"
jsonPayload.src.pod_name="my-source-pod"

  3. Inspecione o payload JSON:

    • jsonPayload.drop_reason: mostra por que o pacote foi descartado.
    • jsonPayload.policies: lista quais NetworkPolicies foram avaliadas. Se uma lista vazia for retornada com um veredito DENY, o namespace estará operando no modo de negação padrão, e nenhuma política permitiu o tráfego.

Se nenhum registro do NetworkPolicy aparecer, verifique se a geração de registros está ativada no recurso personalizado NetworkLogging do cluster. Por exemplo, verifique se o campo spec.cluster.deny.log está definido como true:

kubectl get networklogging default -o yaml

Etapa 3: rastrear descartes ativos com a CLI do Hubble

Transmita descartes ao vivo diretamente usando a CLI do Hubble para inspecionar pacotes em tempo real:

gke-hubble observe --verdict DROPPED --namespace default --follow

Exemplo de saída:

TIMESTAMP             SOURCE               DESTINATION          TYPE     VERDICT
10:14:22.102          default/frontend     default/backend:80   to-stack DROPPED (Policy denied by NetworkPolicy: backend-deny-all)

A saída indica a NetworkPolicy exata que está bloqueando o tráfego (backend-deny-all).

Etapa 4: verificar se há esgotamento do conntrack

Se o motivo da queda indicar CT: Map insertion failed:

  1. Inspecione o registro do agente do GKE Dataplane V2 para verificar a saturação da tabela conntrack:

    kubectl logs -n kube-system daemonset/anetd -c cilium-agent --tail=100 | grep "Conntrack table full"

  2. Verifique o tamanho máximo da tabela conntrack no nó afetado:

    kubectl exec -it -n kube-system daemonset/anetd -c cilium-agent -- cilium status --all-controllers | grep -i conntrack

    Se a tabela conntrack estiver cheia, escalonar horizontalmente horizontalmente suas cargas de trabalho em mais nós ou reduza a taxa de conexão dos pods de cliente.

Diagnosticar desequilíbrio de tráfego e redefinições de TCP

Revise o escopo do diagnóstico e os pré-requisitos antes de resolver problemas de desequilíbrio de tráfego e redefinições de conexão:

  • Área de foco:desigualdade no balanceamento de carga, falhas no handshake TCP, encerramento repentino da conexão.
  • Pré-requisitos:métricas do GKE Dataplane V2 ativadas.
  • Compatibilidade com CNI:GKE Dataplane V2.
  • Sintoma:algumas réplicas de pod recebem tráfego excessivo, enquanto outras permanecem inativas. Os aplicativos cliente registram connection reset by peer ou broken pipe.
  • Objetivo:determinar se o desequilíbrio de tráfego é causado pela fixação de conexão na camada de transporte (camada 4 do OSI, TCP) em vez da camada de aplicativo (camada 7 do OSI, HTTP/2 ou gRPC) e identificar a origem dos pacotes TCP RST.

Etapa 1: comparar o fluxo de tráfego no nível do pod

Para determinar se o tráfego está distribuído de maneira uniforme entre as réplicas, faça o seguinte:

  1. No Cloud Monitoring, consulte a contagem de fluxo de entrada em todos os pods de uma implantação:

    sum by (pod) (rate(pod_flow_ingress_flows_count{destination_workload="my-service"}[5m]))

  2. Avalie a distribuição de tráfego entre os pods. Se um único pod receber a maioria do tráfego, investigue a reutilização de conexões ou sessões fixas:

    • gRPC ou HTTP/2:conexões TCP de longa duração fazem com que todas as solicitações percorram um único fluxo TCP para um pod de back-end. O roteamento de serviços do Kubernetes na camada de transporte (camada 4 do OSI, TCP) não pode balancear solicitações em uma conexão HTTP/2 estabelecida.
    • Afinidade de sessão ClientIP:verifique se o serviço está configurado com sessionAffinity: ClientIP.
    • Serviços sem comando:os clientes podem resolver o DNS uma vez e armazenar em cache o único endereço IP permanentemente.

Etapa 2: analisar as métricas de redefinição de TCP

As redefinições de TCP (RST) encerram as conexões imediatamente. Eles são emitidos pelo kernel do sistema operacional quando um endpoint recebe um pacote para uma porta desconhecida ou quando um aplicativo fecha uma conexão com dados não lidos no buffer.

Execute a seguinte consulta MQL no Cloud Monitoring:

fetch prometheus_target
| metric 'prometheus.googleapis.com/hubble_tcp_flags_total/counter'
| filter (metric.flag == 'RST')
| align rate(1m)
| every 1m
| group_by [metric.source, metric.destination, metric.traffic_direction], sum(val())

Analise os resultados da consulta para determinar a origem da redefinição:

  • RST de saída (traffic_direction=egress): o pod local está gerando a redefinição. Verifique se o aplicativo do pod está falhando, atingindo o limite de conexão ou rejeitando ativamente a conexão.
  • RST de entrada (traffic_direction=ingress): o peer remoto (banco de dados externo, API ou pod remoto) enviou a redefinição. Verifique a integridade do servidor de destino e os estados do firewall.

Etapa 3: transmitir redefinições de TCP ao vivo

Use a CLI do Hubble para capturar o handshake de redefinição ativa:

gke-hubble observe --type trace --verdict FORWARDED --tcp-flags RST --namespace default

Etapa 4: correção e soluções práticas

Aplique as seguintes etapas de correção, dependendo da causa do desequilíbrio de tráfego ou das redefinições de TCP:

  • Para fixação de conexão na camada de aplicativo (camada 7 do OSI) ou gRPC:
    • Implante o Cloud Service Mesh para ativar o balanceamento de carga no nível da solicitação da camada de aplicativo (camada 7 do OSI).
    • Configure limites de conexão do lado do cliente ou tempos limite de sinal de atividade (por exemplo, MAX_CONNECTION_AGE e MAX_CONNECTION_AGE_GRACE do gRPC) para forçar o restabelecimento periódico da conexão.
  • Para afinidade de IP do serviço:remova service.spec.sessionAffinity, a menos que o estado do aplicativo exija isso.
  • Para o cache de DNS do serviço headless:verifique se os tempos de execução do aplicativo (como JVM networkaddress.cache.ttl) não armazenam em cache os resultados de DNS indefinidamente.
  • Para estouro da fila de pendências do aplicativo:quando uma fila de escuta do aplicativo está cheia, o kernel do Linux descarta pacotes SYN recebidos ou envia um TCP RST. Escalone horizontalmente as réplicas de pod ou aumente o backlog de escuta do aplicativo (somaxconn).

Nível 2: observabilidade de nó e CNI (kernel)

O nível do nó e da CNI abrange o kernel do Linux do host, os programas eBPF e as interfaces de rede do nó. Os gargalos nesse nível afetam todas as cargas de trabalho em execução no nó afetado.

Verificação de integridade do sistema: detecta patches não autorizados do anetd

O GKE Dataplane V2 é executado como um DaemonSet gerenciado (anetd) no namespace kube-system. No Cloud Logging, é possível consultar registros de auditoria do Kubernetes para detectar se usuários não autorizados ou scripts automatizados corrigiram ou reiniciaram anetd:

protoPayload.methodName="io.k8s.core.v1.daemonsets.patch" OR
protoPayload.methodName="io.k8s.core.v1.daemonsets.update"
protoPayload.resourceName="namespaces/kube-system/daemonsets/anetd"

Se um patch não autorizado for detectado, reverta o DaemonSet para a configuração padrão ou acione uma recriação do pool de nós para restaurar o estado gerenciado.

Triagem para latência no nível do nó e gargalos da CNI

Analise o escopo de diagnóstico e os pré-requisitos antes de diagnosticar a latência no nível do nó e os gargalos do kernel:

  • Área de foco:latência do kernel do host, perda de pacotes na interface da VM, saturação do agente eBPF do GKE Dataplane V2, esgotamento do conntrack.
  • Pré-requisitos:métricas de VM do Compute Engine ativadas; acesso ao kubectl.
  • Compatibilidade com CNI:GKE Dataplane V2 e CNI padrão do GKE.
  • Sintoma:o tráfego entre nós tem picos de latência ou quedas aleatórias, enquanto o tráfego dentro do nó permanece normal.
  • Objetivo:diferenciar entre a limitação de rede da VM host, as quedas do kernel do Linux e os gargalos no nível da CNI.

Etapa 1: diferenciar problemas fora e dentro do GKE

Execute o teste de comparativo de mercado de VM do Compute Engine: implante uma VM independente do Compute Engine na mesma sub-rede VPC que os nós do cluster do GKE. Teste a conectividade da VM com o destino.

  • Se a VM independente tiver as mesmas quedas de pacotes ou latência:o problema está fora do GKE (firewalls da VPC, Cloud NAT, Cloud Interconnect ou o servidor externo). Acesse Isolar problemas de conectividade do GKE versus VPC ou externa.
  • Se a VM independente se comunicar normalmente, mas os pods do GKE falharem:o problema está no GKE (eBPF no nível do nó, conntrack ou CNI). Prossiga para a etapa 2.

Etapa 2: diferenciar problemas de aplicativos de problemas de nós e da camada CNI

Para determinar se a latência se origina no aplicativo ou no nó e na camada de CNI, faça o seguinte:

  1. Verifique a saturação de recursos do aplicativo:verifique se o nó não está sofrendo limitação de CPU ou pressão de memória, o que atrasa o processamento de pacotes no espaço do usuário:

    kubectl top nodes
kubectl top pods -n default

  2. Inspecionar a contagem de conntrack do kernel do Linux:verifique a contagem de conntrack ativa no host:

    # On a node where you have debugging access
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

    Se nf_conntrack_count se aproximar de nf_conntrack_max, o kernel do host vai descartar novos pacotes TCP SYN.

Etapa 3: verificar descartes de pacotes no nível da VM usando a telemetria do Compute Engine

Google Cloud O Compute Engine exporta métricas de interface de rede no nível da VM para o Cloud Monitoring.

Em Cloud Monitoring > Metrics Explorer, consulte:

sum by (drop_reason) (rate(compute_googleapis_com:instance_network_dropped_packets_count[5m]))
  • FQ_CODEL_DROP: pacote descartado devido à saturação da fila Fair Queuing ou CoDel (limite de largura de banda de saída da VM excedido).
  • FIREWALL_RULE_DROP: pacote descartado por uma regra de firewall da VPC.
  • RATE_LIMIT_DROP: pacote descartado porque a VM excedeu a cota máxima de pacotes por segundo (PPS) da interface de rede.

Etapa 4: investigar quedas no nível do kernel usando eBPF

Se as métricas no nível da VM mostrarem zero quedas, mas os pods do GKE ainda descartarem pacotes, inspecione o agente do GKE Dataplane V2 (anetd) para verificar se há quedas de mapa eBPF:

kubectl logs -n kube-system daemonset/anetd -c cilium-agent --tail=200 | grep -i "drop"

Procure ct-map-insertion-failed ou fib-lookup-failed.

Nível 3: observabilidade de VPC e roteamento (rede de nuvem)

A VPC e a camada de roteamento na nuvem conectam nós do GKE a outros serviços Google Cloud , redes locais e a Internet. As falhas aqui geralmente decorrem de regras de firewall da VPC, rotas personalizadas ou configurações de gateway.

Isolar problemas de conectividade do GKE em relação à VPC ou a problemas externos

Revise o escopo de diagnóstico e os pré-requisitos antes de isolar problemas de rede externa de falhas no cluster:

  • Área de foco:isolamento de limites entre o roteamento interno do Kubernetes e o roteamento de nuvem da VPC.
  • Pré-requisitos:CLI gcloud e permissões para criar testes de conectividade.
  • Compatibilidade com CNI:todos os clusters.
  • Sintoma:os pods não conseguem se conectar a um recurso externo (por exemplo, Cloud SQL, uma API local ou um endpoint de terceiros).
  • Objetivo:determinar rapidamente se a queda ocorre no nó do GKE ou dentro da Google Cloud VPC ou rede externa.

Etapa 1: o teste de comparativo de mercado de VM do Compute Engine

Para implantar uma VM de referência e avaliar se o problema persiste fora do GKE, faça o seguinte:

  1. Implante uma instância de VM temporária do Compute Engine na mesma sub-rede e zona da VPC que seu pool de nós do GKE:

    gcloud compute instances create gke-baseline-tester \
    --zone=us-central1-a \
    --subnet=gke-subnet \
    --machine-type=e2-micro

  2. Conecte-se à instância usando SSH e teste a conectividade com o destino:

    curl -v --connect-timeout 5 https://api.example.com

  3. Avalie o resultado:

    • Se a VM do Compute Engine não conseguir se conectar:o problema está na VPC ou na rede externa (regras de firewall, tabelas de roteamento, esgotamento de IP do Cloud NAT ou inclusão de IP externo em uma lista de permissões).
    • Se a VM do Compute Engine se conectar:o problema está no GKE (NetworkPolicy bloqueando o tráfego de saída, CIDR do pod não mascarado ou DNS no nível do contêiner).

Etapa 2: executar um teste de conectividade sob demanda

Execute um teste de Google Cloud Testes de conectividade da VM do nó para o destino:

gcloud network-management connectivity-tests create test-node-to-dest \
    --source-instance=projects/PROJECT_ID/zones/us-central1-a/instances/gke-baseline-tester \
    --destination-ip-address=203.0.113.10 \
    --destination-port=443 \
    --protocol=TCP

Verifique o resultado no console Google Cloud para identificar se uma regra de firewall ou rota da VPC está interrompendo o tráfego.

Diagnosticar a conectividade usando testes de conectividade

Os Testes de conectividade simulam caminhos de pacotes em recursos do GKE e da VPC sem enviar tráfego ativo. Essa simulação avalia a resolução de DNAT de ClusterIP do serviço para pod, as regras de entrada e saída do NetworkPolicy do GKE Dataplane V2 e o mascaramento de IP do nó (SNAT). Revise o escopo de diagnóstico e os pré-requisitos antes de executar simulações de caminhos automatizadas:

  • Área de foco:simulação automatizada de caminhos estáticos para pods, serviços, NetworkPolicies e rotas de VPC do GKE.
  • Pré-requisitos:Network Intelligence Center e API Management ativados.
  • Compatibilidade com CNI:GKE Dataplane V2 (análise avançada).
  • Sintoma:quedas inexplicáveis de conectividade em que todas as configurações parecem válidas após inspeção manual.
  • Objetivo:simular e rastrear estaticamente todo o caminho do pacote de uma origem do pod até o destino, identificando a linha exata da política que causa uma queda.

Cenário A: verificar se uma NetworkPolicy do GKE está bloqueando a coleta de métricas

Ao extrair métricas de pods em um namespace seguro, os coletores do Google Cloud Managed Service para Prometheus podem ser bloqueados por uma NetworkPolicy de negação padrão:

gcloud network-management connectivity-tests create test-gmp-to-pod \
    --source-ip-address=10.0.0.15 \
    --destination-gke-pod=projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/k8s/namespaces/prod/pods/backend-pod \
    --destination-port=8080 \
    --protocol=TCP

Inspecione o rastreamento de teste no console do Google Cloud . Se o teste terminar na etapa GKE Network Policy evaluation com DROP, uma regra de entrada precisará ser adicionada para permitir o tráfego dos pods do coletor.

Cenário B: verificar a capacidade de acesso a um serviço do GKE

Simule a capacidade de acesso de uma VM cliente a um serviço interno do Kubernetes:

gcloud network-management connectivity-tests create test-vm-to-service \
    --source-instance=projects/PROJECT_ID/zones/us-central1-a/instances/client-vm \
    --destination-ip-address=10.96.0.100 \
    --destination-port=80 \
    --protocol=TCP

O trace simulado mostra:

  1. Correspondência de rota da VPC.
  2. Permissão de entrada e saída do firewall da VPC.
  3. Chegada ao nó do GKE.
  4. DNAT de serviço para endereço IP do pod de back-end.
  5. Avaliação da NetworkPolicy de entrada no pod de back-end.

Cenário C: diagnosticar problemas de saída de pod para a Internet

Quando os pods não conseguem acessar uma API externa na Internet:

  1. Crie um teste do pod para o endereço IP público externo (como 8.8.8.8):

    gcloud network-management connectivity-tests create test-pod-to-internet \
    --source-gke-pod=projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/k8s/namespaces/prod/pods/app-pod \
    --destination-ip-address=8.8.8.8 \
    --destination-port=53 \
    --protocol=UDP

  2. Examine o ponto de soltar:

    • Descartado na NetworkPolicy:o pod não tem uma NetworkPolicy de saída que permita o tráfego para 0.0.0.0/0.
    • Descartado no firewall da VPC:uma regra de firewall da VPC nega o tráfego de saída da sub-rede do nó.
    • Descartado no Cloud NAT ou na rota:a sub-rede não tem uma rota padrão para o gateway de Internet ou o Cloud NAT não está configurado para a sub-rede.

Nível 4: observabilidade de gateway externo e custo (Internet e NAT)

O nível do gateway externo gerencia o tráfego de saída para destinos da Internet pública usando o Cloud NAT ou gateways externos. A capacidade de observação nesse nível ajuda a identificar cargas de trabalho de alta saída e controlar os custos de transferência de dados.

Identificar o tráfego NAT (saída para a Internet)

Confira o escopo de diagnóstico e os pré-requisitos antes de analisar o tráfego de saída da Internet e de NAT:

  • Área de foco:tráfego de saída da Internet, utilização de portas do Cloud NAT e custos de transferência de dados externos.
  • Pré-requisitos:a observabilidade de fluxo do GKE Dataplane V2 precisa estar ativada.
  • Compatibilidade com CNI:GKE Dataplane V2.
  • Sintoma:erros de esgotamento de porta do Cloud NAT ou custos de saída da Internet inesperadamente altos.
  • Objetivo:identificar quais objetos específicos de pod e serviço do GKE estão transmitindo tráfego para endpoints externos da Internet.

Etapa 1: entender os conceitos "to-stack" e "world" no GKE Dataplane V2

No GKE Dataplane V2:

  • world: representa qualquer destino fora do cluster do GKE e da VPC (a Internet pública).
  • to-stack: representa pacotes que fazem a transição da interface veth do contêiner eBPF para a pilha de rede Linux do host para passar pelo mascaramento de IP (SNAT) antes de chegar ao Cloud NAT.

Etapa 2: transmitir e filtrar o tráfego NAT com a CLI do Hubble

Transmita fluxos de saída da Internet ao vivo originados do seu cluster:

# Stream egress flows heading to external internet ("world")
gke-hubble observe \
    --traffic-direction egress \
    --verdict FORWARDED \
    --to-identity world \
    --follow

Exemplo de saída:

TIMESTAMP             SOURCE               DESTINATION          TYPE     VERDICT
10:25:01.120          default/worker-pod   142.250.190.46:443   to-stack FORWARDED

Para identificar os principais falantes de saída, também é possível transmitir a saída JSON do Hubble para jq e contar os fluxos de saída externos por pod:

timeout 60s gke-hubble observe \
    --traffic-direction egress \
    --verdict FORWARDED \
    --to-identity world \
    -o json | jq -r '.flow.source.namespace + "/" + .flow.source.pod_name' | sort | uniq -c | sort -nr | head -n 10

Etapa 3: monitorar o tráfego externo usando métricas

No Cloud Monitoring, acompanhe o volume de fluxos externos:

fetch prometheus_target
| metric 'prometheus.googleapis.com/pod_flow_egress_flows_count/counter'
| filter (metric.destination_identity == 'world')
| align rate(1m)
| every 1m
| group_by [metric.source_workload, metric.source_namespace], sum(val())

Analisar os custos e a performance do tráfego do cluster usando o Flow Analyzer

Revise o escopo do diagnóstico e os pré-requisitos antes de visualizar os fluxos de tráfego e os custos entre zonas:

  • Área de foco:custos de transferência de dados entre zonas, principais comunicadores, visibilidade do tráfego entre nós sem consultas SQL.
  • Pré-requisitos:registros de fluxo de VPC ativados com INCLUDE_ALL_METADATA; visibilidade intranós ativada; Análise de Observabilidade ativada no bucket de registros.
  • Compatibilidade com CNI:todos os clusters.
  • Sintoma:aumento nas cobranças de transferência de dados entre zonas nas faturas mensais de Google Cloud .
  • Objetivo:identificar visualmente quais cargas de trabalho do GKE estão gerando tráfego entre zonas e otimizar o posicionamento sem consultar registros brutos.

Pré-requisitos

Para usar o Flow Analyzer no GKE:

  1. Registros de fluxo de VPC:precisam ser ativados na sub-rede do cluster com metadata="INCLUDE_ALL_METADATA".
  2. A visibilidade intranós precisa estar ativada no cluster para que o tráfego de pod para pod seja exposto ao pipeline de registros de fluxo da VPC.
  3. Análise de dados de registros:o bucket _Default no Cloud Logging precisa ser atualizado para usar a Análise de observabilidade.

Etapa 1: identificar os principais tráfegos do GKE no Flow Analyzer

Para ver cargas de trabalho de alto volume no Flow Analyzer, faça o seguinte:

  1. No console do Google Cloud , acesse a página Flow Analyzer.
  2. Clique em Bucket de origem e selecione o bucket de registros que contém os registros de fluxo. A menos que você os tenha encaminhado para outro lugar, esse é o bucket _Default.
  3. Em Agregação de tráfego, selecione Origem - Destino.
  4. Defina o período da janela de análise.
  5. Em Organizar fluxos por, selecione os campos de pod ou carga de trabalho do GKE.
  6. Clique em Executar nova consulta. O gráfico Fluxos de dados mais altos mostra quais cargas de trabalho movem mais dados.

Etapa 2: analisar os custos de tráfego entre zonas

O tráfego entre zonas gera cobranças de transferência de dados. Para localizar cargas de trabalho transmitindo entre zonas:

  1. Em Organizar fluxos por, selecione os campos de zona de origem e zona de destino.
  2. Clique em Executar nova consulta e leia a tabela Todos os fluxos de dados. As linhas em que as zonas de origem e destino são diferentes representam seu tráfego entre zonas. Os filtros do Flow Analyzer correspondem a valores. Portanto, não é possível filtrar por "diferente". Em vez disso, compare os pares de zonas nos resultados.
  3. Expanda um par de zonas de alto volume para ver as cargas de trabalho do GKE de origem e destino.

Remediação:

  • Implemente topologySpreadConstraints ou podAffinity do Kubernetes para colocar serviços de comunicação na mesma zona de disponibilidade.
  • Ative o Roteamento ciente de topologia (service.kubernetes.io/topology-mode: Auto) no serviço para manter o tráfego na zona de origem.

Etapa 3: detalhar a análise de observabilidade (para consultas SQL avançadas)

No Flow Analyzer, clique em Ver na Análise de dados de registros para executar consultas SQL nos dados de fluxo.

A consulta SQL a seguir calcula os principais comunicadores de pods entre zonas:

SELECT
  JSON_VALUE(json_payload.src_gke_details.pod.workload.workload_name) AS src_workload,
  JSON_VALUE(json_payload.dest_gke_details.pod.workload.workload_name) AS dest_workload,
  JSON_VALUE(json_payload.src_instance.zone) AS src_zone,
  JSON_VALUE(json_payload.dest_instance.zone) AS dest_zone,
  SUM(CAST(JSON_VALUE(json_payload.bytes_sent) AS INT64)) / 1024 / 1024 / 1024 AS total_gb_sent
FROM
  `PROJECT_ID.global._Default._AllLogs`
WHERE
  log_name LIKE '%vpc_flows%'
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND JSON_VALUE(json_payload.src_instance.zone) != JSON_VALUE(json_payload.dest_instance.zone)
GROUP BY
  1, 2, 3, 4
ORDER BY
  total_gb_sent DESC
LIMIT 20;

Referência da CLI do Hubble e folha de referência de consultas

A CLI do Hubble transmite e filtra dados de fluxo de rede em tempo real diretamente do buffer de anel do kernel do GKE Dataplane V2.

Configuração: criar um alias auxiliar

Como o Hubble é executado no plano de controle do cluster, configure um alias de shell para executar comandos do Hubble sem implantar binários locais:

alias gke-hubble="kubectl exec -it -n gke-managed-dpv2-observability deployment/hubble-relay -c hubble-cli -- hubble"

Receitas de filtragem comuns

Objetivo de solução de problemas Comando da CLI do Hubble
Observe todos os pacotes descartados em tempo real no cluster gke-hubble observe --verdict DROPPED --follow
Transmitir todo o tráfego de um pod específico em qualquer namespace gke-hubble observe --pod default/my-pod --follow
Filtrar o tráfego entre dois namespaces específicos gke-hubble observe --from-namespace frontend --to-namespace backend
Isolar o tráfego em uma porta específica (como a porta 80) gke-hubble observe --port 80
Inspecionar consultas e respostas de DNS ativas gke-hubble observe --port 53
Ver redefinições de TCP ativas (pacotes RST) gke-hubble observe --type trace --verdict FORWARDED --tcp-flags RST
Transmitir todo o tráfego de saída para a Internet pública gke-hubble observe --traffic-direction egress --to-identity world
Inspecionar o tráfego da camada de aplicativo HTTP (camada 7 do OSI) gke-hubble observe --protocol http

Filtragem avançada com negação (--not)

Você pode excluir tráfego conhecido de alto volume ou normal para se concentrar em anomalias:

# Observe drops, but exclude internal kube-system health probes and DNS
gke-hubble observe \
    --verdict DROPPED \
    --not --namespace kube-system \
    --not --port 53

Formatação de saída e integração do jq

Para processar registros de fluxo de maneira programática, gere a saída no formato JSON:

# Extract only source, destination, and drop reason from the last 100 flows
gke-hubble observe --verdict DROPPED -o json --last 100 | \
    jq -r '[.time, .flow.source.pod_name, .flow.destination.pod_name, .flow.drop_reason_desc] | @tsv'

Limitações

Ao usar a CLI do Hubble para solução de problemas em tempo real, lembre-se das seguintes limitações técnicas:

  • Buffer de anel efêmero local do nó:os fluxos do Hubble são armazenados em um buffer de anel na memória em cada nó individual. Durante eventos de alto tráfego, os registros de fluxo mais antigos são substituídos em segundos. Para análises históricas, use o registro em log do NetworkPolicy e os registros de fluxo da VPC no Cloud Logging.
  • Sem OR lógico integrado:as flags da CLI do Hubble avaliam vários argumentos usando AND lógico. Para pesquisar várias condições (como "Porta 80 OU Porta 443"), execute comandos separados ou filtre a saída JSON usando jq.

A seguir