Vista previa de Kubernetes v1.36: HPA a cero réplicas, redimensionado de pods en caliente y tokens de imagen efímeros
El proyecto Kubernetes publicó su vista previa de v1.36 con fecha de lanzamiento prevista para el 22 de abril. Treinta y seis mejoras gradúan, lideradas por HPA scale-to-zero activado por defecto, redimensionado de pods en caliente a nivel de pod y tokens de imagen de corta vida que reemplazan a los secrets estáticos.
El proyecto Kubernetes publicó el 30 de marzo su vista previa de v1.36, con una fecha de lanzamiento prevista para el 22 de abril de 2026. Treinta y seis mejoras gradúan en este ciclo, un número que refleja la maduración de funcionalidades que llevan varias versiones en alfa y beta. Tres de ellas destacan por su impacto inmediato en clústeres en producción.
HPA scale-to-zero activado por defecto
El escalado a cero réplicas del Horizontal Pod Autoscaler ha sido la funcionalidad más solicitada del HPA desde que el controlador se lanzó. v1.36 lo activa por defecto. Las cargas de trabajo con HPA configurado pueden ahora reducirse a cero réplicas cuando están inactivas y volver a escalar con el tráfico entrante.
La implicación práctica: economía estilo serverless en Kubernetes estándar sin ningún operador adicional. Los trabajos por lotes, los procesadores de webhooks, los consumidores de eventos y los entornos de desarrollo pueden ahora permanecer a coste cero entre ráfagas sin mantener un grupo de instancias precalentadas.
La funcionalidad requiere un disparador que genere tráfico para despertar el despliegue, normalmente una fuente de eventos externa como KEDA o un adaptador de métricas personalizado. El HPA gestiona el escalado; el desarrollador configura las métricas y el sistema hace el resto.
Redimensionado de pods en caliente extendido al nivel de pod
El redimensionado en caliente de pods —la capacidad de modificar los límites de CPU y memoria de un pod en ejecución sin eliminarlo y recrearlo— pasa al nivel de pod en v1.36. Anteriormente la funcionalidad operaba a nivel de contenedor individual dentro del pod. Esto importa porque los pods con múltiples contenedores y grupos de recursos compartidos pueden ahora redimensionarse con una única operación en lugar de aplicar parches contenedor por contenedor.
Para cargas de trabajo de bases de datos, mallas de servicio con sidecars intensivos y cualquier sistema que trate los reinicios de pod como costosos (arranque lento, precalentamiento, invalidación de caché), esto reduce significativamente la fricción operativa. Las cargas de trabajo intensivas en memoria que necesitan escalar verticalmente bajo carga sin tiempo de inactividad son las beneficiarias más claras.
Tokens de Service Account efímeros para extracción de imágenes
Los secrets estáticos de extracción de imágenes han sido un antipatrón de seguridad durante años: credenciales de larga vida almacenadas en Kubernetes Secrets, reutilizadas entre namespaces, a menudo con permisos de registro más amplios de los que necesita cualquier carga de trabajo individual. v1.36 introduce tokens de Service Account efímeros y de corta vida para la extracción de imágenes, sustituyendo por completo a los secrets estáticos en los registros compatibles.
Los tokens están limitados a la carga de trabajo, expiran tras una ventana configurable breve y rotan automáticamente. El resultado práctico: un nodo comprometido ya no proporciona a un atacante credenciales de registro reutilizables que persistan después de resolver el incidente.
Esto requiere soporte del lado del registro para el intercambio de tokens (OIDC o Workload Identity Federation). AWS ECR, GCP Artifact Registry y Azure ACR admiten flujos compatibles. Harbor y Quay auto-alojados lo soportan con configuración adicional.
Otras mejoras destacadas
Límites de adjunción de volúmenes CSI en el Cluster Autoscaler: El autoscaler ahora respeta los máximos de adjunción de volúmenes CSI por nodo al seleccionar nodos para pods pendientes. Antes, el autoscaler podía elegir un tipo de nodo que no podía adjuntar los volúmenes requeridos, dejando los pods pendientes pese al escalado. Esto elimina toda una clase de incidencias confusas de “¿por qué no se programa mi pod?”.
Mejora del soporte de nodos mixtos Linux/Windows: Las restricciones de programación para pools de nodos con sistemas operativos mixtos se vuelven más ergonómicas, reduciendo la configuración repetitiva de node selectors y toleraciones necesaria para cargas de trabajo Windows.
Auth config estructurada v2: La API de configuración de autenticación estructurada (en alfa desde v1.30) pasa a beta, ofreciendo una alternativa declarativa a los flags de kubeapiserver para configurar autenticadores OIDC.
Calendario de lanzamiento
- Congelación de código: 9 de abril
- RC.1: 14 de abril
- Lanzamiento GA: 22 de abril
El changelog completo y la lista de funcionalidades en beta/alfa está disponible en kubernetes.io/releases. Si utilizas un servicio Kubernetes gestionado, espera que tu proveedor cloud ofrezca v1.36 entre 4 y 8 semanas después del GA, dependiendo de su ciclo de calificación.