Kubernetes 1.35: lo que ya se ve venir

Actualizado: 2026-05-03

Kubernetes 1.34 salió en agosto de 2025 con 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.

Puntos clave

• Políticas de admisión basadas en CEL llegan a estable en 1.35: reemplazan webhooks de admisión con expresiones evaluadas dentro del plano de control, eliminando un punto de fallo externo.
• DRA (Dynamic Resource Allocation) llega estable para varios tipos de aceleradores: GPU, NPU y aceleradores específicos con un modelo de API más rico que los device plugins.
• La nueva API de KubeletConfigSource permite empujar configuración al kubelet sin reinicio del nodo.
• Varias funciones esperadas siguen en beta: zone-based PodAffinity/PodAntiAffinity y in-place pod resize.
• El patrón operativo sano es mantener una versión por detrás de la última estable y leer el release notes completo antes de planificar el upgrade.

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 la migración CSI 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.

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 domina son mejoras incrementales de robustez, de experiencia de operador y de cobertura de casos raros. 1.35 continúa esa línea.

Novedades que realmente importan

Políticas de admisión CEL (estable). CEL como lenguaje de validación reemplaza progresivamente a los webhooks de admisión escritos en código. La diferencia operativa es significativa: 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.

# Ejemplo de ValidatingAdmissionPolicy con CEL (estable en 1.35)
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: requerir-limite-memoria
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["deployments"]
  validations:
    - expression: >
        object.spec.template.spec.containers.all(c,
          has(c.resources.limits) && has(c.resources.limits.memory))
      message: "Todos los contenedores deben definir límite de memoria"

Esto permite expresar políticas de validación sin desplegar un webhook externo con su propio certificado TLS, su alta disponibilidad y su monitorización adicional.

DRA general para aceleradores (estable). Dynamic Resource Allocation llega estable en 1.35 para GPU, NPU y aceleradores específicos. DRA reemplaza el modelo antiguo de device plugins con algo más rico y expresivo:

• Permite que los aceleradores declaren capacidades detalladas (no solo conteo).
• Permite que los Pods soliciten aceleradores con criterios más granulares.
• Facilita el compartimiento de aceleradores entre Pods cuando el hardware lo permite.

Para equipos que ejecutan cargas con GPUs o NPUs, DRA es el camino a seguir. Si no tienes aceleradores en el clúster, DRA es transparente.

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. Para equipos con muchos nodos esto cambia la forma de operar actualizaciones de configuración de forma significativa.

Lo que se queda en beta

Zone-based PodAffinity/PodAntiAffinity. Promete simplificar el diseño de alta disponibilidad multi-región pero lleva en beta desde 1.32 con casos raros bajo carga de scheduler. No es bloqueante para uso en producción si ya está configurada, pero conviene esperar a que 1.36 la estabilice antes de refactorizar políticas de placement.

In-place pod resize. La capacidad de cambiar CPU y memoria solicitada de un pod sin reinicio. Sobre el papel es muy útil; en la práctica tiene implicaciones sutiles con el kernel y con ciertos runtimes. Sigue siendo beta con feature gate explícito. Para cargas estables no es prioridad; para cargas muy dinámicas conviene validar en entornos de prueba antes de activar en producción.

Deprecaciones que conviene atender

1.35 continúa la retirada progresiva de APIs antiguas. Si aún hay objetos con apiVersion antigua (beta, v1beta1) de recursos que llevan estables varios ciclos, ahora es el momento de migrarlos. La función kubectl convert cubre la mayoría de casos.

También desaparecen en 1.35 o en 1.36 varios flags del kubelet y del kube-apiserver que se habían dejado por compatibilidad. Si los playbooks Ansible o la 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. La 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 (solo las tres últimas versiones tienen soporte).

Para equipos con varios clústeres, el patrón razonable es tener uno en la versión más reciente actuando como canario. Esta disciplina de upgrade es análoga a la que se aplica en PostgreSQL 18 y en cualquier infraestructura crítica: probar primero, propagación controlada, no actualizar todo a la vez.

El upgrade en sí, si se usa kubeadm o distribución gestionada, es razonablemente directo. Los problemas serios en upgrades raramente vienen del binario del plano de control; vienen de recursos personalizados, de webhooks de admisión, de volúmenes con CSI exótico o de networking con CNIs que no siguieron el ritmo. Ahí es donde hay que invertir el tiempo de pruebas: no en ejecutar el upgrade, sino en verificar que el entorno completo funciona después de él. Para equipos que operan Kubernetes con sistemas de IA encima, las pruebas de upgrade deben incluir que las cargas Wasm y los componentes de observabilidad siguen funcionando correctamente con la nueva versión.

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 donde ya no necesita revoluciones; necesita pulir lo que tiene y eliminar aristas. 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: 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.