Kubernetes 1.33: el sneak peek visto desde operaciones
Actualizado: 2026-07-07
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 beta y queda habilitado por defecto (KEP-1287): cambiar CPU y memoria sin reiniciar el pod mediante el nuevo subrecurso
resize. -
Los sidecars llegan a GA en esta misma release y ya participan del resize en vivo; el patrón sidecar cierra su ciclo de madurez.
-
Cambios de seguridad: los tokens de ServiceAccount se atan más al nodo, los namespaces de usuario quedan activados por defecto y ClusterTrustBundles llega a beta.
-
Dos fuentes de ruido en el upgrade: deprecación de la API de endpoints y bloqueo de feature-gates que ya alcanzaron 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, ahora en beta
La KEP-1287, in-place update of pod resources, sube a beta en 1.33 y llega con el feature-gate InPlacePodVerticalScaling activado por defecto, después de recorrer alfa 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 soporte la actualización del cgroup asociado: containerd la incorporó desde la versión 1.6.9, y CRI-O desde que implementó la API UpdateContainerResources. La operación pasa ahora por un subrecurso resize dedicado (antes iba por el campo status.resize, ya obsoleto), con condiciones PodResizePending y PodResizeInProgress para seguir el estado del cambio.
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, implementados como initContainers con restartPolicy: Always, llegaron a beta con el gate activado por defecto en 1.29 y se han ido puliendo desde entonces. La novedad de 1.33 es que el patrón alcanza por fin GA (el feature-gate SidecarContainers queda bloqueado a su valor por defecto y se retirará en 1.36), y de paso los sidecars también participan del resize en vivo, aunque este siga en beta. 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 componente con soporte nativo dentro del pod.
Cambios de seguridad que vale la pena revisar
Varios cambios pequeños que en conjunto aprietan la seguridad por defecto:
-
Los Bound Service Account Tokens se refuerzan: el token ahora incluye también el nombre del nodo en el claim, así que la identidad del pod queda atada más de cerca al nodo donde corre, y un token robado pierde parte de su utilidad fuera de ese contexto.
-
Los namespaces de usuario (user namespaces) quedan activados por defecto para los pods que los piden, con el aislamiento extra de UID/GID que eso da frente a un escape de contenedor. Eso sí, exige containerd 2.0+ y runc 1.2+ en los nodos.
-
ClusterTrustBundlesllega a beta: un objeto nativo para distribuir bundles de CA de confianza sin depender de ConfigMaps hechos a mano. -
Para quienes usan kube-proxy en modo ipvs: el modo nftables sigue avanzando hacia GA como reemplazo a medio plazo de iptables e ipvs, aunque iptables seguirá siendo el modo por defecto incluso una vez nftables se gradúe. Si se usa Cilium con kube-proxy replacement esto no afecta; si se usa kube-proxy tradicional, vale la pena ir probando nftables en un nodo de test.
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.
Bloqueo de --feature-gates que llegan a GA. Cuando un feature-gate llega a GA, su valor queda bloqueado y deja de poder desactivarse; SidecarContainers es el caso claro en esta release, bloqueado a true y con retirada anunciada para 1.36. Si hay Ansible o Talos fijando explícitamente ese gate a false (o cualquier otro ya bloqueado) en los manifiestos de nodo, el arranque falla con un error de flag inconsistente. Conviene auditar y limpiar esas flags explícitas 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 seguir de cerca es in-place resize, ya en beta y activado por defecto. Es la función que cambia más claramente cómo se piensa la asignación de recursos en cargas dinámicas, aunque su paso a GA tocará esperarlo a una release posterior. Para clusters con muchos pods de larga vida y tráfico impredecible, apunta a quitar 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, probando el resize en preproducción y esperando quizás al parche 1.33.1 o 1.33.2 para producción, como es costumbre prudente.
Este artículo también está disponible en inglés.
