Azure estrena red multi-cluster con Cilium

Azure movió una pieza que muchos equipos de plataforma venían esperando: una red entre clusters para Fleet Manager basada en Cilium, disponible en preview público. Si administras Kubernetes a escala, ya sabes dónde duele el problema: no basta con levantar varios clusters y repartir cargas. En cuanto necesitas que servicios de distintos clusters se hablen con reglas claras, observabilidad consistente y segmentación fina, la operación se complica rápido.

La novedad importa porque ataca justo ese punto. En lugar de tratar cada cluster como una isla, Azure empieza a acercar una capa de red multi-cluster pensada para operar con más orden, especialmente cuando tienes entornos híbridos, equipos separados por dominios y políticas estrictas de seguridad. La referencia que detonó esta nota salió en Developerro News, y puedes revisarla aquí: https://www.developerro.com/news/.

Qué anunció Azure y por qué te debería importar

La idea central es simple de explicar, aunque no tanto de operar: Azure está probando una red entre clusters para Fleet Manager con Cilium como base. Fleet Manager es la capa de administración para agrupar y gobernar varios clusters, y Cilium aporta networking y seguridad basada en eBPF, con un enfoque muy fuerte en políticas y observabilidad. Si trabajas con Kubernetes, seguramente ya has visto Cilium en escenarios donde necesitas control más fino que el que te da una red tradicional de CNI.

¿Por qué te importa esto si ya tienes AKS, VNet peering o algún mesh? Porque el problema real no suele ser solo conectar. El problema es conectar sin abrir demasiado, mantener consistencia entre clusters y no convertir cada cambio en una tarea artesanal. En empresas con varios equipos, cada cluster termina con su propia historia: namespaces, servicios, reglas de red, excepciones de seguridad y dependencias cruzadas. Cuando creces, eso se vuelve una carga operativa.

Azure está empujando hacia una capa donde la red multi-cluster deja de ser una suma de soluciones sueltas. En lugar de depender de integraciones hechas a mano entre clusters, la propuesta apunta a una administración más centralizada desde Fleet Manager, con Cilium como pieza para aplicar políticas y control de tráfico. Si tu organización tiene workloads repartidos entre regiones, suscripciones o incluso entre nube y on-prem, esto encaja con un dolor bastante común.

Fleet Manager como punto de control

Fleet Manager no es solo una consola más. Su valor está en que te ayuda a agrupar clusters y tratarlos como una flota, no como recursos aislados. Eso cambia la conversación de “¿cómo conecto estos dos servicios?” a “¿cómo gobiernas decenas de servicios distribuidos sin perder trazabilidad?”.

En escenarios reales, esto puede significar que un equipo de plataforma define la base común y los equipos de producto consumen clusters con reglas ya establecidas. Si tienes una arquitectura con clusters para producción, staging y entornos regionales, la capacidad de administrar red entre ellos desde una capa común reduce el número de decisiones manuales.

Cilium no entra por moda, entra por control

Cilium se ha ganado espacio porque no se queda en el nivel básico de conectividad. Su enfoque con eBPF permite aplicar políticas de red y visibilidad con más detalle que un CNI tradicional. Para equipos que deben cumplir segmentación estricta, eso significa menos improvisación y más trazabilidad de quién habla con quién.

La combinación con Azure apunta a un caso muy concreto: no solo conectar clusters, sino hacerlo con una política que puedas gobernar. Si tu equipo de seguridad te pide separar dominios de aplicaciones, limitar flujos entre namespaces o auditar tráfico entre servicios, una red multi-cluster con base en Cilium es más cercana a lo que necesitas que un esquema de peering genérico.

Qué problema resuelve en la práctica

Cuando una organización crece, Kubernetes deja de ser un único cluster bonito en un diagrama. Aparecen clusters por región, por unidad de negocio, por nivel de riesgo o por requisitos de residencia de datos. Y en ese punto, la red se vuelve el cuello de botella. No porque no exista conectividad, sino porque cada excepción cuesta tiempo y cada regla nueva puede romper algo.

