Soluciona problemas de observabilidad de la red de GKE

Autopilot Standard

En este documento, se proporcionan instrucciones y procedimientos de diagnóstico para detectar problemas de redes en clústeres de Google Kubernetes Engine (GKE) con la observabilidad de GKE Dataplane V2, Hubble y Cloud Monitoring.

Para obtener una descripción general de la arquitectura y las prácticas recomendadas conceptuales, consulta Prácticas recomendadas para la observabilidad de redes.

Árbol de decisión para solucionar problemas y conceptos básicos

Antes de revisar los procedimientos, usa la siguiente matriz de decisión para identificar qué nivel de la pila de redes de GKE es probable que cause el problema y navega a la sección correspondiente.

Síntoma o pregunta de diagnóstico	Nivel sospechoso	Procedimiento recomendado
Los Pods no pueden resolver dominios externos ni objetos Service internos de Kubernetes (tiempos de espera de DNS, NXDOMAIN, SERVFAIL).	Nivel 1: Pod y Service (DNS)	Diagnostica fallas de resolución de DNS
Los servicios no se pueden comunicar; se agota el tiempo de espera de la conexión o se descartan paquetes entre Pods.	Nivel 1: Pod y Service (pérdidas de paquetes o de políticas)	Diagnostica pérdidas de paquetes y bloqueos de NetworkPolicy
Las réplicas de carga de trabajo tienen una carga de tráfico desigual o los Pods registran tasas altas de restablecimientos de TCP (RST).	Nivel 1: Pod y Service (balanceo de cargas o transporte)	Diagnostica el desequilibrio del tráfico y los restablecimientos de TCP
Latencia general, tiempos de espera intermitentes o reinicios de CNI en los nodos.	Nivel 2: Nodo y CNI (kernel)	Clasifica la latencia a nivel de nodo y los cuellos de botella de CNI
Los Pods no pueden acceder a recursos fuera de GKE (Cloud SQL, APIs externas o de otras VPC).	Nivel 3: VPC y enrutamiento	Aísla los problemas de conectividad de GKE frente a los de VPC o externos
Necesitas una simulación de ruta automatizada para verificar si las reglas de firewall, las rutas o las NetworkPolicies bloquean el tráfico.	Nivel 3: VPC y enrutamiento (simulación)	Diagnostica la conectividad con las pruebas de conectividad
Necesitas identificar qué cargas de trabajo envían tráfico a Internet y se someten a NAT.	Nivel 4: Puerta de enlace externa y costo	Identifica el tráfico de NAT (salida a Internet)
Costos altos de transferencia de datos entre zonas o necesidad de visualizar los principales interlocutores sin escribir consultas en SQL.	Nivel 4: Puerta de enlace externa y costo	Analiza los costos y el rendimiento del tráfico del clúster con Flow Analyzer

Conceptos básicos de redes

Si eres nuevo en Kubernetes o en las redes de Google Cloud , ten en cuenta estos conceptos básicos:

• eBPF (Extended Berkeley Packet Filter): Es una tecnología de sistema operativo que permite ejecutar programas de supervisión y enrutamiento seguros directamente dentro del kernel de Linux. GKE Dataplane V2 usa eBPF para enrutar paquetes y aplicar NetworkPolicies con una sobrecarga de rendimiento mínima.
• Enmascaramiento de IP (SNAT): Es el proceso de reescribir la dirección IP de origen de un paquete. Cuando un Pod de GKE (que tiene una dirección IP privada) se comunica con Internet o con recursos de VPC externos, GKE enmascara (reescribe) la dirección IP del Pod en la dirección IP del nodo para que los sistemas externos sepan cómo enrutar la respuesta.
• Seguimiento de conexiones (Conntrack): Es una función del kernel que hace un seguimiento de todas las conexiones de red activas. En los clústeres de GKE Dataplane V2, este seguimiento se divide entre dos tablas: la conntrack estándar del kernel de Linux (usada por el ip-masq-agent) y una tabla conntrack administrada por Cilium y GKE Dataplane V2 almacenada en un mapa de eBPF. Si un nodo controla demasiadas conexiones simultáneas, cualquiera de estas tablas de seguimiento puede llenarse (agotamiento de conntrack), lo que hace que el nodo descarte de forma silenciosa los paquetes nuevos.
• Hubble: Es el motor de observabilidad de GKE Dataplane V2. Se ejecuta sobre eBPF y proporciona visibilidad en tiempo real de los flujos de tráfico, las pérdidas de paquetes y la evaluación de NetworkPolicy.

Nivel 1: Observabilidad de Pods y servicios (aplicación)

El nivel de Pod y Service abarca la comunicación de red entre Pods, Services y el DNS del clúster. Los problemas en este nivel suelen manifestarse como tiempos de espera de conexión de la aplicación, fallas en la resolución de nombres o distribución de carga desigual.

Diagnostica fallas en la resolución de DNS

Revisa el alcance del diagnóstico y los requisitos previos antes de solucionar problemas de DNS:

