Google Cloud mostra como usar VPC Flow Logs para agilizar o troubleshooting de workloads no GKE

O problema de fundo é a natureza efêmera dos pods. Um registro de flow log com 10.4.2.18 falando com 10.4.8.44 diz pouco, porque o pod dono daquele IP pode já ter sumido quando alguém vai investigar. Como a rede virtual do Google Cloud enxerga cada conexão, cada fluxo amostrado é gravado com os metadados do GKE: cluster, pod, namespace, controller dono (Deployment, StatefulSet ou DaemonSet), serviço, além de nó e zona nas duas pontas. Isso vale para tráfego L3/L4 e dispensa agentes ou sidecars. Quem registra workloads no App Hub ganha ainda os rótulos apphubSource e apphubDestination.

O setup tem três passos: atualizar o bucket _Default para Observability Analytics (mudança permanente), habilitar VPC Flow Logs em nível de organização com include-all-metadata, e ligar a visibilidade intranode nos clusters Standard (nos Autopilot ela já vem ativa). Ligar a visibilidade intranode reinicia componentes do control plane e dos nós, então o texto recomenda testar antes em cluster fora de produção. Com o Flow Analyzer, os três casos na Online Boutique são: mapear dependências por nome de workload, ver os chamadores de um serviço (productcatalogservice) com a agregação bidirecional, e achar pares de pods que cruzam zonas com o filtro SQL src_gcp_zone <> dest_gcp_zone. Para o tráfego entre zonas, a sugestão é trafficDistribution: PreferSameZone no Service, com réplicas suficientes em cada zona.

As limitações são explícitas. 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 NetworkPolicy nunca chega à VPC, e aí o caminho é o logging de NetworkPolicy. E como os logs são amostrados, bytes e pacotes servem para ranking e tendência, não para contabilidade por conexão.

Em 28 de outubro de 2026, o CEVIU noticiou "VPC Flow Logs no GKE: como diagnosticar tráfego de workloads mais rápido, segundo o Google Cloud", que apresentava a mesma ideia: saber quem fala com quem para delimitar problemas. A notícia desta data cobre o detalhamento do guia, com os passos de configuração, os três casos práticos no Flow Analyzer e as ressalvas de uso.

Para quem opera GKE, isso encurta o caminho entre "o serviço ficou lento" e "quem está chamando quem" sem instalar nada no cluster. A consulta de tráfego entre zonas também toca custo: ela aponta pares de pods que geram transferência inter-zona, o que ajuda a priorizar ajustes de distribuição de tráfego. Antes de ligar tudo em nível de organização, vale pesar o custo de volume de logs e usar amostragem e filtros.