La preview pública de Azure apunta a reducir ese costo operativo. Si puedes definir una capa común para comunicación entre clusters, te ahorras parte del trabajo de crear túneles, documentar reglas dispersas y mantener configuraciones paralelas. Eso es especialmente útil en entornos híbridos donde una parte de la carga vive en Azure y otra sigue en datacenter o en otra nube.

También hay un ángulo de seguridad. Muchas organizaciones en Latinoamérica operan con políticas de segmentación bastante estrictas, ya sea por regulación, por auditoría interna o por exigencias de clientes enterprise. En ese contexto, el objetivo no es solo que el tráfico pase, sino que pase por rutas conocidas, con políticas claras y con menos superficies abiertas de las necesarias.

Un ejemplo realista de arquitectura

Imagina una empresa de retail con tres clusters en Azure: uno para checkout, otro para catálogo y otro para analítica operativa. Además, mantiene un cluster on-prem para integración con sistemas legados. El servicio de pagos necesita hablar con autorización y antifraude, pero el equipo de datos no debería tener acceso directo a todo el plano de servicios.

Con una red multi-cluster bien gobernada, puedes separar flujos por dominio y evitar que cada equipo cree su propia solución. En vez de abrir rutas amplias entre clusters, puedes definir políticas para que solo ciertos servicios y namespaces tengan comunicación permitida. Eso reduce el radio de impacto cuando algo falla y hace más fácil explicar la arquitectura en una auditoría.

Dónde suele romperse la operación

Estos son los puntos donde normalmente se complica el día a día:

1. Reglas duplicadas entre clusters que nadie sabe quién mantiene.
2. Dependencias ocultas entre servicios que viven en clusters distintos.
3. Diferencias de configuración entre regiones que generan bugs difíciles de reproducir.
4. Equipos de seguridad pidiendo segmentación más fina justo cuando el sistema ya está creciendo.
5. Observabilidad fragmentada, con logs y métricas que no cuentan la historia completa.

La propuesta de Azure con Cilium no elimina esos problemas por arte de magia, pero sí reduce el número de herramientas y pasos manuales para enfrentarlos. Y eso, en operación real, vale bastante.

Cómo encaja con Cilium y con la estrategia de Azure

Azure no está inventando el concepto de multi-cluster networking. Lo que está haciendo es llevarlo a una capa más integrada dentro de su ecosistema, con Fleet Manager como punto de administración. Ahí está la diferencia práctica: menos piezas sueltas, más posibilidad de estandarizar.

Cilium aporta tres cosas que suelen pesar mucho en plataformas grandes: políticas de red más expresivas, visibilidad del tráfico entre workloads y una base técnica moderna con eBPF. Si quieres leer la documentación oficial, estos enlaces te sirven como punto de partida:

• https://docs.cilium.io/
• https://learn.microsoft.com/azure/
• https://kubernetes.io/docs/concepts/services-networking/

La apuesta de Azure sugiere que la red entre clusters no debe tratarse como una función secundaria. En muchas organizaciones, primero se diseña la app, luego se despliega el cluster, y al final se resuelve cómo hablarán entre sí los servicios. Ese orden casi siempre termina en parches. La idea de integrar la capa de red desde Fleet Manager es mover la decisión un nivel arriba.

Qué cambia frente a enfoques más clásicos

Con peering de red o reglas manuales, tú puedes conectar clusters, pero la gobernanza queda repartida entre equipos y herramientas. Con una capa apoyada en Cilium, el foco pasa a ser la política, no solo el túnel. Eso importa porque la mayoría de los incidentes en entornos multi-cluster no nacen por falta de conectividad, sino por exceso de conectividad mal controlada.

Si trabajas con microservicios, sabes que una aplicación puede depender de autenticación, caché, colas, APIs internas y servicios de soporte. Cuando esas piezas están distribuidas en varios clusters, necesitas una forma de expresar relaciones entre ellas sin escribir reglas distintas para cada entorno. Ahí es donde una solución como esta empieza a tener sentido.

H3: Seguridad y segmentación desde el diseño

