Kubernetes 1.37: nuevas funcionalidades y cambios en beta y estable

Kubernetes 1.37: funcionalidades estables (GA)

1. La Metrics API se gradúa

Feature Group: SIG Instrumentation | KEP: KEP-5207

La API metrics.k8s.io llevaba años en beta. Es la API detrás de kubectl top y de las métricas de CPU y memoria del Horizontal Pod Autoscaler. En v1.37 por fin se gradúa a estable.

Aquí no hay cambios funcionales. Tanto v1 como v1beta1 siguen funcionando, así que no necesitas cambiar nada por ahora. Pero si desarrollas herramientas que usan esta API, ya puedes usar v1 con confianza, porque es estable y no cambiará de forma inesperada.

2. Recursos a nivel de pod

Hasta ahora, había que definir requests y limits de recursos para cada contenedor de un pod, incluso si los contenedores estaban pensados para trabajar juntos.

Los recursos a nivel de pod permiten definir requests/limits de CPU, memoria y hugepages a nivel del pod, en lugar de (o además de) hacerlo a nivel de contenedor.

spec:
  resources:
    requests:
      cpu: "1"
      memory: "512Mi"
    limits:
      cpu: "2"
      memory: "1Gi"
  containers:
  - name: app
    image: my-app
  - name: sidecar
    image: my-sidecar

Todos los contenedores del pod pueden así compartir el mismo pool de recursos en lugar de tener cada uno su propia asignación fija. Esto reduce la pérdida de recursos y funciona mejor para workloads multi-contenedor con picos de consumo.

3. DRA: taints y tolerations de dispositivos

Feature Group: SIG Scheduling | KEP: KEP-5055

Esta funcionalidad lleva el modelo de taints de nodos a Dynamic Resource Allocation (DRA). Los drivers de DRA, o una DeviceTaintRule que escribas tú mismo, pueden aplicar un taint a un dispositivo específico (por ejemplo, una GPU que se está sobrecalentando o que se está drenando por mantenimiento).

Un taint NoSchedule evita que nuevos pods usen ese dispositivo, mientras que un taint NoExecute expulsa a los pods que ya lo están usando. Si un workload aún necesita usar el dispositivo, puede agregar una toleration correspondiente en su ResourceClaim.

Esto te permite aislar una sola GPU o NIC en lugar de acordonar el nodo completo.

4. Tolerancia configurable en el HPA

Feature Group: SIG Autoscaling | KEP: KEP-4951

El Horizontal Pod Autoscaler (HPA) siempre usó una tolerancia fija del 10% para todo el clúster, con el fin de evitar escalar por pequeñas variaciones en las métricas. Pero ese mismo 10% no tiene sentido para todos los workloads. Un cambio del 10% en un workload con 500 pods es muy distinto a uno con 5 pods.

Con esta funcionalidad ya estable, puedes definir una tolerancia personalizada para cada HPA, con valores separados para escalar hacia arriba y hacia abajo en spec.behavior.scaleUp y spec.behavior.scaleDown. Así, cada workload escala de forma más adecuada sin modificar el valor por defecto de todo el clúster.

5. Certificados para pods

Feature Group: SIG Auth | KEP: KEP-4317

Esto les da a los pods una forma nativa de obtener certificados X.509 de corta duración sin pasar por bearer tokens. Una nueva API PodCertificateRequest se encarga de la emisión, y un volumen proyectado PodCertificate permite que el kubelet entregue la clave y el certificado directamente al pod, con rotación automática.

Así resulta más fácil configurar mTLS de forma nativa (incluso con herramientas de terceros como HashiCorp Vault), sin el sidecar extra ni la maraña de webhooks que hoy usan muchos service meshes.

6. Salida KYAML para kubectl

Feature Group: SIG CLI | KEP: KEP-5295

KYAML es un subconjunto de YAML más estricto, al estilo de Kubernetes: llaves para mapas, corchetes para listas, comillas dobles para strings. Sigue permitiendo comentarios y comas finales, pero elimina las clásicas trampas de YAML, como interpretar silenciosamente un valor como boolean false (el "problema de Noruega").

Ahora es una opción de salida estable en kubectl, así que puedes generar manifiestos en este formato sin preocuparte de que una conversión de tipos accidental rompa tu configuración.

7. Cambio recursivo de etiquetas SELinux más rápido (SELinuxMount)

Feature Group: SIG Storage | KEP: KEP-1710

En nodos con SELinux habilitado, Kubernetes solía reetiquetar cada archivo de un volumen uno por uno antes de que un pod pudiera arrancar. En un volumen con millones de archivos, solo eso podía tomar minutos.

SELinuxMount se gradúa a GA y viene habilitado por defecto en v1.37. En lugar de reetiquetar archivo por archivo, los volúmenes se montan con -o context=<label>; todo el volumen recibe la etiqueta correcta en una sola operación de montaje. Esto solo se activa cuando el driver CSI del volumen lo habilita mediante CSIDriver.spec.seLinuxMount: true.

Algo importante a tener en cuenta: un solo montaje solo puede llevar un contexto SELinux. Si hoy tienes pods con etiquetas SELinux distintas compartiendo el mismo volumen en el mismo nodo (algo que funcionaba bien con el antiguo reetiquetado recursivo), esos pods podrían dejar de arrancar. Si necesitas el comportamiento anterior para un workload específico, define seLinuxChangePolicy: Recursive en la spec del pod. Los clústeres sin SELinux habilitado no verán ningún cambio.

