Kubernetes 1.33: el sneak peek visto desde operaciones

Actualizado: 2026-05-03

El sneak peek oficial de Kubernetes 1.33 se publicó el 26 de marzo y la release llega el 23 de abril con el nombre Octarine. La nota es más sobria que la de 1.30 o 1.32: pocos fuegos artificiales y bastantes cierres de deuda. En 1.33 madura in-place pod resize, se limpian anotaciones antiguas del endpoint, y entran cambios de seguridad que vale la pena conocer antes de encontrárselos en el changelog definitivo.

Este post es un repaso desde la perspectiva de operaciones. No voy a listar todas las KEPs; hay otras publicaciones que lo hacen. Me quedo con lo que cambia el día a día y con lo que requiere trabajo de preparación. Para el contexto de versiones anteriores, el análisis de Kubernetes 1.31: estabilizaciones es referencia útil de la cadencia de madurez.

Puntos clave

• In-place pod resize pasa a GA (KEP-1287): cambiar CPU y memoria sin reiniciar el pod, con runtime containerd 2.0+ o CRI-O reciente.
• Los sidecars participan ahora del in-place resize; el patron sidecar cierra su ciclo de madurez.
• Cambios de seguridad: PodSecurityStandards baseline más estricto, ServiceAccount token projection avanza hacia default.
• Dos fuentes de ruido en el upgrade: deprecación de anotación de endpoints y limpieza de feature-gates GA.
• Es una release de consolidación, no de titulares: un upgrade de 1.32 a 1.33 no debería dar sobresaltos con preparación adecuada.

In-place pod resize por fin GA

La KEP-1287, in-place update of pod resources, sube a GA en 1.33 después de recorrer beta desde 1.27. Hasta ahora, cambiar la CPU o la memoria de un pod vivo obligaba a recrearlo: destruir el contenedor, programarlo de nuevo, perder el estado en memoria, sufrir cold starts. Con in-place resize se pueden modificar los recursos sin reiniciar, siempre que el runtime (containerd 2.0+, CRI-O reciente) soporte la actualización del cgroup asociado.

El caso práctico más evidente es el de cargas con picos inciertos que antes se sobreaprovisionaban para evitar el ciclo de kill and restart. Con resize vivo, un VPA puede ajustar memoria hacia arriba cuando el pod empieza a respirar cerca del límite, sin impacto en latencia. Lo mismo aplica a bases de datos dentro del cluster que toleran mal los reinicios: un Postgres gestionado por operador puede crecer en memoria sin cortar conexiones.

Los límites siguen siendo reales:

• No todos los recursos se pueden cambiar en vivo. Storage, hugepages y algunos devices siguen requiriendo recreación.
• El kubelet necesita descubrir la actualización a través del runtime; mezclar nodos con containerd 1.7 y 2.x dentro del mismo cluster puede provocar comportamientos inconsistentes si no se alinea primero.

El plan recomendado: levantar un entorno 1.33 con el runtime más nuevo, probar el resize en una carga dummy midiendo cold restart rate con PromQL, y solo después autorizar el feature en producción.

Sidecars, el capítulo que cierra

Los sidecar containers como initContainers con restartPolicy: Always alcanzaron estable en 1.29 y han ido puliéndose desde entonces. La novedad en 1.33 no es el patrón en sí sino el soporte de recursos por contenedor al reasignar: los sidecars también participan del in-place resize. Un pod con Envoy como sidecar y la aplicación principal ya no requiere rotar todo el pod para ajustar memoria al proxy cuando se dispara la carga de mTLS.

Hay un detalle menor pero útil: el OpenTelemetry collector como sidecar deja de tener ese patrón raro de cerrar primero y perder los últimos spans. Con el orden de terminación claro desde 1.29 y los resize movibles, el patrón sidecar termina siendo lo más cercano a lo que prometía en 2023: un ciudadano de primera clase del pod.

Cambios de seguridad que vale la pena revisar

Varios cambios pequeños que en conjunto aprietan la seguridad por defecto:

• La deprecación de AllowAllPodVolumeActions avanza.
• Los PodSecurityStandards a nivel baseline empiezan a bloquear algunos patrones que en 1.32 generaban solo warnings. Concretamente, los hostPath con escritura y los capabilities no declarados en la política son más ruidosos en admission.
• ServiceAccount token projection continúa su camino hacia el default. Si todavía hay pods consumiendo el token montado vía secret tradicional, la migración a projected tokens con audiencia específica conviene cerrarla antes de dos o tres releases más.
• Para quienes usan kube-proxy ipvs: en 1.33 los mensajes de deprecación hacia nftables se vuelven más explícitos. Si se usa Cilium como CNI con kube-proxy replacement esto no cambia nada; si se usa kube-proxy tradicional en modo ipvs, vale la pena empezar a migrar.

Para gestionar la seguridad de los workloads más allá del core de Kubernetes, el análisis de Falco para seguridad en runtime ofrece la capa de detección complementaria.

Lo que va a ser ruidoso en el upgrade

Dos cosas que anticipamos ruidosas en el upgrade a 1.33:

DeprecatedAnnotation de endpoints. Los controllers que aún leen endpoints.kubernetes.io/last-change-trigger-time van a tener que migrar al campo equivalente en EndpointSlice. La mayoría de herramientas populares ya lo hicieron, pero los scripts internos raramente lo han hecho.

Limpieza de --feature-gates. Más flags graduando a GA limpia la configuración de kubelet pero obliga a auditar los manifiestos de nodos que aún incluyan flags explícitos. Si hay Ansible o Talos aplicando --feature-gates=InPlacePodVerticalScaling=true y se aplica 1.33, el arranque fallará con un error oscuro. Conviene limpiar las flags antes del upgrade.

Mi lectura

Octarine es una release de consolidación, no de titulares. El trabajo interesante está en rematar cosas que llevaban dos o tres ciclos en beta, reducir la deuda de anotaciones antiguas y seguir apretando los defaults de seguridad. Para quien opera clusters, esto es mejor que el 1.30 con DRA estrenándose o el 1.32 con tantos cambios que el upgrade necesitaba ventana. Un upgrade de 1.32 a 1.33 no debería dar sobresaltos si se hace la tarea de auditar flags y deprecaciones.

El punto que más vale la pena es in-place resize GA. Es la función que cambia más claramente cómo se piensa la asignación de recursos en cargas dinámicas. Para clusters con muchos pods de larga vida y tráfico impredecible, quita una categoría entera de incidentes: los reinicios forzados por reajuste. Esto por sí solo justifica planificar el upgrade en cuanto la versión 1.33.0 esté disponible, esperando quizás al parche 1.33.1 o 1.33.2 para producción, como es costumbre prudente.