Un punto fuerte de Cilium es que te permite pensar en políticas más cercanas a la aplicación. No todo se reduce a IPs y puertos. Puedes razonar en términos de servicios, namespaces y flujos concretos, lo que ayuda cuando los clusters cambian con frecuencia.

Eso es útil si tu equipo opera bajo principios de least privilege. En vez de abrir una red completa entre clusters, puedes definir qué workloads se comunican y bajo qué condiciones. En auditorías internas, esa diferencia se nota mucho porque la explicación es más clara y la superficie de exposición es menor.

H3: Observabilidad para no operar a ciegas

Otro tema que pesa es la visibilidad. En una arquitectura multi-cluster, si no ves el tráfico entre servicios, terminas adivinando. Cilium suele destacarse porque ayuda a entender mejor los flujos y a diagnosticar cuellos de botella o rechazos de política.

Para un equipo de SRE o plataforma, eso significa menos tiempo buscando en logs dispersos y más tiempo resolviendo el problema real. Cuando administras varios clusters, cada minuto ahorrado en diagnóstico tiene impacto directo en disponibilidad y en costo humano.

Qué deberías evaluar antes de probarlo

Si estás pensando en evaluar esta preview pública, conviene hacerlo con una lista clara. No te lances solo porque suena bien. En Kubernetes, las previews sirven para entender dirección de producto, pero también para medir compatibilidad con tu operación.

Antes de mover un entorno, revisa estas preguntas:

• ¿Tus clusters están en Azure, en híbrido o en varias nubes?
• ¿Necesitas segmentación por equipo, aplicación o nivel de sensibilidad?
• ¿Tu observabilidad actual te permite seguir flujos entre clusters?
• ¿Tienes políticas de seguridad que dependan de IPs, namespaces o identidades?
• ¿Tu equipo puede absorber el cambio operativo sin romper procesos existentes?

Si la mayoría de tus respuestas apunta a complejidad alta, vale la pena mirar esta preview con atención. Si operas un solo cluster pequeño, probablemente todavía no sea la prioridad.

Tabla rápida de escenarios

Qué significa para equipos en Latinoamérica

En Latinoamérica, muchas empresas están en una mezcla bastante pragmática: parte de la infraestructura ya vive en cloud, pero todavía hay sistemas legados, restricciones de presupuesto y equipos pequeños para la cantidad de servicios que deben operar. Por eso, cualquier avance que reduzca complejidad operativa sin exigir una re-arquitectura completa vale más de lo que parece.

Azure suele tener tracción en organizaciones con presencia regional, especialmente cuando hay necesidades de gobierno, integración con Microsoft 365 o equipos ya acostumbrados al ecosistema. Si a eso le sumas una capa de red multi-cluster con Cilium, el caso de uso se vuelve más claro para empresas que necesitan crecer sin perder control.

También hay un tema de madurez. En muchos equipos de la región, Kubernetes ya dejó de ser una prueba de laboratorio. Ahora es plataforma de negocio. Eso obliga a pensar en redes, políticas y observabilidad con el mismo nivel de seriedad que antes se reservaba para bases de datos o balanceadores. Esta preview va en esa dirección.

Qué puedes ganar si lo adoptas bien

1. Menos reglas manuales repartidas entre clusters.
2. Mejor separación entre dominios de aplicación.
3. Más facilidad para auditar flujos críticos.
4. Menos tiempo resolviendo incidentes de conectividad.
5. Una base más ordenada para crecer a varios clusters.

Claro, también hay costo de aprendizaje. Cilium tiene su propia curva, y Fleet Manager añade otra capa de conceptos. Pero si tu problema ya es multi-cluster, ese costo suele ser menor que seguir operando con soluciones improvisadas.

Tabla resumen

En resumen práctico, Azure está acercando una pieza que faltaba para quienes ya viven en Kubernetes distribuido: una forma más ordenada de manejar red entre clusters sin depender tanto de soluciones artesanales. Si tu operación ya se parece más a una flota que a un solo cluster, vale la pena seguir de cerca esta preview y probarla en un entorno controlado.