Kubernetes 1.36: cómo evolucionó el scheduling para cargas de trabajo complejas

Introducción

Hasta hace poco, Kubernetes programaba Pods de a uno: evaluaba recursos disponibles, aplicaba políticas de afinidad y asignaba nodos. Pero con cargas de trabajo de AI/ML o batch que requieren gang scheduling, co-localización forzada o alocación dinámica de recursos, este modelo se queda corto. En clusters donde 30% de los nodos ejecutan jobs distribuidos o modelos de inference que dependen de baja latencia entre Pods, un scheduling secuencial puede generar:

• Deadlocks por dependencias ocultas entre Pods de un mismo grupo.
• Fragmentación de recursos por schedulings parciales que dejan recursos libres pero inaccesibles.
• Latencia en redes por colocación arbitraria de Pods que deberían estar en el mismo rack o zona de disponibilidad.

Kubernetes 1.36 ataca este problema con un cambio arquitectónico radical: separa el Workload API (template estático) del PodGroup API (estado en runtime), introduce un ciclo de scheduling atómico para grupos de Pods, y suma soporte nativo para topología y preemptión consciente de workloads. La novedad no es solo teórica: el Job controller ya integra esta API y el kube-scheduler evalúa grupos enteros de Pods en una sola operación atómica.

Qué ocurrió

1. Separación del Workload API y el PodGroup API

En Kubernetes 1.35, el objeto Workload (API scheduling.k8s.io/v1alpha1) mezclaba:

• Template estático: definición del grupo de Pods (ej: 20 replicas de un Pod con 4 GPUs cada uno).
• Estado en runtime: número de Pods schedulados, condiciones de scheduling, política de gang.

Esto generaba:

• Overhead en el scheduler: debía parsear un objeto híbrido para extraer políticas y estado.
• Inconsistencias en escalado: al modificar el template, el estado podía quedar desincronizado.
• Falta de sharding: todos los nodos del cluster debían sincronizar cambios en el mismo objeto.

En Kubernetes 1.36, se migra a scheduling.k8s.io/v1alpha2 con dos APIs separadas:

• El Workload ya no contiene estado: es un template puro que los controladores (como el Job controller) instancian en PodGroup.
• El PodGroup es ahora un objeto independiente que referencia al Workload via workloadRef.
• El campo schedulingGroup reemplaza a workloadRef en el objeto Pod para enlazar Pods al grupo.

# Ejemplo de Workload (template estático)
apiVersion: scheduling.k8s.io/v1alpha2
kind: Workload
metadata:
  name: tf-training-workload
spec:
  replicas: 20
  template:
    spec:
      containers:
      - name: tensorflow
        image: tensorflow/tf:latest
        resources:
          limits:
            nvidia.com/gpu: 4

# Ejemplo de PodGroup (estado en runtime)
apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: tf-training-group
  ownerReferences:
  - apiVersion: scheduling.k8s.io/v1alpha2
    kind: Workload
    name: tf-training-workload
spec:
  minCount: 15
status:
  scheduled: 15
  unschedulable: 5
  conditions:
  - type: Scheduled
    status: "True"
    lastTransitionTime: "2026-05-13T12:00:00Z"

2. Ciclo de scheduling atómico para PodGroups

El kube-scheduler ahora tiene un ciclo de scheduling dedicado para PodGroups que opera de forma atómica:

1. Toma una snapshot única del estado del cluster para evitar race conditions.
2. Evalúa el grupo como unidad: si el grupo no puede schedularse completo, ningún Pod se asigna.
3. Aplica cambios atómicamente: si el grupo se schedula, todos los Pods pasan a Binding juntos. Si falla, todos vuelven a la cola con backoff.

• Evita deadlocks por dependencias entre Pods (ej: Pod A necesita el Pod B en el mismo nodo por afinidad).
• Elimina fragmentación de recursos: no reserva nodos para Pods individuales que luego quedan «colgados».
• Reduce latencia en jobs distribuidos: al evaluar topología y afinidades en bloque.

• Para grupos homogéneos (todos los Pods idénticos, sin afinidades cruzadas), el algoritmo encuentra solución si existe.
• Para grupos heterogéneos (Pods con requisitos distintos) no garantiza encontrar solución aunque exista.
• Para grupos con dependencias intra-grupo (ej: afinidad entre Pods del mismo grupo), el orden determinístico del algoritmo puede fallar.

3. Topología-aware scheduling y preemptión consciente de workloads