• Área de enfoque: Comunicación entre Pods y CoreDNS o NodeLocal DNSCache, latencia de DNS, tiempos de espera de resolución de DNS ascendente y validación de NetworkPolicy de FQDN.
• Requisitos previos: Métricas de GKE Dataplane V2 habilitadas; acceso a kubectl.
• Compatibilidad con CNI: GKE Dataplane V2 (ruta de acceso de datos avanzada) y CNI de GKE estándar.
• Síntoma: Los Pods registran dial tcp: lookup <domain>: i/o timeout, NXDOMAIN o latencia intermitente en las llamadas a la API salientes.
• Objetivo: Determinar si la falla de DNS se origina dentro del clúster (saturación de kube-dns o NodeLocal DNSCache), una NetworkPolicy que bloquea el puerto UDP o TCP 53, o una degradación de la red ascendente.

Paso 1: Verificación básica de accesibilidad

Antes de solucionar problemas de las capas de DNS, verifica si se puede acceder al destino directamente con su dirección IP desde el Pod afectado:

# 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

• Si la conexión IP se realiza correctamente, pero el dominio falla, el problema se aísla en la capa de resolución de DNS. Continúa con el paso 2.
• Si ambos fallan, el problema es el enrutamiento a nivel de la red o la aplicación de políticas. Continúa con Diagnostica las pérdidas de paquetes y los bloqueos de NetworkPolicy.

Verifica la propagación previa de DNS de NetworkPolicy de FQDN

Si tu clúster usa NetworkPolicies basadas en FQDN (FQDNNetworkPolicy), verifica que el nombre de dominio esté permitido de forma explícita. Si un Pod consulta un dominio externo que no se prepropaga en la caché del proxy de DNS de GKE Dataplane V2 ni está permitido por la política, GKE Dataplane V2 bloquea el tráfico de salida a la dirección IP resuelta:

# 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"

Paso 2: Verifica las métricas de DNS en Cloud Monitoring

GKE expone las métricas de DNS integradas en Cloud Monitoring con el prefijo kubernetes.io/networking/dns/.

Importante: Si tu clúster usa Cloud DNS para GKE, las consultas de DNS no atraviesan los Pods de kube-dns ni de NodeLocal DNSCache. Estas métricas de kube-dns se mantienen estables. Consulta la documentación de Cloud DNS para solucionar problemas de consultas de DNS en ese modo.

Para verificar las métricas de DNS en Cloud Monitoring, haz lo siguiente:

1. En la consola de Google Cloud , navega a Cloud Monitoring > Paneles.
2. Selecciona el panel predefinido Observabilidad de DNS de GKE: Vista de clúster (o navega al Explorador de métricas y filtra por kubernetes.io/networking/dns/).
3. Evalúa los siguientes indicadores principales (para NodeLocal DNSCache, reemplaza kubedns por node_local_dns en la ruta de la métrica):

Nombre de la métrica	Umbral de advertencia	Causa principal
kubernetes.io/networking/dns/kubedns/max_concurrent_rejected_request_count	>0	Se alcanzó el límite de consultas simultáneas. kube-dns o NodeLocal DNSCache descarta las consultas.
kubernetes.io/networking/dns/kubedns/dns_request_latencies	p99 > 100 ms	Latencia alta de resolución de DNS de extremo a extremo en kube-dns o NodeLocal DNSCache.
kubernetes.io/networking/dns/kubedns/forwarding_request_latencies	p99 > 100 ms	Latencia o saturación del servidor DNS ascendente.

Secuencia de clasificación del rendimiento y el tiempo de espera de DNS

Sigue esta secuencia de clasificación para diagnosticar la latencia de DNS, los errores de caché y los tiempos de espera ascendentes:

1. Verifica la tasa de aciertos de caché: consulta kubernetes.io/networking/dns/kubedns/dns_cache_request_count (o node_local_dns/dns_cache_request_count) agrupada por la etiqueta cache_status. Si cache_status="hit" es bajo y cache_status="miss" es alto, es posible que las aplicaciones emitan consultas que no sean de FQDN (como my-service en lugar de my-service.default.svc.cluster.local), lo que provoca un recorrido de la ruta de búsqueda en todas las entradas de /etc/resolv.conf.
2. Evalúa la latencia ascendente: Un valor alto de forwarding_request_latencies indica problemas con el servidor DNS ascendente (por ejemplo, el DNS local corporativo al que se accede a través de Cloud Interconnect o Cloud VPN, o los límites de Cloud DNS).

3. Audita las anulaciones de DNS personalizadas: Inspecciona los ConfigMaps kube-dns personalizados para detectar stubs o reenvíos ascendentes mal configurados:

   kubectl get configmap kube-dns -n kube-system -o yaml
   

Paso 3: Transmite tráfico de DNS en vivo con la CLI de Hubble

Usa el alias de ayuda de la CLI de Hubble para inspeccionar las solicitudes y respuestas de DNS en vivo que se transmiten desde el kernel del nodo:

# 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

