Kubernetes 1.37: nuevas funciones y cambios en beta y estable

Kubernetes 1.37: funciones estables (GA)

1. La Metrics API llega a estable

Grupo responsable: 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 pasa a estable.

No hay ningún cambio funcional. Tanto v1 como v1beta1 siguen funcionando, así que no necesitas cambiar nada por ahora. Pero si estás creando 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

Antes de esto, 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 te permiten definir requests/limits de CPU, memoria y hugepages a nivel del pod en lugar de (o junto con) el 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

Así, todos los contenedores del pod pueden compartir el mismo pool de recursos en lugar de que cada uno tenga su propia asignación fija. Esto reduce los recursos desperdiciados y funciona mejor para workloads multicontenedor con picos de uso de recursos.

3. DRA: taints y tolerations de dispositivos

Grupo responsable: SIG Scheduling | KEP: KEP-5055

Esto 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 impide 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 añadir 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

Grupo responsable: SIG Autoscaling | KEP: KEP-4951

El Horizontal Pod Autoscaler (HPA) siempre usó una tolerancia fija del 10% en todo el clúster para evitar escalar por pequeños cambios 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 función ya estable, puedes definir una tolerancia personalizada para cada HPA, con valores separados para escalar hacia arriba y hacia abajo bajo spec.behavior.scaleUp y spec.behavior.scaleDown. Así, cada workload escala de forma más adecuada sin cambiar el valor predeterminado de todo el clúster.

5. Certificados para pods

Grupo responsable: 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.

Esto facilita configurar mTLS de forma nativa (incluso con herramientas de terceros como HashiCorp Vault), sin los sidecars adicionales ni el andamiaje de webhooks que usan hoy muchas service meshes.

6. Salida KYAML para kubectl

Grupo responsable: SIG CLI | KEP: KEP-5295

KYAML es un subconjunto de YAML más estricto y al estilo de Kubernetes: llaves para mapas, corchetes para listas, comillas dobles para strings. Sigue permitiendo comentarios y comas finales, pero elimina las trampas clásicas de YAML, como que un valor se interprete en silencio como el booleano 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)

Grupo responsable: SIG Storage | KEP: KEP-1710

En nodos con SELinux habilitado, Kubernetes reetiquetaba 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 tardar minutos.

SELinuxMount pasa 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 mismo montaje solo puede llevar un contexto SELinux. Si actualmente tienes pods con distintas etiquetas SELinux compartiendo el mismo volumen en el mismo nodo (algo que funcionaba bien con el reetiquetado recursivo anterior), esos pods ahora podrían fallar al arrancar. Si necesitas ese comportamiento anterior para un workload específico, define seLinuxChangePolicy: Recursive en la spec del pod. Los clústeres sin SELinux habilitado no ven ningún cambio.

Funciones beta de Kubernetes 1.37

8. Kubelet en user namespace (modo rootless)

Grupo responsable: 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 in UserNS ejecuta el kubelet dentro de un user namespace de Linux. Dentro del namespace sigue apareciendo como root, pero en el host real está mapeado a un usuario sin privilegios. Esta función pasa a beta en Kubernetes v1.37 y añade una capa extra de aislamiento sin cambiar la forma en que usas el kubelet en el día a día.

9. Escalado a/desde cero en el HPA para métricas de objeto y externas

Grupo responsable: SIG Autoscaling | KEP: KEP-2021

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

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

10. Serializador CBOR

Grupo responsable: SIG API Machinery | KEP: KEP-4222

Los recursos integrados de Kubernetes usan Protobuf para mantener rápidas las llamadas a la API, pero los CRD no pueden usar Protobuf fácilmente porque requiere generación de código en tiempo de compilación. CBOR es un formato binario que no tiene 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.

Funciones alpha de Kubernetes 1.37

Estas funciones están en 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

Grupo responsable: SIG Storage | KEP: KEP-1432

Actualmente, 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 hay una señal estructurada sobre la que actuar. Esto introduce cuatro nuevas RPC 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 específico; un monitor de salud del lado del controlador los consulta periódicamente 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 de ese nodo. Esto les da a los controladores de remediación información legible por máquinas sobre la cual actuar, en lugar de cruzar a mano los dashboards de cada proveedor.

12. ulimits por contenedor

Grupo responsable: 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 cambiar la configuración del host.

Kubernetes v1.37 añade un campo ulimits a Container.SecurityContext. El kubelet pasa estos límites al runtime de contenedores. Por ahora, esta función 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

Grupo responsable: SIG Scheduling | KEP: KEP-6080

DRA ya puede emparejar dispositivos por atributos compartidos, pero solo si los distintos fabricantes de hardware usan el mismo nombre de atributo, algo que normalmente no ocurre. Supón 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 el ID de un nodo NUMA, con la que el scheduler puede hacer coincidencias. Así puedes emparejar GPU y NIC en el mismo nodo NUMA sin esperar a que todos los fabricantes acuerden un esquema de nombres.

Esto está en 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.