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 quedas 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 da 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 de segurança 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 pods e serviços (aplicativos)

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 do 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 a 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 53 UDP ou TCP ou uma degradação da rede upstream.

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

Antes de resolver problemas de camadas de DNS, verifique se o destino pode ser acessado diretamente usando o endereço IP 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 quedas 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 é 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 de 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 O limite de consultas simultâneas foi 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, ausências no cache e tempos limite de 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, os aplicativos podem estar 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 forwarding_request_latencies alto indica problemas com o servidor DNS upstream (por exemplo, DNS corporativo local alcançado pelo Cloud Interconnect ou 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 de 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 de 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 as perdas de pacotes e as negações de política:

  • Á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 que está descartando pacotes sem mudanças de 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

A geração de registros do NetworkPolicy exporta registros JSON estruturados para todas as decisões baseadas em 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 se há 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 de 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 é 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 maior parte do tráfego, investigue a reutilização de conexões ou as 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 da 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

Siga as etapas de correção abaixo, 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 manutenção ativa (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 de serviço:remova service.spec.sessionAffinity, a menos que o estado do aplicativo exija isso.
  • Para o armazenamento em cache de DNS de serviço headless:verifique se os ambientes 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 os 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, quedas 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 a kubectl.
  • Compatibilidade com CNI:GKE Dataplane V2 e CNI padrão do GKE.
  • Sintoma:o tráfego entre nós apresenta picos de latência ou quedas aleatórias, enquanto o tráfego dentro do nó permanece íntegro.
  • 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. Inspecione 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 descartará novos pacotes TCP SYN.

Etapa 3: verificar as perdas 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 as quedas no nível do kernel usando o 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 por ct-map-insertion-failed ou fib-lookup-failed.

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

O nível de roteamento de VPC e Cloud Router conecta os nós do GKE a outros serviços do Google Cloud , redes locais e à 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 referência da 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 \
    --round-trip

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 os 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). Analise o escopo de diagnóstico e os pré-requisitos antes de executar simulações de caminho 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 de 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 \
    --round-trip

Inspecione o trace 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 acessibilidade de uma VM cliente para 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 \
    --round-trip

O trace simulado mostra:

  1. Correspondência de rota da VPC.
  2. Permissão de saída e entrada 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 \
    --round-trip

  2. Examine o ponto de entrega:

    • 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 de gateway externo gerencia o tráfego de saída para destinos públicos da Internet por meio do Cloud NAT ou de 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)

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

  • Área de foco:tráfego da internet de saída, 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 de dados para a 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 externos, 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

Analise o escopo de 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ó ativada; Análise de Observabilidade ativada no bucket de registros.
  • Compatibilidade com CNI:todos os clusters.
  • Sintoma:cobranças elevadas de transferência de dados entre zonas nas faturas mensais doGoogle 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. Visibilidade intranós:precisa estar ativada no cluster para que o tráfego de pod para pod seja exposto ao pipeline de geração 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 o 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 o topologySpreadConstraints ou o 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 DNS e respostas gke-hubble observe --port 53
Ver redefinições de TCP em tempo real (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 local de nó temporário: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