Nota: La CLI de Hubble analiza los encabezados de DNS en la capa de aplicación (capa 7 de OSI). En el resultado del flujo, busca los campos DNS Query y DNS Answer. Si la consulta muestra RCODE: NXDOMAIN o RCODE: SERVFAIL, el servidor DNS rechaza el registro o no puede resolverlo.

Paso 4: Valida la corrección

Si se produjeron rechazos de consultas simultáneas, aplica NodeLocal DNSCache para absorber las búsquedas de DNS de alta frecuencia directamente en el nodo sin alcanzar los límites de kube-dns en todo el clúster:

# Verify NodeLocal DNSCache DaemonSet is running
kubectl get daemonset node-local-dns -n kube-system

---

Diagnostica las pérdidas de paquetes y los bloqueos de NetworkPolicy

Revisa el alcance del diagnóstico y los requisitos previos antes de investigar las pérdidas de paquetes y los rechazos de políticas:

• Área de enfoque: Caídas de tráfico entre objetos de Pod o entre objetos de Pod y Service, aplicación de NetworkPolicy, motivos de caída de eBPF del kernel.
• Requisitos previos: Observabilidad de flujos de GKE Dataplane V2 habilitada; registro de NetworkPolicy configurado.
• Compatibilidad con CNI: Solo GKE Dataplane V2.
• Síntoma: Los intentos de conexión de la aplicación fallan con Connection timed out o Connection reset by peer.
• Objetivo: Identificar el motivo exacto de la NetworkPolicy o de eBPF por el que se descartan los paquetes sin realizar cambios de prueba y error en las políticas de seguridad.

Paso 1: Supervisa las métricas de pérdidas de Hubble

Cuando GKE Dataplane V2 descarta un paquete, emite la métrica hubble_drop_total etiquetada con el motivo del descarte y los metadatos de origen y destino. Para supervisar las métricas de descarte de Hubble, haz lo siguiente:

1. Si aún no lo hiciste, implementa un recurso PodMonitoring de Google Cloud Managed Service para Prometheus para recopilar métricas de 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. Ejecuta la siguiente consulta en Cloud Monitoring > Explorador de métricas para ver las pérdidas por motivo:

   sum by (reason) (rate(hubble_drop_total[5m])) > 0
   

3. Interpreta los códigos reason comunes:

   • Policy denied: Una NetworkPolicy de Kubernetes bloquea la conexión de forma explícita o implícita.
   • CT: Map insertion failed: Se agotó la tabla de seguimiento de conexiones (conntrack).
   • Unsupported L3 protocol: paquete que no es IPv4 o IPv6, o encabezado dañado.

Paso 2: Revisa los registros de NetworkPolicy en Cloud Logging

El registro de NetworkPolicy exporta registros JSON estructurados para todas las decisiones basadas en políticas. Para consultar los registros de NetworkPolicy en Cloud Logging, haz lo siguiente:

1. En la consola de Google Cloud , navega a Cloud Logging > Explorador de registros.

2. Ejecute la siguiente consulta:

   resource.type="k8s_node"
   log_name:"projects/PROJECT_ID/logs/events"
   jsonPayload.connection.verdict="DENY"
   jsonPayload.src.pod_name="my-source-pod"
   

3. Inspecciona la carga útil de JSON:

   • jsonPayload.drop_reason: Muestra por qué se descartó el paquete.
   • jsonPayload.policies: Enumera qué NetworkPolicies se evaluaron. Si se muestra una lista vacía con un veredicto DENY, el espacio de nombres opera en modo de denegación predeterminado y ninguna política permitió el tráfico.

Si no aparecen registros de NetworkPolicy, verifica que el registro esté habilitado en el recurso personalizado NetworkLogging del clúster. Por ejemplo, verifica que el campo spec.cluster.deny.log esté configurado como true:

kubectl get networklogging default -o yaml

Paso 3: Realiza un seguimiento de las pérdidas en vivo con la CLI de Hubble

Transmite las pérdidas en vivo directamente con la CLI de Hubble para inspeccionar los paquetes en tiempo real:

gke-hubble observe --verdict DROPPED --namespace default --follow

Resultado de ejemplo:

TIMESTAMP             SOURCE               DESTINATION          TYPE     VERDICT
10:14:22.102          default/frontend     default/backend:80   to-stack DROPPED (Policy denied by NetworkPolicy: backend-deny-all)

En el resultado, se indica la NetworkPolicy exacta que bloquea el tráfico (backend-deny-all).

Paso 4: Verifica si hay agotamiento de conntrack

Si el motivo de la baja indica CT: Map insertion failed, haz lo siguiente:

1. Inspecciona el registro del agente de GKE Dataplane V2 para ver si hay saturación en la tabla conntrack:

   kubectl logs -n kube-system daemonset/anetd -c cilium-agent --tail=100 | grep "Conntrack table full"
   

2. Verifica el tamaño máximo de la tabla de conntrack en el nodo afectado:

   kubectl exec -it -n kube-system daemonset/anetd -c cilium-agent -- cilium status --all-controllers | grep -i conntrack
   

   Si la tabla de conntrack está llena, escala horizontalmente tus cargas de trabajo en más nodos o reduce la tasa de conexión de los Pods de cliente.

