Kubernetes v1.37 (Garhwal): todas las novedades y mejoras

TL;DR

Kubernetes v1.37 ("Garhwal") incluye 67 mejoras: 16 estables, 23 en Beta, 27 en Alpha y 1 eliminación. Los cambios más destacados son el redimensionamiento in-place para contenedores init y sidecar (GA), la tolerancia configurable del HPA (GA), node declared features (GA), el escalado a cero para el HorizontalPodAutoscaler (Beta), Memory QoS (Beta), los gestores de recursos a nivel de Pod (Beta), el gang scheduling mediante la nueva Workload API (Beta) y el modo rootless del kubelet (Beta). Entre las novedades en Alpha se incluyen una Eviction Request API cooperativa y el checkpoint/restore a nivel de Pod, además de avances continuos en Dynamic Resource Allocation (DRA). Acción requerida: el etiquetado de montajes SELinux cambia por defecto en esta versión y puede romper workloads existentes en clústeres con SELinux habilitado.

Kubernetes v1.37, también conocida como "Garhwal", trae un sólido conjunto de cambios para los equipos a los que les importan la gestión de recursos, el autoescalado y el scheduling. Esta versión incluye 67 mejoras: 16 ya son estables (GA), 23 pasan a Beta, 27 a Alpha y 1 es una eliminación. El nombre proviene de Garhwal, una región del Himalaya en Uttarakhand, India. El tema gira en torno a capas que se conectan y se apoyan entre sí, desde campos en terrazas hasta arroyos de montaña, algo que encaja con una versión que sigue construyendo sobre el trabajo de las anteriores.

Estas son algunas de las funciones que más nos entusiasman de Kubernetes v1.37: el redimensionamiento in-place para contenedores init y sidecar, el escalado a cero para el HorizontalPodAutoscaler, Memory QoS y el gang scheduling nativo a través de la Workload API. Muchas de ellas hacen que Kubernetes aproveche mejor los recursos, escale según la demanda real y ubique correctamente los workloads estrechamente acoplados.

Estos son los principales cambios de Kubernetes v1.37:

Funciones estables de Kubernetes v1.37

1. Redimensionamiento in-place de Pods para contenedores init y sidecar

Grupo responsable: SIG Node | KEP: #1287

El redimensionamiento in-place de Pods alcanzó el estado estable (GA) en Kubernetes v1.35. En la v1.37, este soporte se extiende a los contenedores init y sidecar, y esa parte ahora también es GA.

Antes de este cambio, se podía redimensionar la CPU y la memoria de un contenedor de aplicación en ejecución sin reiniciarlo, pero los contenedores init y sidecar quedaban fuera. Un contenedor sidecar es un contenedor init con restartPolicy: Always, por lo que se ejecuta durante toda la vida del Pod. Si un sidecar necesitaba más CPU o memoria, la única opción real era recrear el Pod. Eso implicaba downtime también para la aplicación principal, aunque solo el sidecar necesitara el cambio.

Con la v1.37, el feature gate InPlacePodVerticalScalingInitContainers es GA. Puedes cambiar los requests o limits de CPU y memoria de un contenedor sidecar en ejecución, y el kubelet actualiza en caliente la configuración del cgroup del contenedor. El Pod sigue en ejecución. Con resizePolicy controlas qué sucede por recurso: NotRequired significa aplicar el cambio en vivo, y RestartContainer significa reiniciar solo ese contenedor para aplicarlo. La v1.37 también suma dos piezas en Alpha a la misma función: el redimensionamiento in-place de volúmenes emptyDir respaldados por memoria (el gate InPlacePodVerticalScalingMemoryBackedVolumes) y la posibilidad de que el scheduler haga preempción sobre Pods de menor prioridad para hacer espacio a un redimensionamiento diferido (el gate InPlacePodVerticalScalingSchedulerPreemption).

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  initContainers:
  - name: log-shipper        # sidecar
    image: log-shipper:1.0
    restartPolicy: Always
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
  containers:
  - name: app
    image: app:1.0
    # ...

Con esta configuración, puedes aumentar la CPU del sidecar sin ningún reinicio. Aumentar su memoria reinicia solo ese contenedor, nunca el Pod completo.

2. Tolerancia configurable para los HorizontalPodAutoscalers

Grupo responsable: SIG Autoscaling | KEP: #4951

En Kubernetes v1.37, la tolerancia configurable para el HorizontalPodAutoscaler (HPA) alcanzó la disponibilidad general (GA).

