En el ecosistema actual de inteligencia artificial y machine learning, la eficiencia computacional no es un lujo: es una necesidad. Sin embargo, muchas empresas descubren que sus costosas inversiones en infraestructura cloud no se traducen en rendimiento real. Un escenario recurrente en Kubernetes con Kubeflow y Cilium ilustra a la perfección cómo dos sistemas correctamente configurados pueden generar un fallo silencioso y costoso. En Q2BSTUDIO, como empresa especializada en aplicaciones a medida, hemos visto este patrón en múltiples clientes que despliegan clusters para entrenamiento distribuido. El problema es sencillo de describir: más de la mitad de las GPUs permanecen ociosas, el entrenamiento nunca arranca, pero todos los indicadores de salud aparecen en verde. No hay errores en los logs, no hay caídas, no hay OOMKills. Solo silencio. Y una factura que sigue creciendo.
Para entenderlo, imaginemos una sala de conciertos con todas las butacas ocupadas. Los músicos están en sus puestos, instrumentos afinados, luces encendidas. Pero el director ha sido llevado a un ala equivocada del edificio, y las puertas cortafuegos, cumpliendo perfectamente su función de seguridad, han sellado esa zona. El resultado es una sala llena y un silencio absoluto. Eso es exactamente lo que ocurre en un cluster de GPUs cuando el coordinador del entrenamiento (el director) se coloca en una zona de disponibilidad y los trabajadores (los músicos) en otra, y las políticas de red de Cilium bloquean la comunicación entre ellas. El fallo no es de ningún componente individual, sino de la ausencia de un mapa único que muestre tanto la ubicación de los pods como las puertas cerradas.
La raíz del problema radica en que el scheduler de Kubernetes, por diseño, es agnóstico a la topología. Coloca los pods basándose en recursos disponibles (CPU, memoria, GPUs) sin considerar en qué zona de disponibilidad caen. Kubeflow hereda esa suposición. Por otro lado, Cilium sí es consciente de la topología: los operadores usan CiliumNetworkPolicy para trazar límites de zona, con el objetivo de aislar el radio de explosión o proteger un pool dedicado de GPUs. Esa es una buena práctica de seguridad, pero Cilium no puede reubicar un pod que ya ha sido colocado. Cuando el coordinador termina en una zona y los trabajadores en otra, la red bloquea silenciosamente la conexión. Nadie tiene el mapa completo de colocación y reglas de red simultáneamente.
Este mismo fallo se manifiesta de tres formas distintas en entornos productivos. La primera es un bloqueo duro: la política de red deniega la conexión directamente. Los trabajadores no pueden alcanzar al coordinador y el entrenamiento nunca comienza. Se detecta en segundos. La segunda es más sutil: no hay bloqueo explícito, pero la sincronización de gradientes (NCCL AllReduce) debe atravesar la latencia entre zonas, reduciendo el rendimiento entre un 30% y un 60% sin ningún error visible. Esto se nota en horas. La tercera es económica: el tráfico cruza zonas de disponibilidad y aparece en la factura como transferencia de datos inter-AZ. Solo se descubre días después, al revisar la factura. En Q2BSTUDIO, hemos ayudado a clientes a detectar estos casos utilizando herramientas de BI y Power BI para monitorizar métricas de utilización de GPU y costes por zona, permitiendo una visión consolidada que de otro modo pasaría desapercibida.
La solución sorprende por su simplicidad. No hay que tocar Cilium (las puertas permanecen cerradas porque la política de seguridad no era el problema), ni parchear Kubernetes o Kubeflow. Solo hay que proporcionar al scheduler la información que le falta: mantener todo el grupo de entrenamiento junto, en una zona cuya ruta de red esté abierta. En la práctica, esto se consigue con unas líneas de YAML nativas de Kubernetes en el spec de la carga de trabajo: nodeAffinity para fijar el grupo a la zona con GPUs, topologySpreadConstraints para colocalizar coordinador y trabajadores, y un toleration para que el coordinador pueda aterrizar en nodos con taint de GPU. Una vez que todos los pods que se comunican comparten la misma zona, el tráfico pasa a ser intra-zona: desaparecen el bloqueo duro, la latencia y el coste inter-AZ. Un solo cambio, tres síntomas eliminados.
Si no se quiere codificar un nombre de zona explícito, se puede usar podAffinity con una clave de topología de zona, para que los trabajadores se coloquen en la misma zona donde aterrice el coordinador. Es la misma idea, pero portable entre clústeres. En nuestras pruebas de laboratorio, la utilización de GPU pasó de aproximadamente un 40% a un 85% en el momento de colocalizar el grupo. Este tipo de optimizaciones forma parte de los servicios que ofrecemos en Q2BSTUDIO, tanto en el ámbito de cloud AWS/Azure como en la integración de agentes IA y ciberseguridad, donde entender la topología de red es crítico para no comprometer el rendimiento ni la seguridad.
La conclusión es clara: tu interfaz de red de contenedores (CNI) tiene opiniones sobre la topología que tu scheduler no puede ver. Las políticas de red conscientes de la topología son silenciosas para el scheduler de Kubernetes, y ese silencio es donde habita el fallo. La solución es nativa de Kubernetes: sin cambios en el CNI, sin parches en el framework, solo restricciones de dispersión topológica y afinidad en el spec de la carga de trabajo. La instrumentación previa es clave: métricas de utilización de GPU y de zona de pods en Prometheus y Grafana exponen este problema en segundos; sin ellas pueden pasar días. Este patrón se generaliza a cualquier combinación de CNI consciente de topología y framework de ML distribuido, no solo a Cilium y Kubeflow.
Para quienes quieran experimentar directamente, existe un laboratorio reproducible que incluye un cluster kind con zonas GPU y CPU, la política de Cilium, reglas de grabación de Prometheus, un dashboard de Grafana y scripts de demostración antes/después. Se puede encontrar en el repositorio https://github.com/ram2valar/kubeflow-cilium-lab y una grabación de la charla en KubeCon + CloudNativeCon India 2026 en https://www.youtube.com/watch?v=BG9XGouyM9c . En Q2BSTUDIO, estamos convencidos de que la prevención de estos fallos silenciosos es una de las inversiones más rentables en cualquier infraestructura cloud moderna.