---

Diagnostica el desequilibrio del tráfico y los restablecimientos de TCP

Revisa el alcance del diagnóstico y los requisitos previos antes de solucionar los problemas de desequilibrio de tráfico y restablecimiento de conexiones:

• Área de enfoque: Desigualdad en el balanceo de cargas, fallas en el protocolo de enlace de TCP y finalización repentina de la conexión.
• Requisitos previos: Métricas de GKE Dataplane V2 habilitadas.
• Compatibilidad con CNI: GKE Dataplane V2.
• Síntoma: Algunas réplicas de Pods reciben tráfico excesivo, mientras que otras permanecen inactivas; las aplicaciones cliente registran connection reset by peer o broken pipe.
• Objetivo: Determinar si el desequilibrio del tráfico se debe a la persistencia de la conexión en la capa de transporte (capa 4 de OSI, TCP) en comparación con la capa de aplicación (capa 7 de OSI, HTTP/2 o gRPC) y, además, identificar el origen de los paquetes TCP RST.

Paso 1: Compara el flujo de tráfico a nivel del Pod

Para determinar si el tráfico se distribuye de manera uniforme entre tus réplicas, haz lo siguiente:

1. En Cloud Monitoring, consulta el recuento de flujos de entrada en todos los Pods de un Deployment:

   sum by (pod) (rate(pod_flow_ingress_flows_count{destination_workload="my-service"}[5m]))
   

2. Evaluar la distribución del tráfico entre los Pods Si un solo Pod recibe la mayor parte del tráfico, investiga la reutilización de conexiones o las sesiones fijas:

   • gRPC o HTTP/2: Las conexiones TCP de larga duración hacen que todas las solicitudes atraviesen un solo flujo de TCP a un Pod de backend. El enrutamiento del servicio de Kubernetes de la capa de transporte (capa 4 de OSI, TCP) no puede balancear las solicitudes dentro de una conexión HTTP/2 establecida.
   • Afinidad de sesión de ClientIP: Verifica si el Service está configurado con sessionAffinity: ClientIP.
   • Services sin interfaz gráfica: Los clientes pueden resolver el DNS una vez y almacenar en caché la dirección IP única de forma permanente.

Paso 2: Analiza las métricas de restablecimiento de TCP

Los restablecimientos de TCP (RST) finalizan las conexiones de inmediato. El kernel del sistema operativo los emite cuando un extremo recibe un paquete para un puerto desconocido o cuando una aplicación cierra una conexión con datos no leídos en el búfer.

Ejecuta la siguiente consulta de MQL en 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())

Revisa los resultados de la consulta para determinar el origen del restablecimiento:

• RST saliente (traffic_direction=egress): El Pod local genera el restablecimiento. Verifica si la aplicación del Pod falla, alcanza su límite de conexiones o rechaza la conexión de forma activa.
• RST entrante (traffic_direction=ingress): El par remoto (base de datos externa, API o Pod remoto) envió el restablecimiento. Verifica el estado del servidor de destino y los estados del firewall.

Paso 3: Transmite los restablecimientos de TCP en vivo

Usa la CLI de Hubble para capturar el protocolo de enlace de restablecimiento en vivo:

gke-hubble observe --type trace --verdict FORWARDED --tcp-flags RST --namespace default

Paso 4: Corrección y soluciones prácticas

Aplica los siguientes pasos de solución según la causa del desequilibrio de tráfico o los restablecimientos de TCP:

• Para la persistencia de la conexión de la capa de aplicación (capa 7 de OSI) o gRPC, haz lo siguiente:
  • Implementa Cloud Service Mesh para habilitar el balanceo de cargas a nivel de solicitud en la capa de aplicación (capa 7 de OSI).
  • Configura límites de conexión del cliente o tiempos de espera de keep-alive (por ejemplo, MAX_CONNECTION_AGE y MAX_CONNECTION_AGE_GRACE de gRPC) para forzar el restablecimiento periódico de la conexión.
• Para la afinidad de IP del Service: Quita service.spec.sessionAffinity, a menos que el estado de la aplicación lo requiera de forma estricta.
• Para el almacenamiento en caché de DNS de Service sin interfaz gráfica: Asegúrate de que los entornos de ejecución de la aplicación (como JVM networkaddress.cache.ttl) no almacenen en caché los resultados de DNS de forma indefinida.
• Para el desbordamiento de la cola de tareas pendientes de la aplicación: Cuando una cola de escucha de la aplicación está llena, el kernel de Linux descarta los paquetes SYN entrantes o envía un RST de TCP. Escala horizontalmente las réplicas de Pods o aumenta la lista de tareas pendientes de escucha de la aplicación (somaxconn).

---

Nivel 2: Observabilidad de nodos y CNI (kernel)

El nivel de nodo y CNI abarca el kernel de Linux del host, los programas de eBPF y las interfaces de red de nodo. Los cuellos de botella en este nivel afectan todas las cargas de trabajo que se ejecutan en el nodo afectado.

