Kubernetes 1.34 salió en agosto de 2025 con un puñado de cambios importantes en sidecars nativos, contenedores de inicialización y la primera ola de estabilización de WaitForFirstConsumer en modo volumen genérico. El ciclo de 1.35 ha entrado ya en congelación de funciones, las release notes preliminares están en el repositorio y el patrón estable de tres versiones por año sigue funcionando como reloj. Toca mirar qué llega en la próxima versión, qué merece atención real y qué podemos dejar para otro día sin consecuencias.
Contexto: de dónde venimos en el ciclo 1.3x
Desde 1.30 el proyecto ha priorizado estabilización sobre novedad, y eso se nota en la calidad de lo que sale. 1.32 y 1.33 eliminaron definitivamente componentes antiguos como CSI migración de in-tree a out-of-tree para los grandes proveedores. 1.34 llevó a estable el soporte de sidecars nativos, mejoró el modelo de prioridad de pods y añadió más control sobre cómo el scheduler reacciona cuando un nodo pierde capacidad. El resultado es que un clúster 1.34 en 2026 es más predecible, menos sorprendente y más fácil de operar que uno 1.28 de hace tres años.
La clave cultural es que el proyecto ha aceptado que para la mayoría de usuarios Kubernetes es infraestructura, no producto. Los cambios grandes de filosofía son raros; lo que dominan son mejoras incrementales de robustez, de experiencia de operador y de cobertura de casos raros que antes eran dolor. 1.35 continúa esa línea.
Novedades que realmente importan
La estabilización más relevante de 1.35 es la de las políticas de admisión basadas en CEL, que ya estaban en beta desde 1.30. CEL como lenguaje de validación reemplaza progresivamente a los webhooks de admisión escritos en código, y eso tiene implicaciones operativas reales. Un webhook de admisión que cae bloquea el clúster; una expresión CEL evaluada dentro del plano de control no tiene ese riesgo. Para clústeres pequeños donde cada dependencia externa es una pieza más que puede fallar a las tres de la mañana, sustituir webhooks por CEL reduce incidentes.
La segunda novedad que merece mirar es el soporte mejorado para actualizaciones de versión en lugares de nodos mediante la nueva API de KubeletConfigSource. Hasta ahora cambiar configuración del kubelet implicaba rotar el nodo o manipular archivos de sistema y reiniciar el servicio. Con la nueva API, el plano de control puede empujar configuración nueva al kubelet sin reinicio, lo que abre la puerta a operaciones de gestión de flotas mucho más limpias. Para un equipo con cinco nodos es marginal; para uno con cincuenta nodos cambia la forma de operar.
El tercer cambio notable es la generalización del recurso DRA, Dynamic Resource Allocation, que llega estable en 1.35 para varios tipos de aceleradores. Para equipos que ejecutan cargas con GPUs, NPUs o aceleradores específicos, DRA reemplaza el modelo antiguo de device plugins con algo mucho más rico y expresivo. Si no tienes aceleradores en el clúster, DRA es transparente. Si los tienes, vale la pena empezar a familiarizarse con la API ahora.
Lo que se queda en beta
Varias funciones esperadas siguen en beta y no llegan estables en 1.35. La más visible es PodAffinity/PodAntiAffinity basada en zonas, que promete simplificar el diseño de alta disponibilidad multi-región pero que lleva en beta desde 1.32 y aún tiene casos raros con scheduler bajo carga. No es un bloqueante para uso en producción si ya la tienes configurada, pero conviene esperar a ver si 1.36 la estabiliza antes de refactorizar políticas de placement.
La segunda novedad que sigue en beta es in-place pod resize, la capacidad de cambiar CPU y memoria solicitada de un pod sin reinicio. Es una función que sobre el papel suena muy útil pero que en la práctica tiene implicaciones sutiles con el kernel y con ciertos runtimes. En 1.35 sigue siendo beta y con feature gate explícito; para clústeres con cargas estables no es prioridad, y para cargas muy dinámicas todavía conviene validar en entornos de pruebas antes de activar.
Hay otras piezas en beta que tocan casos de uso muy específicos, como el soporte de snapshot de volúmenes con opciones avanzadas o las mejoras en el comportamiento de Taint Based Evictions. No son para la mayoría; si te afectan ya lo sabes.
Deprecaciones que conviene atender
1.35 continúa la retirada progresiva de APIs viejas. El recordatorio clave es que si aún tienes objetos con apiVersion antigua (beta, v1beta1, etc.) de recursos que llevan estables varios ciclos, ahora es el momento de migrarlos. La función kubectl convert sigue viva y cubre la mayoría de casos; los que no cubre suelen ser objetos que deberían rehacerse de cero porque el modelo cambió.
El otro frente de deprecación son flags del kubelet y del kube-apiserver que se habían dejado por compatibilidad. Varios van a desaparecer en 1.35 o en 1.36. Si tus playbooks Ansible o tu gestión de configuración todavía los pasan, ahora es buen momento de limpiar. El release notes de 1.35 los lista de forma explícita; leerlos antes de planificar la ventana de upgrade ahorra incidencias.
Cómo planificar el upgrade
La cadencia predecible del proyecto permite planificar upgrades con confianza. Mi recomendación para un clúster pequeño o mediano de producción es ir siempre una versión por detrás de la última estable: ahora mismo eso significa 1.33 en producción y 1.34 en entornos de pruebas, con 1.35 en observación en cuanto salga el release candidate. Este desfase de una versión deja tiempo para que los bugs de primera hora se descubran y se corrijan en patches menores, pero no tan atrás como para perder soporte oficial, que cubre solo las tres últimas versiones.
Para equipos que operan varios clústeres, el patrón razonable es tener uno en la versión más reciente actuando como canario. Se prueba allí, se mira durante un par de semanas, y si todo va bien se propaga a los demás. Esta disciplina evita sorpresas en el clúster principal y permite capturar problemas específicos de combinaciones de componentes que no aparecen en los entornos de pruebas sintéticos.
El upgrade en sí, si usas kubeadm o distribución gestionada, es razonablemente directo. Lo importante es haber leído el release notes completo, no solo los títulos, y tener probadas las migraciones de API en entorno de pruebas antes de tocar producción. Los problemas serios en upgrades raramente vienen del binario del plano de control; vienen de recursos personalizados, de admisión de webhooks, de volúmenes con CSI exótico o de networking con CNIs que no siguieron el ritmo.
Mi lectura
Kubernetes 1.35 es una versión incremental más en una serie de versiones incrementales, y eso está bien. El proyecto ha llegado al punto en el que ya no necesita revoluciones; necesita pulir lo que tiene y eliminar aristas. Las novedades que llegan estables en 1.35, CEL para admisión, DRA general para aceleradores y la API de configuración del kubelet, son útiles y cubren casos reales sin romper nada. Las que se quedan en beta merecen atención pero no adopción apresurada. El patrón operativo sano es actualizar con disciplina, una versión por detrás de la última, leer el release notes en serio y dejar que los demás descubran los bugs de los primeros días por ti.
