Kubernetes 1.32: lo que trae el primer salto de 2025

Actualizado: 2026-05-03

Kubernetes 1.32, nombre en clave Penelope, se publicó el 11 de diciembre de 2024. Cinco meses después lleva tiempo suficiente en producción para evaluar sin depender solo de las notas de la versión. Este post es un repaso desde operaciones, no una lista completa de KEPs: me centro en lo que cambia el día a día de equipos que gestionan clusters medianos y en las decisiones de adopción que merecen revisarse con perspectiva.

Puntos clave

• Dynamic Resource Allocation (DRA) pasa a v1beta1 con API rediseñada: necesario solo para clusters con GPUs o hardware especializado.
• Structured Authorization Configuration alcanza GA, cerrando el camino para componer varios autorizadores en orden configurable.
• Las métricas de sidecar a nivel de contenedor permiten separar con precisión el consumo del proxy del de la aplicación.
• Tres deprecaciones han generado más trabajo del esperado: gitRepo volume plugin, FlowSchema v1beta3 y la variante sin estructura de autorización.
• AnonymousAuth configurable por endpoint reduce superficie de ataque sin romper probes de load balancer.

Dynamic Resource Allocation en v1beta1

La pieza más interesante de 1.32 es la promoción de Dynamic Resource Allocation a v1beta1, con una API rediseñada respecto al alfa anterior. DRA es la respuesta del proyecto al problema de gestionar recursos que no son CPU ni memoria y tienen semántica de acceso compartido o exclusivo, como GPUs, adaptadores de red especializados o dispositivos personalizados.

El nuevo modelo se basa en ResourceClaim y ResourceClaimTemplate, con un driver externo que publica dispositivos disponibles y gestiona la asignación. Es mucho más claro que el alfa, pero sigue siendo complejo para equipos que vienen de la abstracción simple de requests y limits.

En la práctica, solo clusters con GPUs o hardware especializado necesitan DRA. Quien tiene cargas normales puede ignorarla sin coste. El ecosistema de drivers DRA está en formación, con NVIDIA publicando su driver. Montar DRA con el driver NVIDIA es factible pero no trivial: exige revisar políticas de scheduler, permisos del driver y observabilidad específica para detectar fallos que el cluster no hace explícitos.

Estabilización de Structured Authorization

Structured Authorization Configuration pasa a GA en 1.32, cerrando un camino que empezó en alfa en 1.29. El cambio permite componer varios autorizadores en orden configurable desde un único fichero, con capacidad de evaluar webhooks remotos entre los pasos internos.

La utilidad más inmediata es para clusters que combinan RBAC con políticas externas tipo OPA Gatekeeper, Kyverno o un servicio propio de autorización. Con el modelo anterior, combinar autorizadores era engorroso o directamente no soportado según la combinación. Con la configuración estructurada, se declara el orden, las excepciones y los criterios de fallo de forma explícita.

Para equipos que ya tienen autorización compleja montada con apaños previos, la migración merece la pena.

Sidecar containers: el detalle fino

Los sidecar containers alcanzaron GA en 1.29 como init containers con restartPolicy: Always. En 1.32 el cambio concreto es más discreto pero útil: métricas a nivel de contenedor que diferencian sidecar de contenedor principal y de init container normal.

Los equipos que usan service mesh con sidecars Envoy o colectores OpenTelemetry como sidecar ahora pueden separar con precisión el consumo de recursos del proxy del de la aplicación. Antes esa separación requería correlación por nombre de contenedor, frágil en entornos donde los nombres varían. Ahora es directa desde las métricas del kubelet. Esta observabilidad granular complementa el profiling continuo con eBPF para diagnosticar regresiones de rendimiento.

Deprecaciones que han dolido

Tres deprecaciones de 1.32 han generado más trabajo del esperado:

1. Eliminación del plugin de volumen en árbol gitRepo. Equipos con charts Helm antiguos o manifiestos heredados que usaban gitRepo para traer configuración han tenido que migrar a initContainers con git clone o a ConfigMaps generados por pipeline.
2. Deprecación de FlowSchema y PriorityLevelConfiguration v1beta3 a favor de v1. El cambio de API es menor pero afecta a integraciones que usaban la versión beta directamente, incluidos algunos operators actualizados con retraso.
3. Señalización de deprecación para la variante sin estructura de la autorización, que deja de recibir correcciones excepto críticas.

El consejo es hacer el ejercicio completo de revisión de deprecaciones una vez y documentar los patrones nuevos para que el próximo salto sea menos doloroso.

AnonymousAuthConfigurableEndpoints

Un cambio pequeño pero útil es la capacidad beta de restringir la autenticación anónima a endpoints específicos. Antes era todo-o-nada. Ahora se puede permitir anónima para endpoints como /livez o /readyz y prohibirla para el resto.

Esto reduce superficie de ataque sin romper probes de load balancer que dependen de autenticación anónima para health checks. Los equipos que tenían auth anónima deshabilitada y luchaban con LBs externos que no soportaban autenticación de clientes ganan una salida limpia.

Lo que más se ha usado en producción

Pasados cinco meses, las features de 1.32 más activadas en clusters reales son, por orden:

• Structured Authorization GA: casi automática al actualizar kube-apiserver.
• Métricas de sidecar: ganancia gratis sobre observabilidad.
• AnonymousAuth configurable: para limpiar configuraciones laxas.

DRA v1beta1 solo en clusters con GPUs, con perfil mixto de éxito. Algunos equipos la han desplegado sin mayor problema; otros han encontrado integración compleja con operators GPU preexistentes y han pospuesto la migración a 1.33.

Preparando el salto a 1.33

Kubernetes 1.33 salió el 23 de abril con in-place pod resize GA como principal estrella. Para clusters que ya corren 1.32, el salto es pequeño en cambios API pero merece preparación:

• Revisar el estado de DRA si se usa: las APIs v1beta1 pueden seguir funcionando pero hay cambios incrementales que requieren actualizar drivers.
• Los operators que manejaban FlowSchema deben estar en v1; si no, ahora es obligatorio.
• 1.32 sigue con parches hasta aproximadamente abril de 2026, así que no hay prisa física pero conviene no acumular dos saltos.

Mi lectura

Penelope no es una de las versiones vistosas. No trae el cambio dramático que sí trajo 1.30 o 1.31. Lo que trae es consolidación y cierre de deudas pendientes, y eso tiene un valor que se infravalora en el momento pero se nota cuando uno empieza a adoptar 1.33 sobre un cluster limpio.

Lo que más trabajo ha dado es la limpieza de deprecaciones: manifiestos Helm antiguos con gitRepo, operators en versiones viejas con FlowSchema beta, configuraciones de admission con sintaxis anterior. Todos son trabajo invisible hasta que toca actualizar. Con Kubernetes, la inversión en buena higiene de cluster siempre se amortiza en el ciclo siguiente. Las mismas prácticas de higiene aplican a la migración a containerd 2.0, que comparte varios de estos patrones de actualización incremental.