Por: Brendan Burns, vicepresidente corporativo e investigador técnico, Azure OSS y Cloud Native, Microsoft.

Hay un patrón en cómo madura la tecnología compleja. Al principio, los equipos toman sus propias decisiones: herramientas diferentes, abstracciones distintas, formas distintas de razonar sobre el fracaso. Parece flexibilidad, pero a gran escala se revela como fragmentación.

La solución nunca es tan solo más capacidad; Es una filosofía operativa compartida. Kubernetes lo demostró. No respondió solo a «¿cómo gestionamos los contenedores?» Respondió: «¿Cómo cambiamos los sistemas en funcionamiento de manera segura?» La comunidad construyó esos patrones, los endureció y los convirtió en la base.

La infraestructura de IA sigue en una fase caótica. El cambio de «en funcionamiento frente a rota» a «buenas respuestas frente malas respuestas» es un problema operativo diferente, y no se resolverá con más herramientas. Se resuelve como lo hizo lo nativo en la nube: código abierto que crea las interfaces compartidas y la presión comunitaria que sustituyen el juicio individual por prácticas documentadas y reproducibles.

Eso es hacia lo que avanzamos. Desde mi última actualización en KubeCon + CloudNativeCon Norteamérica 2025, nuestros equipos han seguido con la inversión en infraestructura de IA de código abierto, operaciones multiclúster, redes, observabilidad, almacenamiento y ciclo de vida de clústeres. En KubeCon + CloudNativeCon Europe 2026 en Ámsterdam, compartimos varios anuncios que reflejan ese mismo objetivo: llevar la madurez operativa de Kubernetes a las cargas de trabajo y demandas actuales.

Aprendan más sobre Azure Kubernetes Service

Construir la base de código abierto para la IA en Kubernetes

La convergencia de la infraestructura de IA y Kubernetes significa que las lagunas en la infraestructura de IA y en la infraestructura de Kubernetes son cada vez más las mismas. Una parte significativa de nuestro trabajo upstream para este ciclo ha consistido en construir las primitivas que hacen que las cargas de trabajo respaldadas por GPU sean ciudadanos de primera clase dentro del ecosistema nativo en la nube.

En el ámbito de la planificación, Microsoft ha colaborado con socios del sector para promover estándares abiertos para la gestión de recursos de hardware. Hitos clave incluyen:

• La Asignación Dinámica de Recursos (DRA, por sus siglas en inglés) ha pasado a disponibilidad general, con el controlador de ejemplo de DRA y el Acceso de Administrador de DRA también enviados como parte de ese trabajo.
• Workload Aware Scheduling para Kubernetes 1.36 añade soporte para DRA en la API de Workload y facilita la integración en KubeRay, para facilitar que los desarrolladores soliciten y gestionen infraestructuras de alto rendimiento para entrenamiento e inferencia.
• DRANet ahora incluye compatibilidad upstream para tarjetas de interfaz de red (NIC, por sus siglas en inglés) de Azure RDMA, para extender la gestión de recursos de red basada en DRA a hardware de alto rendimiento donde la alineación de topología GPU-NIC afecta de manera directa al rendimiento del entrenamiento.

Más allá de la programación, hemos seguido con las inversiones en las herramientas necesarias para desplegar, operar y asegurar cargas de trabajo de IA en Kubernetes:

• AI Runway es un nuevo proyecto de código abierto que introduce una API común de Kubernetes para cargas de trabajo de inferencia, para brindar a los equipos de plataforma una forma centralizada de gestionar los despliegues de modelos y adoptar nuevas tecnologías de servicio a medida que evoluciona el ecosistema. Incluye una interfaz web para usuarios que no deberían necesitar conocer Kubernetes para desplegar un modelo, junto con el descubrimiento integrado de modelos HuggingFace, indicadores de ajuste de memoria GPU, estimaciones de costes en tiempo real y soporte para entornos de ejecución como NVIDIA Dynamo, KubeRay, llm-d y KAITO.
• HolmesGPT se ha unido a la Cloud Native Computing Foundation (CNCF) como un proyecto Sandbox, que incorpora capacidades de solución de problemas agénticos al ecosistema compartido de herramientas nativas en la nube.
• Dalec, un proyecto CNCF recién incorporado, define especificaciones declarativas para construir paquetes de sistemas y producir imágenes mínimas de contenedores, con soporte para generación de SBOM y atestados de procedencia en tiempo de compilación. Reducir la superficie de ataque y las vulnerabilidades y exposiciones comunes en la fase de construcción es importante para cualquier organización que intente ejecutar cargas de trabajo de IA de manera responsable y a gran escala.
• Cilium también recibió un amplio conjunto de contribuciones de Microsoft este ciclo, incluido soporte nativo mTLS ztunnel para comunicación de cargas de trabajo cifradas sin sidecar, controles de cardinalidad de métricas Hubble para gestionar costes de observabilidad a escala, agregación de registros de flujo para reducir el volumen de almacenamiento, y dos Propuestas de Funcionalidades Cilium (CFPs, por sus siglas en inglés) fusionadas para mallas de clúster, que avanzan en redes entre clústeres.

Qué hay de nuevo en Azure Kubernetes Service

Además de nuestras contribuciones ascendentes, me alegra compartir nuevas capacidades en Azure Kubernetes Service (AKS) en redes y seguridad, observabilidad, operaciones multiclúster, almacenamiento y gestión del ciclo de vida del clúster.

Desde controles basados en IP hasta redes conscientes de identidad

A medida que los despliegues de Kubernetes se distribuyen, las redes basadas en IP se vuelven más difíciles de razonar: la visibilidad se degrada, las políticas de seguridad se vuelven difíciles de auditar y la comunicación de carga de trabajo cifrado ha requerido a nivel histórico una malla de servicio completo o una cantidad significativa de trabajo personalizado. Nuestras actualizaciones de red en este ciclo cierran esa brecha trasladando la inteligencia de seguridad y tráfico a la capa de aplicación, donde es más significativo y más fácil de manejar.

Azure Kubernetes Application Network ofrece a los equipos TLS mutuo, autorización consciente de la aplicación y telemetría detallada de tráfico a través de la comunicación de entrada y dentro del clúster, con conectividad multirregión integrada. El resultado es una seguridad consciente de la identidad y una visión real del tráfico sin la sobrecarga de ejecutar una malla de servicio completo. Para los equipos que gestionan la deprecación de ingress-nginx, el enrutamiento de aplicaciones con Meshless Istio proporciona un camino basado en estándares: soporte para la API de Kubernetes Gateway sin sidecars, soporte continuo para configuraciones existentes de ingress-nginx y contribuciones a ingress2gateway para equipos que avanzan de forma incremental.

A nivel de plano de datos, el cifrado WireGuard con el plano de datos Cilium asegura el tráfico nodo a nodo de manera eficiente y sin cambios en la aplicación. Cilium mTLS en Servicios Avanzados de Redes de Contenedores extiende esto a la comunicación pod-a-pod a través de certificados X.509 y SPIRE para la gestión de identidad: tráfico de carga de trabajo autenticado y cifrado sin sidecars. Para rematar, Expansión CIDR en cápsulas elimina una restricción operativa de larga duración al permitir que los clústeres amplíen sus rangos de IP pod en lugar de requerir una reconstrucción, y ahora los administradores pueden deshabilitar HTTP proxy variables para nodos y pods sin tocar la configuración del plano de control.

Visibilidad que se ajuste a la complejidad de los clústeres modernos

Operar Kubernetes a gran escala solo es manejable con una visibilidad clara y consistente de la infraestructura, las redes y las cargas de trabajo. Dos lagunas persistentes que hemos cerrado son la telemetría de GPU y la observabilidad del tráfico de red, ambas se vuelven más críticas a medida que las cargas de trabajo de IA entran en producción.