Funcionalidades beta de Kubernetes 1.37

8. Kubelet en un user namespace (modo rootless)

Feature Group: SIG Node | KEP: KEP-2033

Los componentes del nodo, como el kubelet, normalmente se ejecutan como root en el host. Si el kubelet se ve comprometido, un atacante podría obtener acceso root al nodo.

Kubelet en UserNS ejecuta el kubelet dentro de un user namespace de Linux. Dentro del namespace sigue apareciendo como root, pero en el host real se mapea a un usuario sin privilegios. Esta funcionalidad pasa a beta en Kubernetes v1.37 y agrega una capa extra de aislamiento sin cambiar la forma en que usas el kubelet en el día a día.

9. HPA: escalar a/desde cero con métricas de objeto y externas

Feature Group: SIG Autoscaling | KEP: KEP-2021

El Horizontal Pod Autoscaler (HPA) ya podía escalar a cero réplicas usando métricas de objeto o externas desde hace un tiempo. Pero no había una forma sencilla de saber si fue el HPA quien escaló un workload a cero o si alguien lo puso en cero de otra manera.

Kubernetes v1.37 agrega una condición de estado ScaledToZero al objeto HPA, dejando clara esa diferencia. Es especialmente útil para workloads basados en eventos, como los que usan la profundidad de una cola o disparadores al estilo KEDA, que se reducen a cero cuando están inactivos y vuelven a escalar cuando llega trabajo nuevo.

10. Serializador CBOR

Feature Group: SIG API Machinery | KEP: KEP-4222

Los recursos integrados de Kubernetes usan Protobuf para mantener rápidas las llamadas a la API, pero los CRDs no pueden usar Protobuf fácilmente, ya que requiere generación de código en tiempo de compilación. CBOR es un formato binario sin ese requisito, y los primeros benchmarks muestran una codificación hasta 8 veces más rápida y una decodificación 2 veces más rápida para recursos personalizados en comparación con JSON. Los clientes lo negocian automáticamente y recurren a JSON con servidores de API más antiguos, así que el despliegue es seguro.

Funcionalidades alpha de Kubernetes 1.37

Estas son alpha: no están listas para producción, pero vale la pena probarlas en un clúster de staging.

11. Monitor de salud de volúmenes

Feature Group: SIG Storage | KEP: KEP-1432

Hoy en día, si un volumen CSI tiene un problema a nivel de almacenamiento, normalmente solo te enteras por un montaje fallido o un bloqueo de I/O; no existe una señal estructurada sobre la cual actuar. Esta funcionalidad introduce cuatro nuevas RPCs de CSI para que los drivers puedan reportar la salud de los volúmenes de una forma que los controladores puedan aprovechar. Del lado del controlador, ControllerListVolumeHealth lista los volúmenes con problemas y ControllerGetVolumeHealth revisa uno en específico; un monitor de salud del lado del controlador consulta estas RPCs y escribe el resultado en PersistentVolumeClaim.status.healthStatus. Del lado del nodo, el kubelet llama a NodeGetVolumeHealth para volúmenes individuales (registrado en Pod.status.volumeHealth) y a NodeGetStorageHealth para conocer la salud de los drivers en ese nodo. Esto les da a los controladores de remediación información legible por máquina sobre la cual actuar, en lugar de cruzar a mano los dashboards de cada proveedor.

12. ulimits por contenedor

Feature Group: SIG Node | KEP: KEP-5758

Algunas aplicaciones, como las bases de datos y las aplicaciones de alta concurrencia, necesitan límites POSIX más altos —como el número máximo de archivos abiertos o de procesos— que los que el runtime de contenedores ofrece por defecto. Hasta ahora, las opciones habituales eran scripts de entrypoint personalizados o modificar la configuración del host.

Kubernetes v1.37 agrega un campo ulimits a Container.SecurityContext. El kubelet pasa estos límites al runtime de contenedores. Por ahora, esta funcionalidad solo funciona con el perfil Privileged de los Pod Security Standards, y Kubernetes verifica el soporte del nodo antes de programar el pod, para que no termine en un nodo que no pueda aplicar los límites requeridos.

13. DRA: atributos derivados

Feature Group: SIG Scheduling | KEP: KEP-6080

DRA ya puede emparejar dispositivos según atributos compartidos, pero solo si los distintos fabricantes de hardware usan el mismo nombre de atributo, lo cual normalmente no ocurre. Supongamos que quieres una GPU y una NIC rápida en el mismo nodo NUMA: el scheduler necesita nombres y valores de atributos coincidentes, pero cada fabricante describe la topología a su manera.

Los atributos derivados te permiten escribir una expresión CEL en tu solicitud de dispositivo que construye un atributo virtual a partir de lo que el driver ya expone. Eso te da una clave común, como un ID de nodo NUMA, que el scheduler puede usar para el emparejamiento. Así puedes combinar GPUs y NICs en el mismo nodo NUMA sin esperar a que todos los fabricantes se pongan de acuerdo en un esquema de nombres.

Esto es alpha y la API todavía está tomando forma, así que pruébalo en un clúster de staging y revisa el KEP para conocer los campos exactos antes de usarlo.