Saltar al contenido

Kubernetes 1.37 «Garhwal» · 26 de agosto de 2026

Novedades de Kubernetes 1.37, en español

Ordenadas por lo que te toca revisar antes, no por lo que suena mejor: primero lo que puede romperte una actualización, después lo que ya puedes usar en producción, y al final lo que deja de funcionar.

El release en cifras

67KEPs: 16 GA · 23 beta · 27 alfa
1.224issues y PR cerradas
3.7etcd por defecto
1.14.6CoreDNS
1.26.5Go

Fuentes de las cifras: el anuncio oficial (67 enhancements, más una deprecación) y el milestone v1.37.

Lo que puede romperte la actualización

Estable

SELinuxMount llega a GA y puede impedir que arranquen Pods

KEP-1710 · SELinuxMount · SIG Storage

Qué era

Los volúmenes se reetiquetaban recursivamente. Varios Pods con etiquetas SELinux distintas podían compartir un volumen en el mismo nodo sin problema.

Qué cambia

Ahora se montan con -o context=<label>, y un montaje solo admite un contexto. Esos Pods que antes convivían pueden dejar de arrancar. Solo aplica cuando el driver CSI lo declara:

apiVersion: storage.k8s.io/v1
kind: CSIDriver
spec:
  seLinuxMount: true

A quién afecta

A quien tenga SELinux activo. Si tu clúster no usa SELinux, no te afecta en absoluto.

La salida

Conservar el comportamiento anterior, carga por carga:

kind: Pod
spec:
  securityContext:
    seLinuxChangePolicy: Recursive

Es una excepción por carga, no un ajuste global. Sirve para ganar tiempo, no para quedarse. Y si necesitas frenar en seco: el feature gate SELinuxMount aún se puede desactivar a nivel de clúster durante una versión más — no queda bloqueado hasta la 1.38.

Deprecado

cgroup v1: el kubelet ya no arranca

KEP-5573 · SIG Node

Qué era

cgroup v1 funcionaba sin más.

Qué cambia

Nada en 1.37. Pero desde 1.35, failCgroupV1 vale true por defecto, así que el kubelet no llega a inicializarse en un nodo que siga en cgroup v1.

A quién afecta

A quien siga en cgroup v1 y necesite arrancar el kubelet hoy. El override es un campo de primer nivel de KubeletConfiguration, no un feature gate:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false   # parche temporal

Lo que pierdes

Las capacidades avanzadas de gestión de recursos — Memory QoS, el redimensionado en caliente de volúmenes en memoria — solo funcionan con cgroup v2. Es un parche, no una solución: la retirada de cgroup v1 está planificada para una versión futura.

Beta

Workload y PodGroup promocionan a v1beta1: borra los objetos v1alpha2 antes de actualizar

Workload-Aware Scheduling · SIG Scheduling

Qué era

Las APIs de scheduling por grupos (Workload, PodGroup) estaban en scheduling.k8s.io/v1alpha2.

Qué cambia

Pasan a v1beta1. La versión alfa desaparece y el api-server no migra los objetos por ti.

A quién afecta

Solo a quien probara la v1alpha2 en 1.36. En ese caso, hay que eliminar todos los objetos v1alpha2 del api-server antes de subir de 1.36 a 1.37. Si no la usaste, no hay nada que hacer.

Deprecado

El kubelet no arranca con flags antiguos de cAdvisor

SIG Node

Qué era

El kubelet aceptaba una colección de flags heredados de cAdvisor, deprecados desde hace años.

Qué cambia

Si alguno sigue en la configuración, el kubelet falla al arrancar: --containerd, --event-storage-age-limit, --global-housekeeping-interval, los --storage-driver-*… Solo sobrevive --housekeeping-interval. También desaparecen de /metrics/cadvisor las series container_cpu_load_average_10s y container_tasks_state.

A quién afecta

A quien arrastre configuración de kubelet de hace años, y a quien tenga dashboards o alertas sobre esas métricas. Revisa los flags de los nodos antes de actualizar.

Lo que ya puedes usar

Estable

La Metrics API llega a v1 tras casi nueve años en beta

KEP-5207 · metrics.k8s.io · SIG Instrumentation

Qué era

metrics.k8s.io/v1beta1, en beta desde la 1.8.

Qué cambia

Llega a v1. Sin cambios funcionales, y v1beta1 sigue sirviendo durante la transición, así que se puede adoptar al ritmo de cada uno.

A quién afecta

A todo el mundo, aunque no se note: es la API que hay debajo de kubectl top y del HorizontalPodAutoscaler.

Estable

Pedir una GPU con DRA vuelve a ser una línea

KEP-5004 · DRA · recursos extendidos · SIG Scheduling

Qué era

Repartir dispositivos con Dynamic Resource Allocation obligaba a declarar ResourceClaims.

Qué cambia

Los recursos extendidos sobre DRA llegan a GA: un nombre como example.com/gpu se asigna a una DeviceClass, se pide con la sintaxis clásica de resources, y el driver lo resuelve por debajo. Graduan también los taints/tolerations de dispositivos (KEP-5055) y el estado por dispositivo en el ResourceClaim (KEP-4817), que por fin expone cosas como la IP de una interfaz de red asignada por DRA.

A quién afecta

A quien reparta GPUs o aceleradores entre varios Pods.

Estable

Certificados de identidad por Pod, sin montar Secrets

KEP-4317 · KEP-3257 · SIG Auth

Qué era

Utilizar certificados X.509 era un proceso "manual": Secrets montados, controladores externos y rotaciones que alguien tenía que vigilar.

