- Análisis exhaustivo de los fallos de conectividad en entornos de nube como EKS, GKE y OKE.
- Metodologías avanzadas de diagnóstico mediante la captura de paquetes con tcpdump y herramientas de núcleo.
- Configuración optimizada de políticas de red y gestión de interfaces CNI para evitar el agotamiento de IPs.
Cuando montamos un clúster de Kubernetes, la red es precisamente ese ingrediente que puede hacernos la vida muy fácil o convertirse en un auténtico dolor de cabeza. Si te has topado con que los pods no se hablan entre sí o que el tráfico desaparece en el limbo, es probable que el culpable sea la interfaz CNI (Container Network Interface) o alguna configuración mal puesta en el núcleo del sistema.
Lidiar con CNI personalizados requiere paciencia y un buen set de herramientas, ya que no basta con mirar los logs de la aplicación. Para solucionar estos líos, hay que meterse en las entrañas del nodo, analizar cómo se asignan las direcciones IP y verificar que las políticas de tráfico no estén bloqueando comunicaciones legítimas por error.
Diagnóstico en Entornos Amazon EKS y VPC CNI
En el ecosistema de Amazon EKS, el complemento VPC CNI es la pieza clave. Para que todo ruede fino, es fundamental que el rol de IAM tenga adjunto el AmazonEKS_CNI_Policy, ya que sin estos permisos el nodo no podrá gestionar las interfaces de red. Si notas que el pod aws-node no está en estado Running, lo más probable es que haya un fallo en el aprovisionamiento de la red o que el servidor de API no sea accesible desde el nodo de trabajo, siendo vital comprender la estructura y los servicios clave de AWS para mitigar estos errores.
Un punto crítico es el modo de aplicación de las políticas. Por defecto, EKS usa el modo estándar, donde se permite todo el tráfico hasta que la política se activa. Sin embargo, si necesitas un entorno más blindado, puedes cambiar la variable NETWORK_POLICY_ENFORCING_MODE a strict. Esto hace que el pod arranque con una política de denegación total, obligándote a definir reglas explícitas para cada punto de conexión, incluyendo el CoreDNS.
Para quienes buscan un rendimiento bruto, EKS implementa las NetworkPolicies mediante Extended Berkeley Packet Filter (eBPF). Esta tecnología es una pasada porque reduce la latencia y el consumo de CPU al evitar las búsquedas secuenciales típicas de iptables. Además, el uso de sondas eBPF permite registrar resultados de políticas en cada nodo, facilitando enormemente la detección de paquetes descartados.
Solución de Problemas en Azure Kubernetes Service (AKS)
En AKS, es común encontrarse con el error de «Failed to allocate address» durante la creación de un pod. Esto ocurre a menudo cuando el complemento de red no libera las IPs de pods ya eliminados o cuando la creación de nuevos pods es tan frenética que el recolector de elementos no utilizables no da abasto. Una solución rápida es ajustar la recolección de kubelet para que sea más agresiva con los recursos obsoletos.
Otro problema recurrente es que el servicio no sea accesible. Lo primero es comprobar si los endpoints se han creado correctamente ejecutando kubectl get endpoints. Si la lista está vacía, el selector de etiquetas del servicio está mal configurado. Si los endpoints existen pero no hay respuesta, conviene verificar que el puerto del contenedor coincida con el del servicio y que no haya una política de red bloqueando el flujo.
Si el nodo no puede contactar con el servidor de API, el culpable suele ser el RBAC o un problema de red interna. Si recibes un error 403 Forbidden, lo más seguro es que el ServiceAccount del contenedor no tenga los permisos necesarios. Aquí toca crear los RoleBinding y ClusterRoleBinding adecuados para que la aplicación pueda consultar la API de Kubernetes sin problemas.
Estrategias de Captura de Paquetes en GKE
Google Kubernetes Engine ofrece herramientas potentes como la utilidad toolbox para diagnosticar la red desde dentro del nodo. Si tienes cortes intermitentes o tiempos de espera, lo ideal es identificar la interfaz veth asociada al pod problemático y lanzar un tcpdump. Esto permite ver exactamente dónde se pierde el paquete, ya sea en la interfaz cbr0 o en el salto hacia la VPC, optimizando la infraestructura con soluciones como Google Axion en la nube de Google.
Un detalle que suele pasarse por alto es la configuración de la MTU (Maximum Transmission Unit). Si ves que el apretón de manos TCP funciona pero los datos grandes (como el SSL handshake) fallan, es probable que la MTU del pod sea superior a la de la red VPC. En GKE, el valor suele ser de 1460, pero si usas superposiciones como Flannel o Weave, debes reducirlo para dejar espacio a la encapsulación.
Cuando el sistema reporta que una dirección ya está en uso (bind: Address already in use), puede que tengas un proceso zombi. A veces, Docker no cierra bien la red y el proceso sigue escuchando en el puerto. Para limpiar esto, hay que localizar el UUID del pod y usar nsenter para entrar en el espacio de nombres de red y matar el proceso colgado con un kill manual.
Redes Nativas de VCN en Oracle Cloud (OKE)
En OKE, el plugin CNI nativo de VCN permite que los pods tengan IPs directamente enrutables desde la red virtual de Oracle. Esto es una ventaja enorme porque puedes usar los Grupos de Seguridad de Red (NSG) para controlar el tráfico en lugar de depender solo de NetworkPolicies internas. Sin embargo, esto implica que el nodo se conecta a dos subredes: una para el trabajador y otra específica para los pods.
La capacidad de pods en OKE depende directamente de las VNIC secundarias. Si necesitas más de 32 IPs por interfaz, debes configurar la subred con bloques CIDR adicionales. Es vital recordar que las IPs de pod no son persistentes; si el pod se recrea, la dirección IP cambiará, por lo que nunca debes confiar en IPs fijas para la comunicación entre servicios.
Para actualizar el plugin CNI en OKE, a partir de la versión 2.3.0 se ha pasado a una estrategia OnDelete. Esto significa que las actualizaciones no son automáticas para evitar reinicios inesperados. Para forzar la actualización, debes eliminar la política de admisión de validación que impide borrar los pods del CNI, suprimir los pods afectados y luego restaurar la política.
El Ciclo de Vida del Pod y su Impacto en la Red
Entender las fases de un pod es crucial para depurar la red. Un pod en estado Pending puede estar simplemente esperando a que el CNI le asigne una IP. Si ves que el pod se queda ahí eternamente, revisa los eventos de kubelet; es muy probable que haya un fallo en la creación del sandbox de red debido a falta de direcciones disponibles en la subred.
Cuando un pod entra en CrashLoopBackOff, no siempre es un error de código. A veces es un fallo de red que impide que la aplicación arranque (por ejemplo, no llega a la base de datos). El uso de Sondas de Inicio (startupProbe) es fundamental aquí para dar tiempo a las aplicaciones pesadas a cargar antes de que la sonda de Liveness las reinicie por error.
El proceso de terminación también tiene su miga. Cuando borras un pod, Kubernetes envía una señal SIGTERM. Si tienes contenedores sidecar, el kubelet espera a que el contenedor principal termine antes de matar al sidecar. Si el terminationGracePeriodSeconds es muy corto, la red se cortará abruptamente, provocando que las conexiones abiertas den errores 500 en lugar de cerrar la sesión con elegancia.
La estabilidad de la red en Kubernetes depende de una sincronización perfecta entre el runtime del contenedor, el plugin CNI y la infraestructura de la nube. Desde la gestión de prefijos cálidos (WARM_PREFIX_TARGET) en AWS hasta la depuración de tablas conntrack en GKE para evitar la pérdida de paquetes, el éxito reside en monitorizar los logs del sistema y validar que cada capa de red tenga los permisos y la configuración de MTU correctos.