Práticas recomendadas para observabilidade de rede do GKE

Gerenciar a conectividade de rede e as políticas de segurança em ambientes dinâmicos do Kubernetes apresenta desafios operacionais significativos. A observabilidade do GKE Dataplane V2 oferece aos administradores de plataforma visibilidade no nível do kernel do tráfego de rede do cluster, o que ajuda a ativar a solução rápida de problemas, a auditoria contínua de compliance e a validação proativa de caminhos.

Este documento descreve a arquitetura conceitual e as práticas recomendadas para a observabilidade de rede do Google Kubernetes Engine (GKE), incluindo a pilha de telemetria, um modelo mental para triagem, regras de alerta proativas, automação do Terraform e técnicas de otimização de custos.

Para instruções detalhadas de solução de problemas e procedimentos de diagnóstico, consulte Resolver problemas de observabilidade de rede.

Benefícios da observabilidade de rede do GKE

Implementar uma estratégia de observabilidade no GKE oferece as seguintes vantagens principais:

  • Tempo médio para resolução (MTTR) acelerado: ao aproveitar as métricas com tecnologia eBPF e os registros de fluxo do Hubble, é possível isolar imediatamente as anomalias de rede. Essa visibilidade permite distinguir entre falhas no nível do aplicativo, bloqueios de NetworkPolicy do Kubernetes e descartes de firewall da VPC, reduzindo os ciclos de depuração de horas para minutos.
  • Instrumentação no nível do kernel sem sidecars:o GKE Dataplane V2 executa a lógica de observabilidade diretamente no kernel Linux do host usando o eBPF. Isso elimina a necessidade de proxies sidecar com uso intensivo de recursos ou modificações no código no nível do aplicativo, garantindo sobrecarga mínima e preservando o desempenho do aplicativo.
  • Auditoria contínua de conformidade com a segurança:o registro em log do NetworkPolicy gera registros de auditoria detalhados para cada tentativa de conexão (vereditos de ALLOW ou DENY). Esses registros fornecem um registro inviolável do tráfego do cluster, essencial para atender às estruturas de conformidade regulatória (como PCI-DSS, SOC 2 e HIPAA).
  • Validação proativa de caminhos:a integração com os Testes de conectividade permite simular caminhos de rede e avaliar as NetworkPolicies do GKE de forma estática antes da implantação das cargas de trabalho, evitando desvios de configuração e problemas de conectividade na fase de implantação.
  • Otimização de recursos e custos:o rastreamento detalhado do fluxo expõe ineficiências, como utilização excessiva de portas do Cloud NAT, picos de transferência de dados entre zonas e padrões de resolução de DNS não armazenados em cache, permitindo um planejamento de capacidade e uma gestão de custos informados.

Arquitetura de observabilidade de rede do GKE

O GKE Dataplane V2 oferece uma pilha de observabilidade multicamadas projetada para diferentes fases operacionais. A tabela a seguir descreve os componentes principais e os casos de uso recomendados:

Componente de observabilidade Caso de uso principal Disponibilidade Retenção de dados Sobrecarga no desempenho Principais indicadores de telemetria
Métricas do GKE Dataplane V2 Monitoramento da integridade, análise de tendências e alertas em todo o sistema. Somente GKE Dataplane V2 Retenção de telemetria histórica (o Cloud Monitoring e o Google Cloud Managed Service para Prometheus armazenam 30 dias ou mais de métricas e registros) Negligível (agregação no nível do kernel) Contadores de pacotes e bytes, contagens de redefinição de TCP e taxas de queda de conexão (pod_flow_drop_count).
Registros do NetworkPolicy Auditoria da política de segurança, análise histórica de conexões e compliance. Somente GKE Dataplane V2 (para configuração de recursos personalizados do NetworkLogging) Configurável (Cloud Logging) Baixa (exportação de registros em buffer) Metadados de conexão (rótulos de origem e destino, endereços IP, portas) e veredictos de política (ALLOW ou DENY).
CLI e UI do Hubble Análise de tráfego interativa e em tempo real e depuração no nível do pacote. Somente GKE Dataplane V2 Temporário (buffer de anel local do nó) Baixa (ativar dinamicamente) Rastreamentos de fluxo em tempo real, motivos detalhados de descarte (como negação de política ou saturação da tabela conntrack).
Métricas de DNS do GKE Monitoramento do desempenho da resolução de DNS, da eficiência do cache e da latência upstream. Todos os clusters Longo prazo (Cloud Monitoring) Insignificante Contagem de solicitações DNS, taxa de ocorrência e falha de cache, latência de encaminhamento upstream e rejeições de limite simultâneo.
Testes de conectividade Validação de caminho pré-implantação e auditoria de configuração estática. Todos os clusters Não aplicável (simulação sob demanda) Nenhuma (simulada estaticamente) Caminho de roteamento de pacotes simulado, incluindo a avaliação simulada de NetworkPolicy.
Registros de fluxo de VPC Auditoria de tráfego entre nós e externo, perícia forense de segurança e análise de custos. Todos os clusters Configurável (Cloud Logging ou BigQuery) Nenhuma (taxa de amostragem configurável) Detalhes da conexão de 5 tuplas, bytes e pacotes enviados, metadados do GKE (namespace, carga de trabalho, serviço) e RTT (para TCP).
Flow Analyzer Análise visual do tráfego da VPC, identificação dos principais comunicadores e análise dos custos entre zonas sem escrever consultas SQL. Todos os clusters Depende da retenção do bucket da Análise de observabilidade Nenhum (UI analítica) Volume de tráfego agregado e latência agrupados por carga de trabalho ou serviço do GKE.

Na tabela anterior, uma sobrecarga de desempenho Negligível significa que os componentes permanecem estritamente dentro de uma pegada de recursos mínima (normalmente <0,1 vCPU e memória mínima), independente do volume de tráfego ou da escala do sistema. Os componentes baixos mantêm uma pegada mínima em condições padrão, mas são dimensionados dinamicamente com a densidade do tráfego. Em cenários de alta capacidade de processamento, o uso de recursos pode escalonar verticalmente até 2 vCPUs e várias centenas de megabytes de memória.

Modelo mental e loop de triagem da observabilidade do GKE

Para resolver problemas de anomalias de rede de maneira eficaz, selecione o indicador de telemetria adequado para seu escopo operacional e siga uma metodologia de triagem consistente.

Escolher a fonte de telemetria certa

Com várias fontes de telemetria disponíveis, escolha a ferramenta que se adapta à sua tarefa operacional atual:

Origem da telemetria Respostas Ideal para Google Cloud destino
Métricas do GKE Dataplane V2 O que está acontecendo e em que escala? Painéis, alertas e planejamento de capacidade. Cloud Monitoring (prometheus.googleapis.com)
Registros do NetworkPolicy Por que uma conexão foi bloqueada no GKE? Auditorias de segurança e análise da causa raiz da política de segurança. Cloud Logging (registro policy-action)
Registros de fluxo de VPC O que aconteceu com esse tráfego depois que ele saiu do pod? Análise histórica de tráfego entre cargas de trabalho, custos de transferência de dados entre zonas e atribuição de desconexão no nível da VPC. Cloud Logging e análise de observabilidade (vpc_flows registro)
CLI e UI do Hubble O que está passando pelo nó agora? Depuração ao vivo, alternativa ao tcpdump e incidentes ativos. Buffer de anel temporário (CLI do Hubble)
Testes de conectividade O tráfego pode viajar com sucesso? Testagem ativa do plano de dados e análise de caminhos: verifique a capacidade de acesso e identifique pontos de interrupção exatos em firewalls, rotas e nós do GKE da VPC. Network Intelligence Center (simulação)

Ciclo de solução de problemas padronizado

