Caso de mejora en la estabilidad de red de Cilium: resultados sorprendentes logrados con una pequeña corrección de código

• Presentación de un caso de PR donde una corrección de código pequeña (agregar una sola sentencia if) contribuyó enormemente a la estabilidad del sistema
• Impacto e importancia del PR "bpf:nat: Restore ORG NAT entry if it's not found"

Principio básico de NAT (Network Address Translation)

• NAT es una tecnología que permite que varios dispositivos compartan una sola IP pública
• Hace posible la comunicación entre dispositivos internos (IP:Puerto privados) y el internet externo
• La tabla NAT almacena la información de mapeo entre la dirección original y la dirección traducida
• Proceso:
  1. Un dispositivo interno intenta conectarse a un servidor externo
  2. El dispositivo NAT convierte la IP/puerto de origen en una IP/puerto públicos (SNAT)
  3. La respuesta del servidor externo se vuelve a convertir para el dispositivo interno (DNAT)

Uso de NAT en Kubernetes

• Dos casos principales donde NAT se usa de forma importante en Kubernetes:
  1. Comunicación desde un Pod hacia fuera del clúster: convierte la IP interna del Pod en la IP pública del nodo
  2. Comunicación desde el exterior hacia un Pod mediante NodePort: enruta las solicitudes externas hacia un Pod específico

Cómo implementa Cilium NAT

• En Linux, por lo general NAT se procesa con conntrack e iptables
• Cilium usa tecnología eBPF para evitar la pila de red tradicional de Linux
• Cilium administra directamente la tabla NAT usando un mapa hash LRU (BPF_MAP_TYPE_LRU_HASH)

Causa del problema

• Problema de lookup: para procesar paquetes bidireccionales (salientes/entrantes), se almacena la misma información dos veces (RevSNAT)
• Límite del LRU: debido a recursos limitados, los elementos menos usados se eliminan
• **Pérdida de conexión # Caso de una gran mejora en la estabilidad de red de Cilium con una pequeña corrección de código

Introducción: el gran impacto de un pequeño cambio de código

• Un caso en el que agregar solo un bloque if contribuyó enormemente a la estabilidad del sistema
• PR en cuestión: "bpf:nat: Restore ORG NAT entry if it's not found"
• Explicado para que también lo entiendan personas no especialistas en redes

Principio básico de NAT (Network Address Translation)

• NAT es una tecnología que permite que varios dispositivos compartan una sola IP pública
• Funciona mapeando la combinación interna Private IP:Port a una Public IP:Port externa
• Flujo de funcionamiento:
  • Un dispositivo interno intenta acceder a un servidor externo
  • El dispositivo NAT convierte la comunicación interna en comunicación externa (SNAT)
  • Cuando regresa la respuesta, vuelve a convertirla a la comunicación interna original (DNAT)
  • La información de traducción se registra en la tabla NAT

Uso de NAT en Kubernetes

• Kubernetes tiene una estructura de red compleja y usa NAT en varios lugares
• Principales casos de uso de NAT:
  1. Comunicación desde un Pod hacia fuera del clúster: convierte la IP privada del Pod en la IP pública del nodo (SNAT)
  2. Comunicación desde el exterior hacia un Pod mediante NodePort: realiza DNAT y SNAT al mismo tiempo para dirigir el tráfico externo al Pod adecuado

El enfoque especial de Cilium

• En sistemas Linux comunes, NAT se administra con el subsistema conntrack e iptables
• Cilium usa tecnología eBPF para evitar la pila de red tradicional de Linux
• Para procesar SNAT, administra directamente la tabla SNAT en forma de mapa hash LRU (BPF_MAP_TYPE_LRU_HASH)

Causa y síntomas del problema

• Problema de consulta (Lookup):

  • Se necesita consultar la tabla hash para validar el procesamiento NAT
  • Para consultas rápidas, la misma información se inserta dos veces en la tabla como RevSNAT, invirtiendo los valores de src y dst

• Problema de LRU (Least Recently Used):

  • Debido a las limitaciones de recursos, los datos pueden ser eliminados por la lógica LRU

• Problema combinado:

  • La misma información se registra dos veces para una sola conexión TCP
  • Si хотя sea uno de los dos registros es eliminado por LRU, toda la conexión puede cortarse

Solución simple pero efectiva

• Idea clave: si se observa un paquete en una dirección, actualizar también la entrada de la dirección opuesta
• Con este enfoque simple:
  • Ambas entradas bidireccionales se actualizan y quedan más lejos de la prioridad de eliminación del LRU
  • Se reduce la posibilidad de que se elimine solo una de las entradas y se corte toda la comunicación
  • Las pruebas de benchmark mostraron una gran mejora en la estabilidad de red

Conclusión y lecciones

• Es un caso que muestra que incluso en sistemas complejos, una idea simple puede traer un gran cambio
• Se resolvió el problema a partir de conocimientos básicos de CS (cómo funciona NAT)
• Otra forma de evitar el problema: aumentar el tamaño de la tabla NAT
• Reconocimiento a la pasión del desarrollador que analizó a fondo el problema y contribuyó con datos de evidencia objetiva

Valor del enfoque técnico

• La importancia de entender y resolver la causa raíz del problema
• La lección de que una corrección de código simple puede mejorar enormemente la estabilidad de todo el sistema
• La importancia de comprender los principios básicos incluso en sistemas complejos

[ethanhur]

¡Gracias por compartir una experiencia tan genial!