Kubernetes 1.37: cambios y requisitos previos

Por qué revisar la versión antes de adoptar funciones

Kubernetes 1.37 incorpora cambios de seguridad, escalado y compatibilidad con nodos. Al consultar las páginas oficiales el 18 de octubre de 2026, el historial de releases aún muestra 1.37.1 (publicado el 15 de septiembre) como último parche; el calendario de parches lista 1.37.2 como el próximo, con fecha objetivo del 13 de octubre, ya pasada. Una fecha objetivo no confirma que el paquete se haya publicado: verifica la release y el canal de tu distribución antes de planificar. Kubernetes mantiene activas las ramas 1.35, 1.36 y 1.37; la distribución puede tener su propio ciclo, parches y secuencia de actualización.

Si operas 1.34, el fin de soporte upstream está fijado para el 27 de octubre de 2026. La fecha no apaga el clúster, pero sí cierra el mantenimiento de esa rama. Consulta también esta guía de planificación de actualización desde Kubernetes 1.34.

La API de métricas llega a estable; valida qué versiones sirve tu adaptador

En Kubernetes 1.37, metrics.k8s.io/v1 pasa a estable. Conserva los mismos tipos y campos que metrics.k8s.io/v1beta1; la promoción cambia las garantías de compatibilidad, no los valores de CPU y memoria. La API la sirve una implementación agregada, como metrics-server; no queda habilitada solo por actualizar el control plane.

La guía oficial de la release indica que kubectl top prefierev1 cuando está disponible y puede usar v1beta1como alternativa. En 1.37, el controlador HPA todavía consumev1beta1. Durante la transición, conserva ambas versiones si tu implementación lo permite y comprueba que las herramientas de observabilidad y autoscaling realmente pueden consultarlas. Esta API solo cubre métricas de recursos CPU y memoria; no sustituye la monitorización completa ni la API de métricas personalizadas.

# Lista las versiones de métricas que publica la implementación agregada.
kubectl get --raw /apis/metrics.k8s.io/

# Confirma que el APIService estable está registrado y disponible.
kubectl get apiservice v1.metrics.k8s.io

# Consulta métricas de nodos por la API estable.
kubectl get --raw /apis/metrics.k8s.io/v1/nodes

Estos comandos son consultas de solo lectura y requieren permisos para acceder a la API. La ausencia del APIService v1.metrics.k8s.iono demuestra por sí sola que todo autoscaling esté roto: identifica qué versión sirve el adaptador y valida por separado el HPA que dependa de esas métricas. No cambies la versión servida sin revisar compatibilidad con clientes y herramientas del clúster.

1. Certificados de Pods estables, con un firmante que debes operar

En 1.37, podCertificate y clusterTrustBundle pasan a Stable. El kubelet puede proyectar al Pod una clave privada y su cadena de certificados, renovarlas y actualizar el archivo de anclas de confianza. La aplicación debe volver a leer los archivos cuando cambian; una biblioteca que solo carga el certificado al arrancar no aprovecha la rotación.

Stable no significa que Kubernetes incluya un emisor listo para tu organización. Debes instalar u operar un controlador firmante y definir qué identidad puede solicitar cada certificado. Antes de adoptarlo, revisa el modelo de autorización del firmante, duración y usos del certificado, selección de anclas y comportamiento de recarga de la aplicación. No reemplaces credenciales actuales hasta probar renovación y revocación en un entorno controlado.

2. HPA puede escalar a cero; no todos los servicios deben hacerlo

La función HPAScaleToZero está en Beta y habilitada por defecto en 1.37. Un HPA puede bajar un Deployment a cero y volver a subirlo usando métricas de objeto o externas, por ejemplo la cantidad de trabajo en una cola. CPU y memoria no bastan: cuando ya no hay Pods, esas métricas de recursos dejan de ofrecer la señal para despertar el workload.

Es una opción para consumidores de colas o trabajos por lotes que puedan tolerar el arranque en frío. Un Service de Kubernetes no almacena solicitudes mientras no haya Pods listos; una aplicación HTTP suele necesitar una capa de cola o buffering. También necesitas que el adaptador de métricas siga entregando la señal cuando el Deployment está en cero.

# Comprueba si la API de métricas externas entrega la señal esperada.
kubectl get --raw '/apis/external.metrics.k8s.io/v1beta1/namespaces/default/queue_consumer_lag?labelSelector=name%3Dworker_tasks'

# Revisa el estado y las condiciones que reporta el HPA.
kubectl describe hpa queue-worker -n default

Son ejemplos de lectura; ajusta namespace, métrica y nombre al entorno. La documentación también aclara que debes iniciar el Deployment con al menos una réplica: fijarlo manualmente en cero lo deja pausado. Antes de desactivar la función o volver a una versión anterior, eleva el mínimo del HPA a 1 o más y escala a 1 o más réplicas cualquier workload que ya esté en cero.

3. Comprueba cgroups antes de actualizar los nodos

Esta condición no es una novedad de Kubernetes 1.37. Desde Kubernetes 1.35, failCgroupV1 tiene valor predeterminadotrue. En consecuencia, el kubelet falla al iniciar en nodos que todavía usan cgroup v1, salvo que se aplique una excepción explícita y temporal. Kubernetes recomienda migrar a cgroup v2, y capacidades como Memory QoS requieren cgroup v2.

Haz el inventario nodo por nodo, incluyendo sistema operativo, kernel, runtime de contenedores y método de aprovisionamiento. En cada nodo Linux puedes consultar el tipo de sistema de archivos de la jerarquía:

stat -fc '%T' /sys/fs/cgroup

Conserva la salida dentro del registro operativo y confírmala con la documentación de la distribución y del runtime. No apliques un override en producción como sustituto de un plan de migración.

4. Revisa los manifiestos de Pods estáticos

En 1.37 ya no se permiten referencias de Pods estáticos a Secrets o ConfigMaps mediante campos como secretRef o configMapRef. Si tu plataforma usa Pods estáticos, revisa sus manifiestos con el procedimiento de esa distribución y busca dependencias en recursos de la API antes de actualizar. La ubicación de los archivos puede variar; no asumas que todos los clústeres usan la ruta de kubeadm.

Lista breve para una actualización controlada

1. Registra versiones de control plane, nodos, distribución y runtime.
2. Confirma la ruta admitida por el proveedor y la política de desfase entre componentes.
3. Identifica nodos con cgroup v1 y resuelve la migración antes de actualizar kubelet.
4. Revisa Pods estáticos, APIs retiradas, CNI, CSI, operadores y webhooks.
5. Prueba métricas externas y recuperación para cada HPA que pueda llegar a cero.
6. Ensaya firmante, autorización y rotación de certificados fuera de producción.
7. Respalda el estado dentro del alcance y confirma una restauración antes de la ventana.
8. Define criterios de pausa, validaciones de servicio y responsables de reversión.

Para diagnóstico general, comienza por los comandos de lectura descritos en la guía de probes de Kubernetes y delimita cualquier cambio con el responsable de la plataforma. No compartas kubeconfigs, certificados privados, tokens ni salidas que identifiquen tu organización.

Convierte la versión en una decisión operable

El número de versión por sí solo no demuestra compatibilidad ni prepara una reversión. Valida los requisitos de tus nodos, distribución, cargas y dependencias; luego prueba el procedimiento con datos y servicios que puedas recuperar.

Elaine System publica servicios de infraestructura Linux y Kubernetes. El alcance de una revisión se define después de conocer el entorno y las restricciones del proyecto.