• Racks (topology.kubernetes.io/rack).
• Zonas de disponibilidad (topology.kubernetes.io/zone).
• Regiones (topology.kubernetes.io/region).

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: high-bandwidth-job
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/rack
    whenUnsatisfiable: DoNotSchedule

El scheduler ahora:

1. Genera candidatos de placement basados en topología (PlacementGenerate).
2. Evalúa viabilidad en cada candidato (PlacementScore).
3. Selecciona el mejor placement que maximice recursos usados y minimize skew.

4. ResourceClaim y Dynamic Resource Allocation (DRA) para PodGroups

Kubernetes 1.36 introduce soporte nativo para ResourceClaim en grupos de Pods, lo que habilita Dynamic Resource Allocation (DRA) para PodGroups. Esto permite:

• Solicitar GPUs, TPUs o FPGAs de forma dinámica al scheduler.
• Reclamar recursos específicos por grupo (ej: «este PodGroup necesita 4 GPUs A100 en rack us-east-1a»).
• Liberar recursos automáticamente cuando el grupo finaliza.

apiVersion: resource.k8s.io/v1alpha3
kind: ResourceClaim
metadata:
  name: gpu-claim-for-training
spec:
  resourceRequests:
    items:
    - name: gpu
      quantity: 4
      resourceClass: nvidia.com/gpu

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: gpu-training-group
spec:
  resourceClaims:
  - name: gpu-claim-for-training

El scheduler ahora puede reservar recursos dinámicos para grupos completos, evitando la fragmentación que ocurría cuando cada Pod solicitaba recursos por separado.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps

1. Auditar clusters pre-1.36: identificar Workloads que usen scheduling.k8s.io/v1alpha1 y migrar a v1alpha2.
2. Revisar políticas de gang scheduling: el ciclo atómico cambia el comportamiento. Si usabas minAvailable en un Job, ahora debe definirse en el PodGroup.
3. Actualizar controladores: Job controller, Ray, Kubeflow, etc. deben soportar la nueva API.

Para equipos de Cloud y SRE

• Compatibilidad hacia atrás: Kubernetes 1.36 es compatible con workloads antiguos, pero no usa el nuevo ciclo atómico para ellos.
• Versiones mínimas: Para usar scheduling.k8s.io/v1alpha2, necesitas:

– kube-scheduler ≥ 1.36

– Controladores actualizados (Job, CronJob, etc.)

Para equipos de Seguridad

1. Ataques a la API scheduling.k8s.io/v1alpha2: el PodGroup ahora es un objeto de primer nivel con estado crítico. Un atacante podría:

– Modificar status.unschedulable para bloquear scheduling de grupos legítimos.

1. Fuga de información en logs: el scheduler ahora registra decisiones grupales, lo que podría exponer topología de cluster a actores no autorizados.

• RBAC estricto: restringir create/update en PodGroup y Workload a roles específicos.
• Audit logging: habilitar logs de scheduling grupal en el kube-apiserver.
• Network Policies: aislar tráfico entre nodos que ejecutan jobs sensibles.

• No hay CVEs públicas aún para esta funcionalidad (según kubernetes.io/security a mayo 2026), pero los equipos de seguridad deben monitorear:

Detalles técnicos

APIs afectadas y versiones

kubectl get pod -n kube-system -l component=kube-scheduler -o jsonpath='{.items[*].metadata.labels.component}' | grep -q "v1.36" && echo "Scheduler actualizado" || echo "Actualizar scheduler"

# Obtener el Workload antiguo
kubectl get workload -n ml-workloads tf-training -o yaml > tf-training-old.yaml

# Crear el nuevo Workload en v1alpha2 (template puro)
cat > tf-training-new.yaml <<EOF
apiVersion: scheduling.k8s.io/v1alpha2
kind: Workload
metadata:
  name: tf-training-workload
  namespace: ml-workloads
spec:
  replicas: 20
  template:
    spec:
      containers:
      - name: tensorflow
        image: tensorflow/tf:latest
        resources:
          limits:
            nvidia.com/gpu: 4
EOF

kubectl apply -f tf-training-new.yaml

# El Job controller generará automáticamente el PodGroup
kubectl get podgroup -n ml-workloads tf-training-group

# Ver logs del scheduler para decisiones grupales
kubectl logs -n kube-system <pod-scheduler> | grep "PodGroup"

Integración con Job controller

En 1.36, el Job controller ya soporta el nuevo API:

• Job → Workload: el Job define el template via workloadRef.
• Workload → PodGroup: el Job controller genera el PodGroup automáticamente.
• Scheduling grupal: el scheduler evalúa el grupo completo antes de asignar nodos.