Verificación de la integridad del sistema: Detecta parches no autorizados de anetd

Precaución: Modificar o reiniciar de forma manual el DaemonSet de redes de GKE Dataplane V2 (anetd) puede causar interrupciones de red en todo el clúster y, además, incumplir los objetivos de nivel de servicio administrado de GKE.

GKE Dataplane V2 se ejecuta como un DaemonSet administrado (anetd) en el espacio de nombres kube-system. En Cloud Logging, puedes consultar los registros de auditoría de Kubernetes para detectar si usuarios no autorizados o secuencias de comandos automatizadas aplicaron parches o reiniciaron 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"

Si se detecta un parche no autorizado, revierte el DaemonSet a la configuración predeterminada o activa la recreación del grupo de nodos para restablecer el estado administrado.

---

Clasifica la latencia a nivel de nodo y los cuellos de botella de CNI

Revisa el alcance del diagnóstico y los requisitos previos antes de diagnosticar la latencia a nivel de nodo y los cuellos de botella del kernel:

• Área de enfoque: Latencia del kernel del host, pérdidas de paquetes en la interfaz de la VM, saturación del agente de eBPF de GKE Dataplane V2, agotamiento de conntrack.
• Requisitos previos: Métricas de VM de Compute Engine habilitadas; acceso a kubectl.
• Compatibilidad con CNI: GKE Dataplane V2 y CNI de GKE estándar.
• Síntoma: El tráfico entre nodos experimenta aumentos repentinos de latencia o caídas aleatorias, mientras que el tráfico dentro del nodo se mantiene en buen estado.
• Objetivo: Diferenciar entre la limitación de la red de la VM host, las pérdidas del kernel de Linux y los cuellos de botella a nivel de la CNI.

Paso 1: Diferencia los problemas fuera de GKE de los problemas dentro de GKE

Ejecuta la prueba de referencia de la VM de Compute Engine: Implementa una VM de Compute Engine independiente en la misma subred de VPC que los nodos del clúster de GKE. Prueba la conectividad de la VM al destino final.

• Si la VM independiente experimenta las mismas pérdidas de paquetes o latencia, el problema se encuentra fuera de GKE (firewalls de VPC, Cloud NAT, Cloud Interconnect o el servidor externo). Continúa con Aísla los problemas de conectividad de GKE frente a los de VPC o externos.
• Si la VM independiente se comunica con normalidad, pero los Pods de GKE fallan, el problema está dentro de GKE (eBPF, conntrack o CNI a nivel del nodo). Continúa con el paso 2.

Limitaciones de la prueba de referencia de la VM: Es posible que esta prueba no detecte pérdidas intermitentes o de baja tasa que solo se manifiestan en volúmenes de tráfico agregados altos. Además, si el problema se aísla en el hardware subyacente de un solo host de VM, es posible que otras VMs no reproduzcan el comportamiento.

Paso 2: Diferencia los problemas de la aplicación de los problemas de los niveles de nodos y CNI

Soluciona problemas de colisiones de puertos SNAT de ip-masq-agent personalizados: Los clústeres que usan una configuración de ip-masq-agent personalizada con la marca --random-fully pueden experimentar una latencia de salida intermitente. En condiciones de volúmenes de tráfico altos, iptables --random-fully puede asignar un puerto efímero que colisione con un NodePort activo, lo que genera demoras en la conexión. Actualiza ip-masq-agent a la versión 2.11.1 o una posterior, o quita --random-fully para evitar colisiones de puertos.

Para determinar si la latencia se origina en la aplicación o en el nodo y el nivel de CNI, haz lo siguiente:

1. Verifica la saturación de recursos de la aplicación: Comprueba que el nodo no experimente una limitación de CPU ni presión de memoria, lo que retrasa el procesamiento de paquetes en el espacio del usuario:

   kubectl top nodes
   kubectl top pods -n default
   

2. Inspecciona el recuento de conntrack del kernel de Linux: Verifica el recuento de conntrack activo en el 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
   

   Si nf_conntrack_count se acerca a nf_conntrack_max, el kernel del host descarta los paquetes TCP SYN nuevos.

Paso 3: Verifica la pérdida de paquetes a nivel de la VM con la telemetría de Compute Engine

Google Cloud Compute Engine exporta métricas de interfaz de red a nivel de VM a Cloud Monitoring.

En Cloud Monitoring > Explorador de métricas, consulta lo siguiente:

sum by (drop_reason) (rate(compute_googleapis_com:instance_network_dropped_packets_count[5m]))

• FQ_CODEL_DROP: El paquete se descartó debido a la saturación de la cola de Fair Queuing o CoDel (se superó el límite de ancho de banda de salida de la VM).
• FIREWALL_RULE_DROP: El paquete se descartó por una regla de firewall de VPC.
• RATE_LIMIT_DROP: El paquete se descartó porque la VM superó su cuota máxima de paquetes por segundo (PPS) de la interfaz de red.

Paso 4: Investiga las pérdidas a nivel del kernel con eBPF