Use este fluxo de trabalho repetível para triagem de qualquer incidente de rede do GKE:

  1. Detectar anomalias:identifique o problema com alertas do Cloud Monitoring (por exemplo, picos em redefinições de TCP, rejeições de limite simultâneo de DNS ou perda de pacotes).
  2. Isolar a camada:execute o teste de comparativo de mercado da VM do GCE (consulte Triagem para latência no nível do nó e gargalos de CNI) para determinar se o bloqueio está dentro do cluster do GKE (CNI, NetworkPolicy, mascaramento de IP) ou fora na VPC (regras de firewall, roteamento, Cloud NAT).
  3. Investigue a causa raiz:faça uma análise detalhada do fluxo:
    • Para incidentes ativos, use a CLI do Hubble (hubble observe) para transmitir fluxos em tempo real e identificar motivos de queda.
    • Para problemas históricos ou intermitentes, consulte os registros do NetworkPolicy ou os registros de fluxo da VPC no Cloud Logging.
  4. Validar a correção:execute um teste simulado dos Testes de Conectividade para verificar se o caminho é permitido de forma estática e confira o painel de métricas para confirmar se a taxa de desistência voltou a zero.

Monitoramento e alertas proativos de rede

Para manter a alta disponibilidade, os administradores da plataforma precisam estabelecer políticas de alerta no Cloud Monitoring para identificar a degradação da rede antes que ela afete as cargas de trabalho.

Alerta sobre picos de descarte de pacotes

Um aumento anômalo no número de fluxos de rede descartados geralmente indica uma política de segurança mal configurada ou o esgotamento do rastreamento de conexão (conntrack) no nível do nó.

  • Consulta do Prometheus (PromQL):

    sum(rate(pod_flow_egress_flows_count{verdict="DROPPED"}[5m])) by (source) > 10

  • Ação recomendada:consulte Diagnosticar quedas de pacotes e bloqueios de NetworkPolicy para isolar o motivo específico da queda de NetworkPolicy ou eBPF do GKE que está causando a perda de pacotes.

Alerta sobre saturação de DNS

Quando o CoreDNS ou o NodeLocal DNSCache atingem o limite de consultas simultâneas, as buscas de DNS subsequentes são rejeitadas, resultando em tempos limite intermitentes do aplicativo.

  • Consulta do Prometheus (PromQL):

    sum by (cluster_name) (rate(kubernetes_io_networking_dns_kubedns_max_concurrent_rejected_request_count[5m])) > 0

  • Ação recomendada:ajuste o número de réplicas do kube-dns ou implemente o NodeLocal DNSCache para distribuir a carga de resolução. Para conferir as etapas detalhadas, consulte Diagnosticar falhas na resolução de DNS.

Alerta sobre picos de redefinição de TCP

Um pico nos pacotes de redefinição de TCP geralmente indica que um serviço de back-end está rejeitando conexões, possivelmente devido a loops de falha de aplicativo ou saturação da fila de soquetes.

  • Linguagem de consulta do Monitoring (MQL):

    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], sum(val())
| condition val() > 50

  • Ação recomendada:consulte Diagnosticar desequilíbrio de tráfego e redefinições de TCP para investigar a fixação de conexão ou a saturação da fila de aplicativos.

Validação automatizada de caminhos em CI/CD

Integre os testes de conectividade aos pipelines de implantação para validar os caminhos de rede de forma estática antes de rotear o tráfego de produção. Use a CLI gcloud para verificar se as cargas de trabalho recém-implantadas podem alcançar dependências externas (como bancos de dados e APIs) sem bloqueios de política.

  • Exemplo de comando:

    gcloud network-management connectivity-tests create test-prod-db-egress \
    --source-gke-pod=projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/k8s/namespaces/prod/pods/my-app-pod \
    --destination-ip-address=10.240.0.100 \
    --protocol=TCP \
    --destination-port=5432

Ativar a análise de observabilidade para análise visual de fluxo

Para ativar a análise visual e sem SQL dos fluxos de tráfego da VPC, faça upgrade do bucket de registros do GKE (normalmente o bucket _Default) para usar a Análise de observabilidade. Assim, os administradores da plataforma podem usar o Flow Analyzer para investigar a distribuição de tráfego e os custos de transferência de dados. Para mais informações, consulte Analisar custos e desempenho do tráfego de cluster usando o Flow Analyzer.

Automação do Terraform: observabilidade como código