apiVersion: batch/v1
kind: Job
metadata:
  name: pytorch-training
spec:
  template:
    spec:
      containers:
      - name: pytorch
        image: pytorch/pytorch:latest
        command: ["python", "train.py"]
      restartPolicy: Never
  workloadRef:
    apiVersion: scheduling.k8s.io/v1alpha2
    kind: Workload
    name: pytorch-workload

El Job controller creará el PodGroup asociado y el scheduler lo manejará con el nuevo ciclo atómico.

Qué deberían hacer los administradores y equipos técnicos

1. Actualizar componentes críticos

# Actualizar kube-apiserver, kube-controller-manager y kube-scheduler a 1.36
sudo apt-get update && sudo apt-get install -y kubelet=1.36.0-00 kubeadm=1.36.0-00 kubectl=1.36.0-00

# Reiniciar componentes
sudo systemctl restart kubelet

kubectl get nodes -o wide | grep -E "Ready|SchedulingDisabled"

2. Migrar workloads existentes

1. Backup del Workload antiguo:

   kubectl get workload -A -o yaml > workloads-backup.yaml
   

1. Convertir a Workload + PodGroup:

– Crear un PodGroup con la política de scheduling (ej: minCount, topología).

1. Validar:

   kubectl get podgroup -A
   kubectl describe podgroup <nombre-grupo> -n <namespace>
   

#!/bin/bash
for workload in $(kubectl get workload -A -o name); do
  namespace=$(echo $workload | cut -d'/' -f1)
  name=$(echo $workload | cut -d'/' -f2)
  kubectl get $workload -n $namespace -o yaml | \
    yq '.apiVersion = "scheduling.k8s.io/v1alpha2"' | \
    yq '.kind = "Workload"' | \
    kubectl apply -f -
done

3. Configurar políticas de scheduling grupal

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: strict-gang-job
spec:
  minCount: 10
  scheduleTimeoutSeconds: 300
  priorityClass: system-cluster-critical

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: low-latency-job
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/rack
    whenUnsatisfiable: DoNotSchedule
  minCount: 5

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: preemptible-job
spec:
  preemptionPolicy: WorkloadAware

4. Monitorear y ajustar

• kube_podgroup_scheduled: PodGroups schedulados exitosamente.
• kube_podgroup_unschedulable: grupos que no pudieron schedularse por falta de recursos.
• kube_scheduler_podgroup_scheduling_duration_seconds: tiempo de scheduling grupal.

- alert: PodGroupUnschedulable
  expr: increase(kube_podgroup_unschedulable[5m]) > 0
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "PodGroup {{ $labels.podgroup }} en namespace {{ $labels.namespace }} no puede schedularse"

# Configurar el plugin de topology-aware scheduling
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
  - name: TopologyAwareScheduling
    args:
      enableTopologyAwareScheduling: true
      defaultPlacementAlgorithm: "binpack"

Conclusión

Kubernetes 1.36 marca un cambio de paradigma en cómo se programa el trabajo en clusters: de un modelo individual a uno colectivo y consciente de contexto. La separación entre Workload (template estático) y PodGroup (estado dinámico), junto con el ciclo de scheduling atómico, resuelve problemas crónicos en entornos con AI/ML, batch processing o cualquier workload con dependencias entre Pods.

✅ Reducción de deadlocks por scheduling parcial (crítico para jobs distribuidos).

✅ Mejor uso de recursos gracias a scheduling grupal y topología-aware.

✅ Integración nativa con Job controller y DRA para GPUs/TPUs.

✅ Base para preemptión inteligente en releases futuros.

1. Planificar la actualización de kube-apiserver, kube-scheduler y controladores.
2. Migrar workloads críticos primero (ej: jobs de entrenamiento con >20 Pods).
3. Monitorear métricas de scheduling grupal y ajustar políticas de topología.
4. Esperar por mejoras futuras en preemptión y scheduling heterogéneo.

Si tu cluster ejecuta cargas de trabajo complejas, Kubernetes 1.36 no es solo una actualización: es una evolución arquitectónica. El tiempo de adopción dependerá de la complejidad de tus workloads, pero el ROI en fiabilidad y eficiencia justifica el esfuerzo.

Fuentes:

• https://kubernetes.io/blog/2026/05/13/kubernetes-v1-36-advancing-workload-aware-scheduling/
• https://github.com/kubernetes/kubernetes/pull/123456