Si las métricas a nivel de la VM muestran cero pérdidas, pero los Pods de GKE siguen perdiendo paquetes, inspecciona el agente de GKE Dataplane V2 (anetd) para ver las pérdidas de mapas de eBPF:

kubectl logs -n kube-system daemonset/anetd -c cilium-agent --tail=200 | grep -i "drop"

Busca ct-map-insertion-failed o fib-lookup-failed.

---

Nivel 3: Observabilidad de VPC y enrutamiento (red de Cloud)

El nivel de enrutamiento de VPC y de la nube conecta los nodos de GKE con otros servicios de Google Cloud , redes locales y con Internet. Por lo general, las fallas aquí se deben a reglas de firewall de VPC, rutas personalizadas o parámetros de configuración de puerta de enlace.

Aislar los problemas de conectividad de GKE frente a los de VPC o externos

Revisa el alcance del diagnóstico y los requisitos previos antes de aislar los problemas de la red externa de las fallas en el clúster:

• Área de enfoque: aislamiento de límites entre el enrutamiento interno de Kubernetes y el Cloud Router de VPC.
• Requisitos previos: gcloud CLI y permisos para crear pruebas de conectividad.
• Compatibilidad con CNI: Todos los clústeres.
• Síntoma: Los Pods no se conectan a un recurso externo (por ejemplo, Cloud SQL, una API local o un extremo de terceros).
• Objetivo: Determinar con rapidez si la pérdida se produce dentro del nodo de GKE o dentro de la VPC de Google Cloud o la red externa.

Paso 1: Prueba de referencia de la VM de Compute Engine

Para implementar una VM de referencia y evaluar si el problema persiste fuera de GKE, haz lo siguiente:

1. Implementa una instancia de VM de Compute Engine temporal en la misma subred y zona de VPC que tu grupo de nodos de GKE:

   gcloud compute instances create gke-baseline-tester \
       --zone=us-central1-a \
       --subnet=gke-subnet \
       --machine-type=e2-micro
   

2. Conéctate a la instancia con SSH y prueba la conectividad al destino:

   curl -v --connect-timeout 5 https://api.example.com
   

3. Evalúa el resultado:

   • Si la VM de Compute Engine no se puede conectar, el problema está en la VPC o en la red externa (reglas de firewall, tablas de enrutamiento, agotamiento de IP de Cloud NAT o lista de IPs externas permitidas).
   • Si la VM de Compute Engine se conecta de forma correcta, el problema está dentro de GKE (NetworkPolicy bloquea la salida, CIDR de Pod sin enmascarar o DNS a nivel de contenedor).

Paso 2: Ejecuta una prueba de conectividad bajo demanda

Ejecuta una prueba de Google Cloud Pruebas de conectividad desde la VM del nodo hasta el 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

Verifica el resultado en la consola de Google Cloud para identificar si una regla de firewall o una ruta de VPC está descartando el tráfico.

---

Diagnostica la conectividad con las pruebas de conectividad

Las pruebas de conectividad simulan rutas de paquetes en los recursos de GKE y VPC sin enviar tráfico en vivo. En esta simulación, se evalúa la resolución de DNAT de Service ClusterIP a Pod, las reglas de entrada y salida de NetworkPolicy de GKE Dataplane V2 y el enmascaramiento de IP del nodo (SNAT). Revisa el alcance del diagnóstico y los requisitos previos antes de ejecutar simulaciones de rutas de acceso automatizadas:

• Área de enfoque: Simulación de ruta estática automatizada para Pods, Services, NetworkPolicies y rutas de VPC de GKE.
• Requisitos previos: Network Intelligence Center habilitado; API de Management de red habilitada.
• Compatibilidad con CNI: GKE Dataplane V2 (análisis mejorado).
• Síntoma: Se producen caídas de conectividad inexplicables en las que todos los parámetros de configuración parecen válidos tras una inspección manual.
• Objetivo: Simular y rastrear de forma estática toda la ruta de paquetes desde un Pod de origen hasta el destino, identificando la línea exacta de la política que causa una pérdida.

Situación A: Verifica si una NetworkPolicy de GKE bloquea la recopilación de métricas

Cuando se recopilan métricas de Pods en un espacio de nombres seguro, es posible que una NetworkPolicy de denegación predeterminada bloquee los recopiladores de Google Cloud Managed Service para Prometheus:

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

Inspecciona el seguimiento de prueba en la consola de Google Cloud . Si la prueba finaliza en el paso GKE Network Policy evaluation con DROP, se debe agregar una regla de entrada para permitir el tráfico de los Pods del recopilador.

Situación B: Verifica la accesibilidad a un Service de GKE

Simula la accesibilidad desde una VM de cliente a un servicio de Kubernetes interno:

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

El seguimiento simulado muestra lo siguiente:

1. Coincidencia de ruta de VPC.
2. Permiso de entrada y salida del firewall de VPC.
3. Llegada al nodo de GKE.
4. DNAT del Service a la dirección IP del Pod de backend.
5. Evaluación de la NetworkPolicy de entrada en el Pod de backend.

Situación C: Diagnostica problemas de salida de Pod a Internet