Para implementar essa arquitetura de observabilidade de forma consistente e evitar erros de configuração manual, implante o pipeline de telemetria usando a seguinte configuração do Terraform (requer o provedor google-beta):

# Configure the VPC Subnet with VPC Flow Logs enabled and all metadata included
resource "google_compute_subnetwork" "gke_subnet" {
  name          = "gke-subnet"
  ip_cidr_range = "10.0.0.0/20"
  region        = "us-central1"
  network       = google_compute_network.custom.id

  # Enable VPC Flow Logs. flow_sampling is the secondary sampling rate, which
  # applies to flow log entries after they are generated. The primary packet
  # sampling rate is dynamic and isn't configurable.
  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 0.5 # Default rate; satisfies the LIGHT org policy tier
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

# Configure GKE Cluster with Dataplane V2, Intranode Visibility, and Hubble
resource "google_container_cluster" "primary" {
  provider   = google-beta
  name       = "gke-observability-cluster"
  location   = "us-central1"
  network    = google_compute_network.custom.id
  subnetwork = google_compute_subnetwork.gke_subnet.id

  # Enable Dataplane V2 (Required for all advanced telemetry)
  datapath_provider = "ADVANCED_DATAPATH"

  # Enable Intranode Visibility (ensures local node pod-to-pod traffic hits the VPC)
  enable_intranode_visibility = true

  # Enable Managed Service for Prometheus (GMP)
  monitoring_config {
    enable_components = ["SYSTEM_COMPONENTS"]
    managed_prometheus {
      enabled = true
    }

    # Enable Dataplane V2 Flow Observability (Hubble Relay and metric exposure)
    advanced_datapath_observability_config {
      enable_metrics = true
      enable_relay   = true
    }
  }
}

# Upgrade the Default log bucket to use Log Analytics (required for Flow Analyzer)
resource "google_logging_project_bucket_config" "default_analytics" {
  project          = var.project_id
  location         = "global"
  bucket_id        = "_Default"
  enable_analytics = true
}

# Define a baseline static path validation test (Pod to external internet gateway)
resource "google_network_management_connectivity_test" "pod_to_internet" {
  name = "pod-to-internet-egress"
  source {
    gke_pod = "projects/${var.project_id}/locations/us-central1/clusters/${google_container_cluster.primary.name}/k8s/namespaces/prod/pods/my-app-pod"
  }
  destination {
    ip_address = "8.8.8.8"
    port       = 443
  }
  protocol = "TCP"
}

Otimização de custos e redução de ruído

A telemetria de rede (métricas e registros) pode gerar volumes de dados substanciais, resultando em custos altos de ingestão e armazenamento. Use as estratégias a seguir para otimizar a coleta de telemetria sem perder a visibilidade do tráfego crítico:

Desativar registros de conexões permitidas

Por padrão, a geração de registros de NetworkPolicy captura conexões permitidas e negadas. As conexões permitidas dominam o volume de registros (geralmente 99% ou mais do tráfego). É possível atualizar a configuração NetworkLogging do cluster para capturar apenas conexões negadas (descartadas), o que reduz drasticamente os custos de geração de registros:

  1. Salve o seguinte manifesto como network-logging-config.yaml:

    apiVersion: networking.gke.io/v1alpha1
kind: NetworkLogging
metadata:
  name: default
spec:
  cluster:
    allow:
      log: false # Disable logging for allowed traffic
      delegate: false
    deny:
      log: true  # Keep logging for blocked traffic (critical for security/triage)
      delegate: false

  2. Aplique a configuração:

    kubectl apply -f network-logging-config.yaml

Delegar geração de registros usando anotações

Para um controle de custos preciso, delegue o registro em log às anotações definindo delegate: true no recurso personalizado NetworkLogging. Essa configuração garante o seguinte:

  • O tráfego permitido só será registrado se o NetworkPolicy correspondente tiver a anotação policy.network.gke.io/enable-logging: "true".
  • O tráfego negado é registrado apenas para objetos de pod em namespaces anotados com policy.network.gke.io/enable-deny-logging: "true".

Essa configuração permite ativar a geração de registros apenas para cargas de trabalho altamente críticas (como gateways de pagamento) e ignorar serviços ruidosos e de baixo risco.

Ajustar a taxa de amostragem dos registros de fluxo de VPC

Na configuração do Terraform (ou no console Google Cloud ), diminua a taxa de amostragem secundária apenas nas sub-redes em que você precisa de volume de tráfego e agregados de custo, em vez de registros de fluxo individuais. Como os registros de fluxo de VPC estimam o tráfego total com base em pacotes amostrados, as contagens de bytes e pacotes continuam sendo úteis para análise de custos em taxas mais baixas. Não defina a taxa de flow_sampling abaixo de 0.1, a taxa mínima que atende ao nível ESSENTIAL da política da organização constraints/compute.requireVpcFlowLogs:

resource "google_compute_subnetwork" "gke_subnet" {
  # ... other subnet configs ...
  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 0.1 # ESSENTIAL tier: volume and cost analysis, not per-flow troubleshooting
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

A tabela a seguir resume as taxas de amostragem secundárias e os níveis correspondentes da política da organização constraints/compute.requireVpcFlowLogs:

Taxa de amostragem secundária Nível da política da organização Quando usar
1.0 COMPREHENSIVE Clusters com um requisito permanente para perícia ou auditoria de segurança por fluxo. Escolha essa taxa ao configurar a sub-rede, porque aumentar a taxa depois de um incidente não recupera fluxos que nunca foram capturados.
0.5 (padrão) LIGHT Sub-redes que fazem backup dos clusters que você está solucionando. Essa é a taxa padrão e o valor de referência recomendado.
0.1 ESSENTIAL Sub-redes em que você precisa de agregados de custo e volume de tráfego em vez de fluxos individuais.

Aplicar exclusões do Cloud Logging

Exclua registros ruidosos ou irrelevantes (como o tráfego interno kube-system) diretamente no nível do coletor do Cloud Logging. Adicione um filtro de exclusão ao seu coletor _Default para descartar metadados internos ou registros de pods do sistema:

resource.type="gce_subnetwork" AND
log_name:"projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND
jsonPayload.src_gke_details.pod.pod_namespace="kube-system"

Práticas recomendadas e dicas operacionais

Considere as seguintes diretrizes operacionais ao implantar e manter o pipeline de telemetria do cluster:

  • Ativar a observabilidade de fluxo do GKE Dataplane V2 sob demanda:a observabilidade de fluxo (hubble-relay) pode gerar uma pequena sobrecarga. Para clusters de produção, é possível ativar o recurso durante sessões de depuração e desativá-lo depois para minimizar o consumo de recursos nos nós:

    gcloud container clusters update CLUSTER_NAME \
    --enable-dataplane-v2-flow-observability \
    --location=LOCATION

  • Ative a visibilidade intranós:por padrão, o tráfego entre dois objetos de pod no mesmo nó não sai dele, o que o torna invisível para os registros de fluxo da VPC. A visibilidade intranós é ativada por padrão em clusters do Autopilot e desativada por padrão em clusters Standard, incluindo aqueles que usam o GKE Dataplane V2. Ativar a visibilidade intranó faz com que esse tráfego passe pela VPC e ajuda a garantir que as regras de firewall e os registros de fluxo da VPC sejam aplicados de maneira consistente.

  • Entenda o comportamento de resolução do VIP do serviço:depois que um IP virtual (VIP) do serviço do Kubernetes é resolvido para um endereço IP do pod de back-end, as métricas da camada de transporte (camada 4 do OSI) o contam como tráfego de pod para pod. Para rastrear qual VIP de serviço foi originalmente segmentado, use os fluxos ativos da CLI do Hubble durante o handshake de conexão.

  • Alinhe os carimbos de data/hora de métricas e registros:ao investigar um incidente, correlacione o pico nas métricas do Cloud Monitoring com o período exato ao consultar registros no Cloud Logging ou na CLI do Hubble para garantir que você esteja analisando o mesmo evento.

A seguir