Kubernetes 1.36 ya está aquí: espacios de nombres de usuario estables, eliminación de IPVS, retirada de Ingress-NGINX

5 min. de lectura

Kubernetes 1.36 se lanzará el 22 de abril de 2026, con alrededor de 80 mejoras y algunos cambios que mantendrán ocupados a los equipos de operaciones en las próximas semanas. User Namespaces se estabilizan, el modo IPVS desaparece de kube-proxy y el plugin de volúmenes gitRepo se elimina. Paralelamente, el campo externalIPs lanza advertencias de obsolescencia. Quien no actualice ahora su hoja de ruta del clúster, chocará contra un muro con la v1.43.

RelacionadoFinOps en el *Maturity Check* 2026  /  Opus 4.7 vs GPT-5.4: *Inference* en la nube europea 2026

Qué ha cambiado realmente en Kubernetes 1.36

Los datos en cifras: 80 mejoras en el lanzamiento, 18 de ellas pasan a *stable*, 18 a *beta* y 26 son nuevas funciones en *alpha*. Tras varios ciclos de lanzamiento centrados en complementos para IA (*AI-Optimized Scheduling* en 1.35), la versión 1.36 vuelve a las bases de la plataforma. User Namespaces es el punto clave: los Pods ya pueden ejecutarse en producción con su propio rango de ID de usuario frente al host, lo que reduce la superficie clásica de escape de contenedores. Para cargas de trabajo sensibles en entornos regulados, este había sido el *feature* más demandado durante dos años.

Los volúmenes OCI (*Stable*) permiten montar artefactos OCI directamente como volúmenes de solo lectura en Pods, sin necesidad de un Init-Container propio. *HPA Scale-to-Zero* pasa a *Beta* y abre la puerta a despliegues que permanecen inactivos de forma permanente y solo escalan bajo demanda. Para patrones similares a *serverless* dentro de clústeres Kubernetes clásicos, esto supone una palanca concreta.

Las eliminaciones también son relevantes. Los volúmenes gitRepo desaparecen definitivamente, ya que las auditorías de seguridad han documentado repetidamente riesgos en la cadena de suministro. El modo IPVS en kube-proxy, marcado como obsoleto en v1.35, se ha eliminado por completo, lo que convierte la configuración de proxy basada en iptables en el estándar. Los campos *externalIPs* en los objetos *Service* ahora lanzan advertencias de obsolescencia y desaparecerán definitivamente en v1.43. Quien aún utilice *externalIPs* en sus manifiestos, deberá migrar a *LoadBalancer* o *Ingress* antes de esa fecha.

Por qué esto es relevante ahora para los equipos DACH

La consecuencia operativa no radica tanto en las nuevas funciones como en los *breaking changes*. Los clústeres empresariales alemanes con años de evolución suelen tener configuraciones históricas que aún funcionaban en la versión 1.35, pero que fallarán en la 1.36. IPVS era la configuración predeterminada para muchos equipos debido a sus ventajas de rendimiento documentadas en entornos con gran cantidad de servicios. Su eliminación obliga a revisar los límites de *connection tracking* y a planificar la capacidad en configuraciones basadas en *iptables*.

Aún más crítico es el caso de Ingress-NGINX. El *SIG Security* retiró oficialmente el controlador el 24 de marzo de 2026, ya que no había capacidad suficiente entre los *maintainers* para realizar las revisiones de seguridad requeridas. En las instalaciones DACH, Ingress-NGINX es, con diferencia, la opción más utilizada para el *ingress* de clústeres. La migración a *Gateway API* u otros controladores alternativos como HAProxy, Contour o Traefik no es trivial. El *SIG* recomienda realizar un inventario en un plazo de 60 días, ya que las nuevas CVE en Ingress-NGINX dejarán de parchearse.

La graduación de *User Namespaces* abre, al mismo tiempo, una puerta que los equipos de seguridad alemanes llevaban años esperando. Sectores regulados (servicios financieros, salud, infraestructuras críticas) obtienen así una herramienta nativa de la plataforma para endurecer el aislamiento de contenedores, sin depender de proyectos externos como gVisor o Kata Containers. Para las auditorías NIS2, esto se convertirá en un tema de debate en las revisiones de seguridad en los próximos meses.

Valoración para arquitectos cloud

Esta versión está menos impulsada por nuevas funciones que las anteriores, pero conlleva más trabajo por clúster. Los proveedores de Kubernetes gestionado (EKS, AKS, GKE, IONOS Managed Kubernetes, STACKIT) desplegarán el soporte para la 1.36 en las próximas cuatro a ocho semanas. Quienes lo gestionan por su cuenta tendrán el *release day* a partir del 22 de abril. Los equipos con clústeres de tamaño medio deberían actualizar al menos un clúster de *staging* a la 1.36, ejecutar análisis de *manifests* para detectar los tres *breaking changes* y, en paralelo, elaborar un plan para la migración de Ingress-NGINX.

El punto estratégicamente más importante es la retirada de Ingress-NGINX. Quienes aún no tengan una hoja de ruta deberían decidir en las próximas dos semanas: mantenerse con un compromiso propio de parcheo de seguridad, migrar a *Gateway API* con otro implementador o cambiar a un controlador de *ingress* comercial con contrato de soporte. La decisión tendrá consecuencias en la planificación de recursos y la gobernanza de seguridad hasta el tercer trimestre de 2026.

En la práctica, esto significa que muchos equipos tendrán que reservar uno o dos *sprints* en su planificación. Quienes ya hayan experimentado con *Gateway API* tendrán medio camino recorrido. Quienes nunca hayan realizado una migración de reglas de *ingress* deberían programar, como muy tarde a finales de mayo, un *tabletop walkthrough* con los equipos de SRE y redes.

Preguntas frecuentes

¿Es obligatoria la actualización a Kubernetes 1.36?

Kubernetes 1.33 (febrero de 2025) es la primera versión que aún recibe un mes de soporte. A partir de mayo de 2026, Kubernetes 1.34 se considerará la versión soportada más antigua. Quienes utilicen la 1.32 o anteriores ya no tendrán soporte. La actualización a la 1.36 no es obligatoria de inmediato, pero saltar a la siguiente LTS no es un patrón que funcione bien en Kubernetes.

¿Cuál es una buena ruta de migración desde Ingress-NGINX?

El SIG Security recomienda la Gateway API con un implementador mantenido activamente. Los candidatos realistas son Contour, Traefik, HAProxy o las variantes comerciales de NGINX Inc. y F5. La migración no es un proyecto de un solo sprint, ya que la Gateway API utiliza otros tipos de recursos y las reglas de reescritura deben migrarse. Los equipos deberían planificar entre cuatro y doce semanas, dependiendo del tamaño del clúster.

¿Debería usar User Namespaces directamente en producción?

Para cargas de trabajo sensibles en seguridad, sí, pero de forma gradual. El *Feature-Gate* es estable, pero la madurez de la plataforma en escenarios productivos aún requiere uno o dos trimestres de observación. Las pruebas en staging con carga representativa son el primer paso recomendado antes de migrar cargas de trabajo críticas.

Más del MBF Media Netzwerk

Fuente de la imagen de portada: Pexels / Wolfgang Weiser (px:33512156)