El HPA modifica el número de réplicas de Pods según métricas como CPU o memoria. Antes de esta función, el HPA usaba una tolerancia fija del 10 % en todo el clúster: no actuaba hasta que el uso se alejaba más de un 10 % del objetivo. Ese valor único no se ajustaba a todos los workloads. Los servicios sensibles podían reaccionar demasiado lento y, para cambiarlo, había que editar un flag global del controlador que afectaba a todos los HPA del clúster.

Con la v1.37, el feature gate HPAConfigurableTolerance es GA. Puedes definir la tolerancia por HPA y por dirección de escalado en el campo behavior. Una tolerancia ajustada al escalar hacia arriba permite que un servicio crítico reaccione a pequeños aumentos de carga. Una tolerancia más laxa en otros casos mantiene estables los workloads más tranquilos. Esto estaba en Beta en la v1.35 y ahora es el comportamiento estándar.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  behavior:
    scaleUp:
      tolerance: 0.05

La tolerancia es una proporción, no puntos porcentuales. Con 0.05 y un objetivo del 60 %, el HPA escala hacia arriba cuando el uso de CPU supera aproximadamente el 63 % (60 % por 1.05). Eso reacciona antes de lo que permitía la antigua tolerancia fija del 10 %.

3. Node Declared Features

Grupo responsable: SIG Node | KEP: #5328

En Kubernetes v1.37, node declared features alcanzó la disponibilidad general (GA).

Antes de esta función, Kubernetes asumía que un nodo podía manejar cualquier función que el plano de control soportara, siempre que las versiones estuvieran dentro del desfase (skew) soportado. Eso no siempre es cierto. Cuando una nueva función se activaba en el plano de control, el scheduler podía ubicar un Pod que la usara en un nodo más antiguo que aún no la soportaba. El Pod entonces fallaba en tiempo de ejecución o se quedaba atascado después de ser programado, aunque la ubicación pareciera correcta.

Con la v1.37, el feature gate NodeDeclaredFeatures es GA. Ahora cada nodo publica el conjunto de funciones que entiende en el campo status.declaredFeatures del objeto Node. El scheduler y las verificaciones de admisión lo usan para ubicar los Pods que dependen de una función solo en nodos que la soportan. Esto convierte una falla en tiempo de ejecución en una decisión clara de scheduling, algo que importa sobre todo durante las actualizaciones, cuando conviven distintas versiones de nodo. Node declared features estaba en Alpha en la v1.35.

Funciones Beta de Kubernetes v1.37

4. Escalado a cero para los HorizontalPodAutoscalers

Grupo responsable: SIG Autoscaling | KEP: #2021

En Kubernetes v1.37, el escalado a cero para el HorizontalPodAutoscaler pasó a Beta y viene habilitado por defecto.

Antes de esta función, un HPA no podía llevar un workload a cero réplicas. Lo mínimo era una. Para un servicio que solo tiene trabajo de vez en cuando, como un consumidor de colas o un worker de procesos batch, eso significaba pagar por mantener al menos un Pod en ejecución incluso cuando no había nada que hacer.

Con la v1.37, puedes definir spec.minReplicas: 0 en un HPA y dejar que reduzca el workload a cero cuando está inactivo, y que lo vuelva a levantar cuando regresa la demanda. Esto funciona para workloads impulsados por métricas Object o External, como la longitud de una cola. No funciona con métricas de CPU o memoria, porque esas métricas provienen de Pods en ejecución y en cero no hay ninguno. Esto puede reducir costos en consumidores de colas, trabajos batch y workloads de GPU que quedan inactivos entre ejecuciones. Mientras el HPA mantiene un workload en cero, registra una condición ScaledToZero con valor True, de modo que puedes distinguir entre un workload que él mismo escaló a cero y uno que fue apagado a mano. Cuando vuelve a escalar hacia arriba, la condición pasa a False con el motivo NotScaledToZero.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: queue_messages
      target:
        type: AverageValue
        averageValue: "30"

Con esta configuración, el workload baja a cero Pods cuando la cola está vacía, y el HPA lo vuelve a escalar cuando llegan mensajes.

5. Memory QoS

Grupo responsable: SIG Node | KEP: #2570

En Kubernetes v1.37, Memory QoS pasó a Beta.

