Prácticas recomendadas para la observabilidad de la red de GKE

Administrar la conectividad de red y las políticas de seguridad en entornos dinámicos de Kubernetes presenta desafíos operativos significativos. La observabilidad de GKE Dataplane V2 proporciona a los administradores de la plataforma visibilidad a nivel del kernel del tráfico de red del clúster, lo que puede ayudar a habilitar la solución rápida de problemas, la auditoría continua del cumplimiento y la validación proactiva de rutas.

En este documento, se describen la arquitectura conceptual y las prácticas recomendadas para la observabilidad de la red de Google Kubernetes Engine (GKE), incluida la pila de telemetría, un modelo mental para la clasificación, reglas de alertas proactivas, automatización de Terraform y técnicas de optimización de costos.

Si quieres obtener instrucciones paso a paso para solucionar problemas y conocer los procedimientos de diagnóstico, consulta Soluciona problemas de observabilidad de la red.

Beneficios de la observabilidad de la red de GKE

Implementar una estrategia de observabilidad en GKE proporciona las siguientes ventajas clave:

  • Tiempo medio de resolución (MTTR) acelerado: Con las métricas potenciadas por eBPF y los registros de flujo de Hubble, puedes aislar de inmediato las anomalías de la red. Esta visibilidad te permite distinguir entre las fallas a nivel de la aplicación, los bloqueos de NetworkPolicy de Kubernetes y las descartes del firewall de VPC, lo que reduce los ciclos de depuración de horas a minutos.
  • Instrumentación a nivel del kernel sin sidecars: GKE Dataplane V2 ejecuta la lógica de observabilidad directamente dentro del kernel de Linux del host con eBPF. Esto elimina la necesidad de proxies sidecar que consumen muchos recursos o de modificaciones de código a nivel de la aplicación, lo que garantiza una sobrecarga mínima y preserva el rendimiento de la aplicación.
  • Auditoría continua del cumplimiento de la seguridad: El registro de NetworkPolicy genera registros de auditoría detallados para cada intento de conexión (veredictos de ALLOW o DENY). Estos registros proporcionan un registro a prueba de manipulaciones del tráfico del clúster, lo que es esencial para satisfacer los marcos de cumplimiento de reglamentaciones (como PCI-DSS, SOC 2 y HIPAA).
  • Validación proactiva de rutas: La integración con las pruebas de conectividad te permite simular rutas de red y evaluar NetworkPolicies de GKE de forma estática antes de que se implementen las cargas de trabajo, lo que evita el desvío de configuración y los problemas de conectividad en la fase de implementación.
  • Optimización de recursos y costos: El seguimiento detallado del flujo expone las ineficiencias, como el uso excesivo de puertos de Cloud NAT, los picos de transferencia de datos entre zonas y los patrones de resolución de DNS sin almacenamiento en caché, lo que permite una planificación de la capacidad y una administración de costos fundamentadas.

Arquitectura de observabilidad de la red de GKE

GKE Dataplane V2 ofrece una pila de observabilidad de varias capas diseñada para diferentes fases operativas. En la siguiente tabla, se describen los componentes principales y sus casos de uso recomendados:

Componente de observabilidad Caso de uso principal Disponibilidad Retención de datos Sobrecarga de rendimiento Indicadores clave de telemetría
Métricas de GKE Dataplane V2 Supervisión del estado, análisis de tendencias y alertas en todo el sistema Solo GKE Dataplane V2 Retención de telemetría histórica (Cloud Monitoring y Google Cloud Managed Service para Prometheus almacenan 30 o más días de métricas y registros) Insignificante (agregación a nivel del kernel) Contadores de paquetes y bytes, recuentos de restablecimiento de TCP y tasas de abandono de la conexión (pod_flow_drop_count).
Registros de NetworkPolicy Auditoría de políticas de seguridad, análisis histórico de conexiones y cumplimiento Solo GKE Dataplane V2 (para la configuración de recursos personalizados de NetworkLogging) Configurable (Cloud Logging) Baja (exportación de registros almacenados en búfer) Metadatos de conexión (etiquetas de origen y destino, direcciones IP, puertos) y veredictos de políticas (ALLOW o DENY)
CLI y IU de Hubble Análisis de tráfico interactivo en vivo y depuración a nivel de paquetes en tiempo real Solo GKE Dataplane V2 Efímero (búfer de anillo local del nodo) Baja (se habilita de forma dinámica) Registros de flujo en tiempo real y motivos detallados de las interrupciones (como rechazo por política o saturación de la tabla de seguimiento de conexiones)
Métricas de DNS de GKE Supervisar el rendimiento de la resolución de DNS, la eficiencia de la caché y la latencia ascendente Todos los clústeres Largo plazo (Cloud Monitoring) Insignificante Recuento de solicitudes de DNS, proporción de aciertos y errores de caché, latencia de reenvío upstream y rechazos por límite simultáneo.
Pruebas de conectividad Validación de rutas previa a la implementación y auditoría de configuración estática. Todos los clústeres No aplicable (simulación a pedido) Ninguno (simulado de forma estática) Es la ruta de enrutamiento de paquetes simulada, incluida la evaluación simulada de NetworkPolicy.
Registros de flujo de VPC Auditoría del tráfico externo y entre nodos, análisis forense de seguridad y análisis de costos Todos los clústeres Configurable (Cloud Logging o BigQuery) Ninguno (tasa de muestreo configurable) Detalles de la conexión de 5 tuplas, bytes y paquetes enviados, metadatos de GKE (espacio de nombres, carga de trabajo, servicio) y RTT (para TCP).
Flow Analyzer Análisis visual del tráfico de la VPC, identificación de los principales emisores y análisis de los costos entre zonas sin escribir consultas en SQL Todos los clústeres Depende de la retención del bucket de Estadísticas de observabilidad Ninguno (IU de Analytics) Volumen de tráfico y latencia agregados, agrupados por carga de trabajo o servicio de GKE.

En la tabla anterior, una sobrecarga de rendimiento de Insignificante significa que los componentes permanecen estrictamente dentro de una huella de recursos mínima (por lo general, < 0.1 CPU virtual y memoria mínima) independientemente del volumen de tráfico o la escala del sistema. Los componentes bajos mantienen una huella mínima en condiciones estándar, pero se ajustan dinámicamente según la densidad del tráfico. En situaciones de alta capacidad de procesamiento, el uso de recursos puede escalar verticalmente hasta 2 CPUs virtuales y varios cientos de megabytes de memoria.

Modelo mental de observabilidad de GKE y bucle de clasificación

Para solucionar problemas de anomalías en la red de manera eficaz, debes seleccionar el indicador de telemetría adecuado para tu alcance operativo y seguir una metodología de clasificación coherente.

Elige la fuente de telemetría adecuada

Con varias fuentes de telemetría disponibles, elige la herramienta que se adapte a tu tarea operativa actual:

Fuente de telemetría Respuestas Es ideal para Google Cloud destino
Métricas de GKE Dataplane V2 ¿Qué sucede y a qué escala? Paneles, alertas y planificación de la capacidad Cloud Monitoring (prometheus.googleapis.com)
Registros de NetworkPolicy ¿Por qué se bloqueó una conexión dentro de GKE? Auditorías de seguridad y análisis de la causa raíz de la política de seguridad Cloud Logging (registro de policy-action)
Registros de flujo de VPC ¿Qué sucedió con este tráfico después de salir del Pod? Análisis histórico del tráfico entre cargas de trabajo, costos de transferencia de datos entre zonas y atribución de bajas a nivel de la VPC Cloud Logging y Observability Analytics (registro de vpc_flows)
CLI y IU de Hubble ¿Qué está pasando por el nodo en este momento? Depuración en vivo, alternativa a tcpdump y problemas activos. Búfer de anillo efímero (CLI de Hubble)
Pruebas de conectividad ¿El tráfico puede viajar correctamente? Análisis de la ruta y sondeo activo del plano de datos: Verifica la accesibilidad e identifica los puntos de descarte exactos en los firewalls de VPC, las rutas y los nodos de GKE. Network Intelligence Center (simulación)

Bucle de solución de problemas estandarizado