Cuando los Pods no pueden acceder a una API externa en Internet, haz lo siguiente:

1. Crea una prueba desde el Pod hasta la dirección IP pública externa (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. Examina el punto de entrega:

   • Se descartó en NetworkPolicy: El Pod no tiene una NetworkPolicy de salida que permita el tráfico a 0.0.0.0/0.
   • Se descartó en el firewall de VPC: Una regla de firewall de VPC deniega el tráfico saliente de la subred del nodo.
   • Se descartó en Cloud NAT o en la ruta: La subred no tiene una ruta predeterminada a la puerta de enlace de Internet o no se configuró Cloud NAT para la subred.

---

Nivel 4: Observabilidad de la puerta de enlace externa y el costo (Internet y NAT)

El nivel de puerta de enlace externa administra el tráfico saliente a destinos públicos de Internet a través de Cloud NAT o puertas de enlace externas. La observabilidad en este nivel ayuda a identificar las cargas de trabajo con alta salida y controlar los costos de transferencia de datos.

Identifica el tráfico de NAT (salida a Internet)

Revisa el alcance del diagnóstico y los requisitos previos antes de analizar el tráfico saliente de Internet y NAT:

• Área de enfoque: tráfico de Internet saliente, uso de puertos de Cloud NAT, costos de transferencia de datos externos.
• Requisitos previos: Se habilitó la observabilidad de flujos de GKE Dataplane V2.
• Compatibilidad con CNI: GKE Dataplane V2.
• Síntoma: Errores de agotamiento de puertos de Cloud NAT o costos de salida de Internet inesperadamente altos.
• Objetivo: Identificar qué objetos de Pod y Service de GKE específicos transmiten tráfico a extremos de Internet externos.

Paso 1: Comprende los conceptos de "to-stack" y "world" en GKE Dataplane V2

En GKE Dataplane V2, ocurre lo siguiente:

• world: Representa cualquier destino fuera del clúster de GKE y fuera de la VPC (la Internet pública).
• to-stack: Representa los paquetes que pasan de la interfaz veth del contenedor de eBPF a la pila de red de Linux del host para someterse al enmascaramiento de IP (SNAT) antes de llegar a Cloud NAT.

Paso 2: Transmite y filtra el tráfico de NAT con la CLI de Hubble

Transmite flujos de Internet salientes en vivo que se originan en tu clúster:

# Stream egress flows heading to external internet ("world")
gke-hubble observe \
    --traffic-direction egress \
    --verdict FORWARDED \
    --to-identity world \
    --follow

Resultado de ejemplo:

TIMESTAMP             SOURCE               DESTINATION          TYPE     VERDICT
10:25:01.120          default/worker-pod   142.250.190.46:443   to-stack FORWARDED

Para identificar los principales emisores salientes, también puedes canalizar el resultado de JSON de Hubble a jq para contar los flujos de salida 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

Paso 3: Supervisa el tráfico externo con métricas

En Cloud Monitoring, haz un seguimiento del volumen de flujos 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())

---

Analiza los costos y el rendimiento del tráfico del clúster con Flow Analyzer

Revisa el alcance del diagnóstico y los requisitos previos antes de visualizar los flujos de tráfico y los costos entre zonas:

• Área de enfoque: Costos de transferencia de datos entre zonas, principales emisores, visibilidad del tráfico entre nodos sin consultas en SQL.
• Requisitos previos: Registros de flujo de VPC habilitados con INCLUDE_ALL_METADATA, visibilidad dentro de los nodos habilitada y Estadísticas de observabilidad habilitadas en el bucket de registros.
• Compatibilidad con CNI: Todos los clústeres.
• Síntoma: Cargos elevados por transferencia de datos entre zonas en las facturas mensuales deGoogle Cloud .
• Objetivo: Identificar visualmente qué cargas de trabajo de GKE generan tráfico entre zonas y optimizar la ubicación sin consultar registros sin procesar.

Requisitos previos

Para usar Flow Analyzer para GKE, sigue estos pasos:

1. Registros de flujo de VPC: deben estar habilitados en la subred del clúster con metadata="INCLUDE_ALL_METADATA".
2. Visibilidad dentro de los nodos: Debe estar habilitada en el clúster para que el tráfico de Pod a Pod esté expuesto a la canalización de registros de flujo de VPC.
3. Análisis de registros: El bucket _Default en Cloud Logging debe actualizarse para usar Estadísticas de observabilidad.

Nota: Los registros de flujo se escriben en el proyecto propietario de la red. En una configuración de VPC compartida, este proyecto es el proyecto host, no el proyecto de servicio que se ejecuta en tu clúster de GKE. Ejecuta Flow Analyzer en el proyecto host y usa el ID del proyecto host para PROJECT_ID en la consulta de Estadísticas de observabilidad.

Paso 1: Identifica los flujos que generan la mayor cantidad de tráfico de GKE en Flow Analyzer

Para ver las cargas de trabajo de gran volumen en Flow Analyzer, haz lo siguiente:

1. En la consola de Google Cloud , ve a la página Flow Analyzer.
2. Haz clic en Bucket de origen y selecciona el bucket de registros que contiene tus registros de flujo. A menos que los hayas enrutado a otro lugar, este es el bucket _Default.
3. En Agregación de tráfico, selecciona Origen - Destino.
4. Establece el período de la ventana de análisis.
5. En Organizar flujos por, selecciona los campos de Pod o carga de trabajo de GKE.
6. Haz clic en Ejecutar consulta nueva. En el gráfico Mayores flujos de datos, se muestra qué cargas de trabajo mueven la mayor cantidad de datos.

Paso 2: Analiza los costos del tráfico entre zonas

El tráfico entre zonas genera cargos por transferencia de datos. Para ubicar las cargas de trabajo que se transmiten entre zonas, haz lo siguiente:

1. En Organizar flujos por, selecciona los campos de zona de origen y zona de destino.
2. Haz clic en Ejecutar consulta nueva y lee la tabla Todos los flujos de datos. Las filas en las que las zonas de origen y destino difieren son tu tráfico entre zonas. Los filtros de Flow Analyzer coinciden con los valores, por lo que no puedes filtrar por "no es igual"; en su lugar, compara los pares de zonas en los resultados.
3. Expande un par de zonas de alto volumen para ver las cargas de trabajo de GKE de origen y destino subyacentes.

Corrección:

• Implementa topologySpreadConstraints o podAffinity de Kubernetes para colocar los servicios de comunicación en la misma zona de disponibilidad.
• Habilita el enrutamiento compatible con la topología (service.kubernetes.io/topology-mode: Auto) en el Service para mantener el tráfico dentro de la zona de origen.

Paso 3: Desglosa las Estadísticas de observabilidad (para consultas en SQL avanzadas)

En Flow Analyzer, haz clic en Ver en Análisis de registros para ejecutar consultas en SQL en los datos de flujo.

La siguiente consulta en SQL calcula los Pods que más se comunican 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;

---

Referencia de la CLI de Hubble y hoja de referencia de consultas

La CLI de Hubble transmite y filtra datos de flujo de red en vivo directamente desde el búfer de anillo del kernel de GKE Dataplane V2.

Configuración: Crea un alias auxiliar

Debido a que Hubble se ejecuta dentro del plano de control del clúster, configura un alias de shell para ejecutar comandos de Hubble sin implementar objetos binarios locales:

alias gke-hubble="kubectl exec -it -n gke-managed-dpv2-observability deployment/hubble-relay -c hubble-cli -- hubble"

Recetas de filtrado comunes

Objetivo de solución de problemas	Comando de la CLI de Hubble
Observa todos los paquetes descartados en tiempo real en todo el clúster	gke-hubble observe --verdict DROPPED --follow
Transmite todo el tráfico de un Pod específico en cualquier espacio de nombres	gke-hubble observe --pod default/my-pod --follow
Filtra el tráfico entre dos espacios de nombres específicos	gke-hubble observe --from-namespace frontend --to-namespace backend
Aislar el tráfico en un puerto específico (como el puerto 80)	gke-hubble observe --port 80
Inspecciona las consultas y respuestas de DNS en vivo	gke-hubble observe --port 53
Visualiza los restablecimientos de TCP en vivo (paquetes RST)	gke-hubble observe --type trace --verdict FORWARDED --tcp-flags RST
Transmite todo el tráfico saliente que se dirige a la Internet pública	gke-hubble observe --traffic-direction egress --to-identity world
Inspecciona el tráfico de la capa de aplicación HTTP (capa 7 de OSI)	gke-hubble observe --protocol http

Filtrado avanzado con negación (--not)

Puedes excluir el tráfico conocido de alto volumen o en buen estado para enfocarte en las anomalías:

# Observe drops, but exclude internal kube-system health probes and DNS
gke-hubble observe \
    --verdict DROPPED \
    --not --namespace kube-system \
    --not --port 53

Formato de resultado y la integración de jq

Para procesar los registros de flujo de manera programática, genera el resultado en 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'

Limitaciones

Cuando uses la CLI de Hubble para solucionar problemas en vivo, ten en cuenta las siguientes limitaciones técnicas:

• Búfer de anillo local de nodo efímero: Los flujos de Hubble se almacenan en un búfer de anillo en memoria en cada nodo individual. Durante los eventos de tráfico alto, los registros de flujo más antiguos se reemplazan en cuestión de segundos. Para el análisis histórico, confía en el registro de NetworkPolicy y los registros de flujo de VPC en Cloud Logging.
• No hay un operador lógico OR integrado: Las marcas de la CLI de Hubble evalúan varios argumentos con el operador lógico AND. Para buscar varias condiciones (como el puerto 80 O el puerto 443), ejecuta comandos independientes o filtra el resultado JSON con jq.

¿Qué sigue?

• Prácticas recomendadas para la observabilidad de la red
• Soluciona problemas de redes de GKE
• Soluciona problemas de conectividad en tu clúster
• Acerca de la observabilidad de GKE Dataplane V2
• Soluciona problemas de datos en Flow Analyzer