VPC Flow Logs no GKE: como diagnosticar tráfego de workloads mais rápido, segundo o Google Cloud

O problema que o Google descreve é conhecido de quem opera Kubernetes: pods são efêmeros e o IP muda a cada escala, falha ou migração entre nós. Um registro de flow log com dois IPs soltos diz pouco, e quando você consulta o cluster o pod pode já ter sumido. O VPC Flow Logs resolve isso na camada de rede. Cada fluxo amostrado recebe os metadados do GKE dono do IP no momento da amostragem: cluster, pod, namespace, controller (deployment, StatefulSet ou DaemonSet), serviço, nó e zona. Não há agente nem sidecar, e o recurso complementa as ferramentas de observabilidade de CNI e dataplane que você já rode dentro do cluster.

A configuração tem três passos: fazer upgrade do bucket de logs (normalmente o _Default) para Observability Analytics, o que é permanente; habilitar o VPC Flow Logs na organização com include-all-metadata; e ligar a intranode visibility nos clusters Standard. Esse último passo reinicia componentes do control plane e dos nós e adiciona overhead por nó, então o texto recomenda testar antes fora de produção. Para custo, dá para reduzir volume com taxa de amostragem secundária, intervalo de agregação ou filtro.

O Flow Analyzer, parte do Network Intelligence Center, transforma os registros em gráfico e tabela. Os três casos do Google, rodados em um Online Boutique num cluster Autopilot, são: mapear dependências por nome de workload, detalhar quem chama um serviço (como o productcatalogservice) e achar pods que conversam entre zonas com o filtro SQL src_gcp_zone <> dest_gcp_zone. O terceiro tem impacto direto em custo, já que tráfego entre zonas gera cobrança de transferência. A sugestão do Google é usar trafficDistribution: PreferSameZone (PreferClose em versões mais antigas) no Service, com réplicas suficientes em cada zona.

Há limites. Tráfego de pod para a internet não traz anotações, porque o masquerade troca o IP do pod pelo do nó antes da amostragem. Tráfego bloqueado por network policy nunca chega à VPC, então exige NetworkPolicy logging. E a amostragem serve para ranking e tendência, não para contabilidade por conexão.

Para quem opera GKE, a leitura é prática: se os flow logs já estão ligados, o ganho de diagnóstico vem quase de graça, sem instrumentar nada. O caso de tráfego entre zonas também serve como ponto de partida para cortar custo de rede. Já a intranode visibility nos clusters Standard merece janela de mudança e teste prévio, por causa dos reinícios.