Los equipos que gestionan cargas de trabajo con GPU a menudo han tenido un punto ciego significativo en la monitorización: la utilización de GPU tan solo no era visible junto a las métricas estándar de Kubernetes sin una configuración manual del exportador. AKS ahora destaca el rendimiento y la utilización de GPU directo en Prometheus y Grafana gestionados, para colocar la telemetría de GPU en la misma pila que los equipos ya utilizan para la planificación de capacidad y alertas. En el lado de la red, ahora está disponible visibilidad L3/L4 por flujo y L7 soportada en tráfico HTTP, gRPC y Kafka, incluyendo IPs, puertos, cargas de trabajo, dirección de flujo y decisiones de política, con una nueva experiencia Azure Monitor que incorpora paneles integrados y la incorporación con un solo clic. Para los equipos que se enfrentan al problema inverso (volumen de métricas en lugar de brechas métricas), los operadores pueden ahora controlar de manera dinámica qué métricas a nivel de contenedor se recopilan a través de recursos personalizados de Kubernetes, para mantener los paneles centrados en señales accionables. La red de contenedores agénticos añade una interfaz web que traduce consultas en lenguaje natural en diagnósticos de solo lectura a través de telemetría en vivo, para acortar el camino de «algo va mal» a «esto es lo que hay que hacer al respecto».

Operaciones más sencillas entre clústeres y cargas de trabajo

Para las organizaciones que ejecutan cargas de trabajo en múltiples clústeres, la red entre clústeres ha significado a nivel histórico fontanería personalizada, descubrimiento de servicios inconsistente y visibilidad limitada a través de los límites del clúster. Azure Kubernetes Fleet Manager ahora aborda esto mediante redes entre clústeres a través de una malla gestionada de Cilium, para brindar conectividad unificada entre clústeres AKS, un registro global de servicios para el descubrimiento de servicios entre clústeres y enrutamiento inteligente con la configuración gestionada de manera central, en lugar de repetida por clúster.

En el lado del almacenamiento, los clústeres pueden ahora consumir almacenamiento de un pool compartido de SAN Elastic en lugar de aprovisionar y gestionar discos individuales por carga de trabajo. Esto simplifica la planificación de capacidad para cargas de trabajo con estado variable y demanda variable y reduce la sobrecarga de aprovisionamiento a gran escala.

Para los equipos que necesitan un punto de acceso más accesible a Kubernetes, AKS de escritorio ya está disponible a nivel general. Aporta una experiencia completa de AKS a su escritorio, para facilitar que los desarrolladores ejecuten, prueben e iteren en cargas de trabajo Kubernetes a nivel local, con la misma configuración que usarán en producción.

Mejoras más seguras y recuperación más rápida

El coste de una mala actualización se acumula con rapidez en la producción, y la recuperación de una ha sido, a nivel histórico, lenta y estresante. Varias actualizaciones de este ciclo se centran en específico en hacer que los cambios de conglomerado sean más seguros, observables y reversibles.

Las actualizaciones del pool de agentes azul-verde crean un pool paralelo con la nueva configuración en lugar de aplicar cambios en su lugar, para que los equipos puedan validar el comportamiento antes de desplazar el tráfico y mantener un camino claro de retroceso si algo parece mal. El rollback del pool de agentes complementa esto al permitir a los equipos revertir un pool de nodos a su versión e imagen de nodos anteriores de Kubernetes cuando surgen problemas tras una actualización (sin una reconstrucción completa). En conjunto, estos ofrecen a los operadores un control real sobre el ciclo de vida de la actualización en lugar de elegir entre «mejorar y tener esperanza» o «quedarse atrás». Para una provisión más rápida durante eventos de escalabilidad, la especificación de imagen preparada permite a los equipos definir imágenes de nodos personalizadas con contenedores precargados, configuraciones del sistema operativo y scripts de inicialización, lo que reduce el tiempo de arranque y mejora la consistencia en entornos que requieren un aprovisionamiento rápido y repetible.

Comiencen con Azure Kubernetes Service