Kubernetes 1.35 GA: balance desde la operación

Actualizado: 2026-05-03

Kubernetes 1.35 alcanza GA en junio de 2026, consolidando trabajo que atraviesa 1.33, 1.34 y ahora 1.35. Tras migrar varios clusters en staging durante las últimas semanas, estos son los puntos que importan a operadores.

Puntos clave

• Los contenedores sidecar nativos están completamente GA, con lifecycle management pulido que elimina las racing conditions del patrón initContainer clásico.
• Dynamic Resource Allocation (DRA) pasa de experimental a disponible para casos no-GPU (FPGAs, NPUs, aceleradores custom).
• El nuevo “dynamic scoring” del scheduler reduce el desperdicio de recursos en clusters heterogéneos un 15-25 % en pruebas.
• Tres elementos requieren revisión antes de migrar producción: cambios sutiles de API en features alpha, comportamiento de StatefulSets con volumes, y métricas del scheduler renombradas.
• La estrategia recomendada: canary en staging dos semanas, luego un nodo en producción, observar una semana, escalar.

Contenedores sidecar completamente GA

El soporte nativo de contenedores sidecar, que llegó a beta en 1.28 y estable en 1.33, está ya GA con lifecycle management pulido. Permite:

• Arrancar sidecars antes que el contenedor principal.
• Esperar a que estén listos (readiness probes respetadas).
• Terminarlos después de que el contenedor principal finalice.

Esto es un cambio grande frente al patrón clásico con contenedores init y racing conditions. El caso de uso típico que se beneficia más: service mesh con sidecar de proxy (Envoy, Linkerd), que ahora arranca sin trucos de ordering en initContainers.

# Kubernetes 1.35: sidecar nativo
spec:
  initContainers:
  - name: proxy-sidecar
    image: envoy:v1.29
    restartPolicy: Always  # esto lo convierte en sidecar, no en init
  containers:
  - name: app
    image: myapp:latest

El campo restartPolicy: Always en un initContainer es la señal que Kubernetes 1.35 usa para tratarlo como sidecar con el lifecycle completo.

Dynamic Resource Allocation (DRA) generalizada

DRA ha pasado de experimental a disponible para casos no-GPU:

• FPGAs: asignación declarativa de FPGAs Intel o Xilinx.
• NPUs: aceleradores de inferencia como el Apple Neural Engine o equivalentes de terceros.
• Aceleradores custom: cualquier hardware que exponga un driver DRA puede ahora integrarse con la misma API declarativa que otros recursos.

Las cargas que necesitan recursos especializados se asignan ya con la misma API declarativa que otros recursos:

spec:
  resourceClaims:
  - name: fpga-claim
    resourceClaimTemplateName: fpga-template
  containers:
  - name: inference
    resources:
      claims:
      - name: fpga-claim

El ecosistema de device plugins existente sigue funcionando, pero DRA simplifica considerablemente el desarrollo de nuevos plugins para hardware especializado.

Mejoras del scheduler

El scheduler gestiona mejor cargas mixtas con el nuevo “dynamic scoring”. En clusters con nodos heterogéneos (nodos CPU-only, nodos GPU, nodos con alta memoria), el scoring dinámico distribuye trabajo más eficientemente sin requerir taints/tolerations manuales para cada combinación de workload.

Resultados en pruebas:

• Reducción del 15-25 % de desperdicio de recursos (CPU o memoria no usada en nodos donde el workload no encaja bien) en clusters mixtos.
• Menor fragmentación: el scheduler empaqueta workloads más densamente cuando es posible, liberando nodos completos para scale-down.

Esta mejora es transparente para la mayoría de workloads — no requiere cambios en los manifiestos de los Pods.

Cambios a vigilar antes de migrar

Tres elementos que requieren revisión antes de actualizar producción:

Cambios de API en features alpha: algunas features que estaban en alpha en 1.33-1.34 y han cambiado de API sutilmente al promoverse a beta en 1.35. Revisar las release notes para detectar si alguna feature alpha que usabas ha cambiado el schema. Habitualmente afecta a feature gates que se activan explícitamente.

Comportamiento de StatefulSets con volumes: algunos edge cases en cómo Kubernetes 1.35 gestiona el fallo de PVC en StatefulSets cambian el orden de los eventos de fallo. Los StatefulSets que dependen de un comportamiento específico de rollback ante fallo de volumen deben testearse explícitamente.

Métricas del scheduler renombradas: el scheduler ha renombrado varias métricas internas para alinearse con el nuevo sistema de scoring. Los dashboards de Grafana que usan métricas de scheduler deben revisarse:

• scheduler_queue_incoming_pods_total → scheduler_queue_incoming_pods_total (sin cambio)
• scheduler_scheduling_duration_seconds → Revisado con nuevas etiquetas de resultado
• Métricas específicas de los plugins de scoring: prefijo cambiado de scheduler_plugin_ a scheduler_score_plugin_

Estrategia de migración recomendada

La estrategia que ha funcionado en staging:

1. Canary en staging durante dos semanas: correr cargas reales de producción sobre el cluster 1.35. Validar sidecars críticos, revisar dashboards de scheduler, confirmar que los StatefulSets se comportan correctamente.
2. Migrar un nodo en producción: actualizar un nodo del nodepool, cordonar los demás, observar durante una semana. Si el scheduler asigna workloads al nodo 1.35 sin incidentes, proceder.
3. Escalar gradualmente: actualizar el resto del nodepool en batches del 20-25 %, con 24 horas de observación entre batches.
4. No migrar toda la flota de una vez: los cambios del scheduler pueden sorprender en casos de workloads específicos con afinidades o anti-afinidades complejas.

Para clusters en 1.30 o anteriores

Para quien todavía está en 1.30 (o versiones anteriores que ya no tienen soporte activo de parches), la estrategia no es un salto directo a 1.35 sino saltos graduales: 1.30 → 1.31 → 1.32 → 1.33 → 1.35. Cada salto de versión tiene sus propias breaking changes y el riesgo acumulado de un salto directo es alto.

Conclusión

Kubernetes 1.35 es una versión de consolidación: no rompe cosas grandes, pero reúne mejoras que juntas justifican la actualización. Para clusters que ya van por 1.33 o 1.34, el upgrade es incremental con valor claro — especialmente en clusters con service mesh (sidecars GA) o hardware especializado (DRA generalizada). Para quien todavía está en 1.30 o antes, conviene plan de saltos graduales, no un salto directo.