Antes de esta función, el kubelet fijaba un límite duro de memoria para un contenedor (memory.max del cgroup), pero no le daba al kernel señales más suaves. Un contenedor podía consumir memoria hasta llegar justo a su límite y luego recibir un OOM kill casi sin aviso. Tampoco existía protección de memoria ligada al request del contenedor, así que bajo presión de memoria el kernel podía recuperar páginas de un contenedor que todavía estaba dentro de su request.

Con la v1.37, el feature gate MemoryQoS está en Beta. Usa los controles de memoria de cgroup v2 para darle mejores señales al kernel. El kubelet establece memory.min a partir del request de memoria del contenedor, lo que protege esa cantidad de memoria de la recuperación por parte del kernel. Si defines memoryThrottlingFactor en la configuración del kubelet, este también establece memory.high como umbral de throttling por debajo del límite. El kernel entonces ralentiza el contenedor y recupera páginas antes de que alcance el límite duro y sufra un OOM kill. Por defecto, memoryThrottlingFactor no está definido y memory.high queda desactivado a menos que lo configures. Se requiere cgroup v2, que ya es el único modo soportado desde la v1.35.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9

Con este ajuste, el kubelet establece memory.high para los contenedores por debajo de su límite de memoria, usando el factor 0.9. El kernel recupera memoria y aplica throttling al contenedor antes de que alcance el límite duro, lo que hace menos probables los OOM kills bajo presión.

6. Gestores de recursos a nivel de Pod

Grupo responsable: SIG Node | KEP: #5526

En Kubernetes v1.37, los gestores de recursos a nivel de Pod pasaron a Beta.