Usa este flujo de trabajo repetible para priorizar cualquier incidente de redes de GKE:

  1. Detecta la anomalía: Identifica el problema a través de las alertas de Cloud Monitoring (por ejemplo, aumentos repentinos en los restablecimientos de TCP, rechazos por límite simultáneo de DNS o pérdidas de paquetes).
  2. Aísla el nivel: Ejecuta la prueba de referencia de la VM de GCE (consulta Triaje para la latencia a nivel del nodo y los cuellos de botella de la CNI) para determinar si el bloqueo se encuentra dentro del clúster de GKE (CNI, NetworkPolicy, enmascaramiento de IP) o fuera de la VPC (reglas de firewall, enrutamiento, Cloud NAT).
  3. Investiga la causa raíz: Realiza un análisis detallado del flujo:
    • Para incidentes en vivo, usa la CLI de Hubble (hubble observe) para transmitir flujos en tiempo real y, así, identificar los motivos de las interrupciones.
    • Para problemas históricos o intermitentes, consulta los registros de NetworkPolicy o los registros de flujo de VPC en Cloud Logging.
  4. Valida la corrección: Ejecuta una prueba de conectividad simulada para verificar que la ruta se permita de forma estática y, luego, consulta el panel de métricas para confirmar que la tasa de descarte volvió a cero.

Supervisión y alertas de redes proactivas

Para mantener la alta disponibilidad, los administradores de la plataforma deben establecer políticas de alertas en Cloud Monitoring para identificar la degradación de la red antes de que afecte las cargas de trabajo.

Alerta sobre aumentos repentinos de descartes de paquetes

Por lo general, un aumento anómalo en los flujos de red descartados indica una política de seguridad mal configurada o el agotamiento del seguimiento de conexiones (conntrack) a nivel del nodo.

  • Consulta de Prometheus (PromQL):

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

  • Acción recomendada: Consulta Diagnostica descartes de paquetes y bloqueos de NetworkPolicy para aislar el motivo específico del descarte de NetworkPolicy o eBPF de GKE que causa la pérdida de paquetes.

Alerta sobre la saturación de DNS

Cuando CoreDNS o NodeLocal DNSCache alcanzan su límite de consultas simultáneas, se rechazan las búsquedas de DNS posteriores, lo que genera tiempos de espera intermitentes de las aplicaciones.

  • Consulta de Prometheus (PromQL):

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

  • Acción recomendada: Ajusta la cantidad de réplicas de kube-dns o implementa NodeLocal DNSCache para distribuir la carga de resolución. Para obtener pasos detallados, consulta Cómo diagnosticar errores de resolución de DNS.

Alerta sobre aumentos repentinos de restablecimientos de TCP

Un aumento repentino en los paquetes de restablecimiento de TCP suele indicar que un servicio de backend rechaza conexiones, posiblemente debido a bucles de fallas de la aplicación o a la saturación de la cola de sockets.

  • Lenguaje de consulta de 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

  • Acción recomendada: Consulta Diagnóstico del desequilibrio del tráfico y los restablecimientos de TCP para investigar la persistencia de la conexión o la saturación de la cola de la aplicación.

Validación de rutas automatizada en CI/CD

Integra las pruebas de conectividad en las canalizaciones de implementación para validar las rutas de red de forma estática antes de enrutar el tráfico de producción. Usa gcloud CLI para verificar que las cargas de trabajo implementadas recientemente puedan acceder a las dependencias externas (como bases de datos y APIs) sin bloqueos de políticas.

  • Comando de ejemplo:

    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

Habilita el análisis de observabilidad para el análisis visual del flujo

Para habilitar el análisis visual sin SQL de los flujos de tráfico de VPC, actualiza el bucket de registros de GKE (por lo general, el bucket _Default) para usar Análisis de observabilidad. Esto permite que los administradores de la plataforma aprovechen el Analizador de flujo para investigar la distribución del tráfico y los costos de transferencia de datos. Para obtener más información, consulta Analiza el rendimiento y los costos del tráfico del clúster con Flow Analyzer.

Automatización de Terraform: Observability-as-Code

Para implementar esta arquitectura de observabilidad de forma coherente y evitar errores de configuración manual, implementa la canalización de telemetría con la siguiente configuración de Terraform (requiere el proveedor de 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"
}

Optimización de costos y reducción de ruido

La telemetría de red (métricas y registros) puede generar volúmenes de datos considerables, lo que genera costos altos de transferencia y almacenamiento. Usa las siguientes estrategias para optimizar la recopilación de telemetría sin perder visibilidad del tráfico crítico:

Inhabilita los registros de conexiones permitidas

De forma predeterminada, el registro de NetworkPolicy captura las conexiones permitidas y rechazadas. Las conexiones permitidas dominan el volumen de registros (a menudo, el 99% o más del tráfico). Puedes actualizar la configuración de NetworkLogging del clúster para capturar solo las conexiones rechazadas (desconexiones), lo que reduce drásticamente los costos de registro:

  1. Guarda el siguiente manifiesto 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. Aplica la configuración:

    kubectl apply -f network-logging-config.yaml