Qué cambia

PodCertificateRequest y ClusterTrustBundle llegan a GA. Un controlador firmante emite y rota los certificados de cada Pod; él los recibe con un volumen proyectado podCertificate, y las anclas de confianza para verificarlos, con otro clusterTrustBundle.

A quién afecta

A quien haga mTLS entre servicios o necesite identidad de carga verificable sin depender de herramientas externas.

Estable

KYAML: la salida de kubectl sin los problemas de YAML

KEP-5295 · SIG CLI

Qué era

YAML clásico, con sus sorpresas: el problema de Noruega (no se convierte en false), números que se vuelven strings, sangrado significativo que se rompe al copiar.

Qué cambia

kubectl get -o kyaml llega a estable. Es un dialecto de YAML con llaves y comillas explícitas, pensado para copiar y pegar sin sustos. No lo estrena la 1.37: alfa en la 1.34, disponible por defecto desde la 1.35.

A quién afecta

A quien copia manifests de un sitio a otro o los genera con scripts. Es de esos cambios pequeños que se agradecen cada día.

Beta

El HPA ya puede escalar a cero

KEP-2021 · SIG Autoscaling

Qué era

Un HorizontalPodAutoscaler no podía bajar de una réplica: las cargas ociosas seguían consumiendo, y apagarlas era cosa tuya.

Qué cambia

Con minReplicas: 0, el HPA lleva a 0 las réplicas y las recupera cuando vuelve la demanda. Solo con métricas object o external: con CPU y memoria no puede, porque dependen de que haya Pods en ejecución. Llega a beta, activado por defecto, tras estrenarse en la 1.16.

A quién afecta

A consumidores de colas, trabajos batch y cargas con GPU: todo lo que pasa horas esperando trabajo.

Beta

Gang scheduling: o cabe el grupo entero, o nada

KEP-4671 · SIG Scheduling

Qué era

El scheduler colocaba los Pods de uno en uno. En un entrenamiento distribuido con decenas de Pods acoplados, la mitad arrancaba y la otra mitad se quedaba Pending: recursos bloqueados sin que nadie avance.

Qué cambia

Sobre las APIs de Workload y PodGroup, el grupo se programa todo o nada: solo si el clúster puede acomodar el conjunto completo. Con preemption consciente del workload, para no desalojar Pods sueltos que no liberan capacidad útil.

A quién afecta

A quien ejecute entrenamiento de ML distribuido o HPC sobre Kubernetes.

Beta

El kubelet deja de necesitar root en el host

KEP-2033 · SIG Node

Qué era

Los componentes de nodo se ejecutaban con privilegios de root en la máquina.

Qué cambia

Pueden correr dentro de un user namespace de Linux: usuario sin privilegios en el host, root dentro del namespace. Una capa más de aislamiento si aparece una vulnerabilidad en un componente de nodo.

A quién afecta

A quien tenga la superficie de ataque del nodo como una preocupación real. Es beta: todavía no para producción sin pruebas.

Lo que deja de funcionar

  • kube-proxy en modo ipvs sigue camino de desaparecer. Está deprecado desde 1.35, y desde entonces avisa al arrancar. Lo nuevo en 1.37 es el feature gate KubeProxyIPVS: el interruptor con el que se desactivará por defecto en 1.40 y se eliminará en 1.43 (KEP-5495). El destino es nftables. Para saber en qué modo estás: 
    kubectl -n kube-system get configmap kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep 'mode:'
  • kube-dns entra en deprecación. CoreDNS es el DNS por defecto desde la 1.13 y kube-dns se quedó atrás hace años: ni EndpointSlices ni dual-stack. El proyecto está retirado y no se esperan paquetes nuevos después de la 1.40. Si aún lo ejecutas, planifica la migración a CoreDNS.
  • Los Pods estáticos ya no pueden referenciar Secrets ni ConfigMaps. Era un bug que les permitía leer recursos de la API mediante configMapRef o secretRef. Ahora queda prohibido, y el feature gate que permitía optar por el comportamiento antiguo ha desaparecido.
  • kubectl run --filename / -f queda deprecado. El Pod generado siempre se construye a partir de los argumentos de la línea de comandos.

Cómo comprobar tu clúster antes de actualizar

# En qué versión estás
kubectl version

# Qué drivers CSI activan el montaje SELinux (el riesgo n.º 1)
kubectl get csidriver \
  -o custom-columns=NAME:.metadata.name,SELINUXMOUNT:.spec.seLinuxMount

# En cada nodo: versión de cgroup (cgroup2fs = v2 · tmpfs = v1)
stat -fc %T /sys/fs/cgroup

# ¿Sirves la v1alpha2 de scheduling? Borra sus objetos antes de subir
kubectl api-versions | grep scheduling.k8s.io

# El estado real de un feature gate concreto
kubectl get --raw /metrics | grep kubernetes_feature_enabled

# En qué modo corre kube-proxy
kubectl -n kube-system get configmap kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep 'mode:'

Este es el nivel de detalle del libro

Kubernetes 101 es la guía en español para entender Kubernetes desde cero, y sale con esta misma versión: la 1.37 se publicó el 26 de agosto y el libro llega el 1 de septiembre. El apéndice C — «Desde cuándo funciona cada pieza» — recoge, capítulo a capítulo, en qué estado está cada funcionalidad y desde qué versión, para que puedas comprobar de un vistazo si lo que lees sigue vigente en tu clúster.

Reservar en Kindle · 12,99 € Leer gratis el arranque del libro

365 páginas · 15 capítulos · 55 laboratorios en un clúster real

Fuentes