Kubernetes v1.34 agregó los recursos a nivel de Pod (KEP #2837), que permiten definir requests y limits de CPU y memoria para todo el Pod en lugar de solo por contenedor. Pero los gestores de recursos del kubelet todavía no entendían esos valores a nivel de Pod. Antes de esta función, el CPU Manager, el Memory Manager y el Topology Manager solo miraban los requests por contenedor. Un Pod que definía sus recursos a nivel de Pod podía quedarse sin el anclaje exclusivo de CPU o la alineación NUMA.

Con la v1.37, el feature gate PodLevelResourceManagers está en Beta. Viene desactivado por defecto en la v1.37: se activó y luego se volvió a desactivar hacia el final del ciclo de la versión, después de que el equipo encontrara problemas críticos, así que debes habilitarlo tú mismo si lo quieres usar. Cuando está activo, el CPU Manager (política estática), el Memory Manager y el Topology Manager tienen en cuenta los recursos a nivel de Pod al asignar CPUs, memoria y localidad de hardware. Esto beneficia a los workloads sensibles a la latencia y de alta exigencia que definen sus recursos a nivel de Pod, para que sigan obteniendo núcleos exclusivos y memoria alineada por NUMA.

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  resources:              # recursos a nivel de Pod
    requests:
      cpu: "2"
      memory: "4Gi"
    limits:
      cpu: "2"
      memory: "4Gi"
  containers:
  - name: app
    image: app:1.0
    # los contenedores pueden definir sus propios recursos o usar los del Pod

Con esta configuración, el Pod es Guaranteed a nivel de Pod, y los gestores del kubelet pueden anclarle CPUs completas y alinear su memoria, incluso cuando el contenedor no define sus propios requests.

7. Gang scheduling con la Workload API

Grupo responsable: SIG Scheduling | KEP: #4671

En Kubernetes v1.37, el gang scheduling nativo a través de la Workload API pasó a Beta.

Antes de esta función, Kubernetes programaba los Pods de uno en uno. Para un trabajo estrechamente acoplado, como un entrenamiento distribuido en el que todos los workers deben arrancar juntos, esto causaba scheduling parcial. Algunos Pods arrancaban mientras otros quedaban pendientes, reteniendo recursos sin lograr nada. Los equipos tenían que agregar un scheduler externo para conseguir un comportamiento de todo o nada (gang). Kubernetes v1.35 introdujo el gang scheduling nativo como Alpha mediante una nueva Workload API.

Con la v1.37, la API es ahora scheduling.k8s.io/v1beta1. Se activa con el feature gate GenericWorkload. En la v1.37, los antiguos gates GangScheduling y WorkloadAwarePreemption se fusionaron en GenericWorkload, de modo que un solo gate cubre ahora tanto el gang scheduling como la preempción consciente del workload. El modelo tiene tres partes. Un Workload contiene uno o más podGroupTemplates, cada uno con una política de scheduling como gang y un minCount. Un PodGroup se crea a partir de una plantilla y hace seguimiento de un grupo en ejecución. Cada Pod apunta a su grupo con schedulingGroup.podGroupName. El scheduler retiene los Pods hasta que al menos minCount de ellos puedan ejecutarse juntos y entonces los ubica. Si no puede cumplir con minCount, no vincula ninguno, y los Pods esperan hasta que haya espacio. El campo minCount sigue siendo modificable después de la creación, lo que ayuda a los trabajos elásticos a crecer o reducirse.

El Workload define la plantilla:

apiVersion: scheduling.k8s.io/v1beta1
kind: Workload
metadata:
  name: training-job
spec:
  podGroupTemplates:
  - name: workers
    schedulingPolicy:
      gang:
        minCount: 4

Un PodGroup se crea a partir de esa plantilla:

apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: training-job-workers-0
spec:
  workloadRef:
    workloadName: training-job
    templateName: workers
  schedulingPolicy:
    gang:
      minCount: 4

Cada Pod se une al grupo por su nombre:

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
spec:
  schedulingGroup:
    podGroupName: training-job-workers-0
  containers:
  - name: trainer
    image: trainer:1.0
    # ...

Con esta configuración, Kubernetes programa los workers solo cuando al menos cuatro de ellos pueden ejecutarse juntos. Si el clúster no tiene espacio para cuatro, no arranca ninguno.

8. Kubelet en un user namespace (modo rootless)

Grupo responsable: SIG Node | KEP: #2033

En Kubernetes v1.37, la ejecución del kubelet en un user namespace, también conocida como modo rootless, pasó a Beta.

Antes de esta función, los componentes del nodo, como el kubelet, se ejecutaban como root en el host. Si el kubelet se veía comprometido, un atacante podía obtener acceso root a todo el nodo.

Con la v1.37, el feature gate KubeletInUserNamespace está en Beta. Ejecuta el kubelet y los demás componentes del nodo dentro de un user namespace de Linux. Dentro del namespace siguen pareciendo root, pero en el host se mapean a un usuario sin privilegios. Esto agrega una capa de aislamiento sin cambiar la forma en que usas el kubelet en el día a día. Esta función viene trabajándose desde la v1.22, así que llegar a Beta es un gran paso.

Funciones Alpha de Kubernetes v1.37

9. Eviction Request API

Grupo responsable: SIG Node | KEP: #4563

Antes de esta función, drenar un nodo por mantenimiento era una acción del lado del cliente. Una herramienta como kubectl drain expulsaba los Pods de uno en uno y respetaba los PodDisruptionBudgets, pero la intención vivía en el cliente, no en el clúster. Los controladores y las aplicaciones no podían ver que un nodo estaba siendo drenado, coordinar una transición segura ni participar en la decisión. Una aplicación con estado podía ser expulsada en un mal momento porque nada le avisaba que venía un mantenimiento.

Con la v1.37, una función Alpha agrega la API EvictionRequest, de modo que la expulsión pueda ser cooperativa en lugar de una eliminación forzada. Un solicitante crea un EvictionRequest para un Pod, y los componentes registrados a través del nuevo campo spec.evictionResponders del Pod se encargan de una transición ordenada. La v1.37 también agrega nuevas condiciones del ciclo de vida del Node (MaintenancePlanned, MaintenanceInProgress, GracefulNodeShutdownInProgress, DrainInProgress y Drained) que los controladores pueden observar para saber en qué punto del flujo de mantenimiento está un nodo. En conjunto, esto permite que una aplicación u operador gestione el drenado en sus propias condiciones, por ejemplo, trasladando un líder o volcando su estado antes de que su Pod desaparezca.

10. Checkpoint y restore a nivel de Pod

Grupo responsable: SIG Node | KEP: #5823

Antes de esta función, Kubernetes podía hacer checkpoint de un único contenedor (KEP #2008), principalmente para análisis forense. Podías capturar el estado de un contenedor, pero no de un Pod completo a la vez, así que un Pod con varios contenedores no podía capturarse como una unidad.

Con la v1.37, una función Alpha agrega checkpoint y restore a nivel de Pod. Extiende la Container Runtime Interface (CRI) con las llamadas CheckpointPod y RestorePod, de modo que el kubelet y un runtime compatible puedan capturar juntos todos los contenedores de un Pod y luego restaurarlos. Esto resulta útil hoy para trabajo forense y sienta las bases para usos futuros, como mover un Pod en ejecución entre nodos. La función requiere un runtime de contenedores que soporte las nuevas llamadas CRI.