Delegar el registro a través de anotaciones

Para un control de costos detallado, delega el registro a las anotaciones configurando delegate: true en el recurso personalizado NetworkLogging. Esta configuración garantiza lo siguiente:

  • El tráfico permitido solo se registra si el objeto NetworkPolicy coincidente tiene la anotación policy.network.gke.io/enable-logging: "true".
  • El tráfico rechazado solo se registra para los objetos del Pod en los espacios de nombres anotados con policy.network.gke.io/enable-deny-logging: "true".

Esta configuración te permite habilitar el registro solo para las cargas de trabajo altamente críticas (como las pasarelas de pago) y, al mismo tiempo, ignorar los servicios ruidosos y de bajo riesgo.

Ajusta la tasa de muestreo de los registros de flujo de VPC

En tu configuración de Terraform (o en la consola de Google Cloud ), reduce la tasa de muestreo secundaria solo en las subredes en las que necesites agregados de volumen y costo del tráfico en lugar de registros de flujo individuales. Debido a que los registros de flujo de VPC estiman el tráfico total a partir de los paquetes muestreados, los recuentos de bytes y paquetes siguen siendo útiles para el análisis de costos a tasas más bajas. No establezcas la tarifa flow_sampling por debajo de 0.1, la tarifa mínima que satisface el nivel ESSENTIAL de la política de la organización 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"
  }
}

En la siguiente tabla, se resumen las tasas de muestreo secundarias y los niveles correspondientes de la política de la organización constraints/compute.requireVpcFlowLogs:

Tasa de muestreo secundario Nivel de política de la organización Cuándo se utiliza
1.0 COMPREHENSIVE Clústeres con un requisito permanente para el análisis forense por flujo o la auditoría de seguridad. Elige esta tasa cuando configures la subred, ya que aumentar la tasa después de un incidente no recupera los flujos que nunca se capturaron.
0.5 (predeterminada) LIGHT Subredes que respaldan los clústeres para los que solucionas problemas. Esta es la tarifa predeterminada y la referencia recomendada.
0.1 ESSENTIAL Subredes en las que necesitas agregados de volumen y costo del tráfico en lugar de flujos individuales.

Aplica exclusiones de Cloud Logging

Excluye los registros irrelevantes o con mucho ruido (como el tráfico interno de kube-system) directamente en el nivel del receptor de Cloud Logging. Agrega un filtro de exclusión a tu receptor _Default para descartar los metadatos internos o los registros de Pods del 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ácticas recomendadas y sugerencias operativas

Ten en cuenta los siguientes lineamientos operativos cuando implementes y mantengas tu canalización de telemetría del clúster:

  • Habilita la observabilidad del flujo de GKE Dataplane V2 a pedido: La observabilidad del flujo (hubble-relay) puede generar una ligera sobrecarga. En el caso de los clústeres de producción, puedes habilitarlo durante las sesiones de depuración y, luego, inhabilitarlo para minimizar el consumo de recursos en los nodos:

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

  • Habilita la visibilidad dentro del nodo: De forma predeterminada, el tráfico entre dos objetos Pod en el mismo nodo no sale del nodo, lo que lo hace invisible para los registros de flujo de VPC. La visibilidad dentro del nodo está habilitada de forma predeterminada en los clústeres de Autopilot y, de forma predeterminada, inhabilitada en los clústeres estándar, incluidos los clústeres estándar que usan GKE Dataplane V2. Habilitar la visibilidad intranodo redirige este tráfico a través de la VPC y ayuda a garantizar que las reglas de firewall y los registros de flujo de la VPC se apliquen de manera coherente.

  • Comprende el comportamiento de resolución de la VIP del Service: Después de que una dirección IP virtual (VIP) del Service de Kubernetes se resuelve en una dirección IP del Pod de backend, las métricas de la capa de transporte (capa 4 del modelo OSI) la registran como tráfico de pod a pod. Para rastrear qué VIP de servicio se segmentó originalmente, confía en los flujos en vivo de la CLI de Hubble durante el protocolo de enlace de conexión.

  • Alinea las marcas de tiempo de las métricas y los registros: Cuando investigues un incidente, correlaciona el aumento repentino en las métricas de Cloud Monitoring con el período exacto en el que consultaste los registros en Cloud Logging o en la CLI de Hubble para asegurarte de que estás analizando el mismo evento.

¿Qué sigue?