Planteamiento
Kubernetes v1.35 documenta Scheduling Group como una funcionalidad alpha. Diseña una plataforma de procesamiento por lotes (batch) donde los workers interdependientes comiencen solo cuando se puedan ubicar al menos minCount Pods juntos. Explica cómo cooperan PodGroup, el scheduler, los controladores, el escalado automático y el manejo de fallos. Indica las suposiciones sobre la versión y los feature-gates.
Qué está evaluando el entrevistador
La prueba principal es si puedes elevar la viabilidad de un solo Pod a un grupo completo manteniendo consistentes la API, la programación y el estado en tiempo de ejecución. Una respuesta sólida distingue basic de gang, maneja la ausencia de un PodGroup, la escasez de capacidad, el fallo de miembros, la apropiación (preemption) y la observabilidad, y evita presentar una API alpha como lista para producción universalmente.
Preguntas para clarificar
- ¿Deben todos los workers iniciar juntos, o es suficiente un umbral concurrente menor?
- ¿Son los miembros Jobs de una sola ejecución o servicios de larga duración?
- ¿Necesitan GPUs, restricciones de topología o ubicación entre clústeres? La referencia documentada es un PodGroup en el mismo namespace.
- ¿Cuál es el tiempo límite de espera (deadline), y puede un trabajo ponerse en cola, tomar prestada capacidad o degradar sus requisitos?
Un marco de 30 segundos
Comienza con los límites: Scheduling Group y las políticas de PodGroup están en estado alpha en v1.35, deshabilitadas de forma predeterminada y requieren el feature gate GenericWorkload. Luego cubre cuatro capas: contrato de la API, programación de grupos, ciclo de vida y operaciones. Un Workload crea el PodGroup; los Pods hacen referencia a él; el scheduler aplica la política y minCount; los controladores gestionan los tiempos de espera, los reintentos y la limpieza; las métricas y el rollback protegen el despliegue.
Diseño paso a paso
1. Modelo e invariantes
El controlador crea un PodGroup por ejecución con los miembros deseados, la política, la versión y el tenant. Cada Pod establece spec.schedulingGroup.podGroupName hacia un PodGroup en el mismo namespace. El campo es inmutable, por lo que mover un Pod implica crear un nuevo conjunto. Para un grupo gang, ningún miembro se vincula (bind) hasta que se cumpla la invariante de minCount.
2. Elegir la política
Usa basic cuando los miembros puedan ejecutarse de forma independiente y la agrupación sirva principalmente para la gestión y la observabilidad. Usa gang para tareas de entrenamiento o procesamiento por lotes estrechamente acopladas; el grupo solo es viable cuando al menos minCount miembros pueden programarse simultáneamente. Configurar minCount por debajo del total permite elasticidad; configurarlo igual al total requiere a todos los miembros.
3. Máquina de estados de envío y espera
Crea el PodGroup antes de crear los Pods para que las referencias se resuelvan. Si el objeto referenciado está ausente, los Pods permanecen en estado Pending y el scheduler reintenta después de que aparezca el grupo. Rastrea estados como PendingGroup, WaitingCapacity, Feasible, Bound, Running, Failed y Cancelled, cada uno con una generación, motivo y marca de tiempo.
4. Programación y coordinación de capacidad
El scheduler evalúa primero los nodos candidatos mediante filtros, topología, dispositivos y prioridad, y luego comprueba la viabilidad del grupo. Las operaciones de vinculación (bind) deben ser reintentables e idempotentes, y ocurrir solo después de que el recuento de candidatos alcance minCount. El escalador automático debe consumir el perfil de recursos del grupo y escalar para la solicitud completa en lugar de agregar capacidad solo para el primer Pod.
5. Preemption, plazos y equidad
Asigna al grupo una prioridad y un peso de cola consistentes para que la apropiación (preemption) no deje medio grupo inservible. Al cumplirse un plazo límite (deadline), cancela el grupo y libera las reservas; los reintentos usan una nueva generación para que los miembros obsoletos no puedan reincorporarse. Las cuotas de tenant, el tamaño máximo del grupo y el envejecimiento de la cola evitan que grupos gang grandes monopolicen el clúster.
6. Fallo de miembros y rollback
Tras el inicio, un miembro caído no debe tratarse como evidencia de que el grupo está actualmente sano. Dependiendo de la semántica del trabajo, reinicia un miembro o termina el grupo; los trabajos de entrenamiento comúnmente restauran un checkpoint y crean una nueva generación. Eliminar un Workload debe limpiar los Pods de los que es propietario y el PodGroup, preservando al mismo tiempo los eventos terminales para auditoría.
7. Observabilidad y límites de seguridad
Expón la latencia de la cola del grupo, el recuento de miembros viables, minCount, los recuentos de escalado y preemption, y los motivos de fallo. Un webhook de admisión valida el namespace, la cuota, el tamaño del grupo y la disponibilidad del feature gate. Dado que la API es alpha, utiliza un conmutador de despliegue explícito, pruebas de compatibilidad y una ruta rápida de reversión (rollback).
Ejemplo de una respuesta sólida
«Haría que un controlador de Workload cree un PodGroup en el mismo namespace con la política gang y un minCount igual al mínimo de workers necesarios para progresar. Los Pods hacen referencia a él mediante el campo inmutable schedulingGroup. El controlador crea primero el grupo; las referencias no resueltas permanecen en Pending. El scheduler evalúa los recursos, la topología y la prioridad de todos los miembros y vincula solo cuando el recuento de viables alcanza minCount. El escalador automático escala a partir del perfil de recursos del grupo. Un deadline cancela todo el grupo y libera capacidad; una ejecución de entrenamiento fallida obtiene una nueva generación restaurada a partir de un checkpoint. El manifiesto de despliegue registra explícitamente v1.35 alpha y GenericWorkload, y el despliegue comienza en un clúster aislado».
Errores comunes
- Llamar a
basic"todo o nada" a pesar de que sus miembros pueden programarse de forma independiente. - Usar únicamente etiquetas sin explicar la referencia al PodGroup en el mismo namespace y el campo inmutable.
- Ignorar la ausencia de un grupo, el escalado, los plazos límite, la preemption o las generaciones de reintentos.
- Omitir el estado alpha y el feature gate
GenericWorkload. - Hablar de una vinculación exitosa sin considerar la cancelación a nivel de grupo y las métricas.
Preguntas de seguimiento
¿Qué pasa si el PodGroup se crea después del Pod?
El Pod permanece en Pending y el scheduler lo reconsidera una vez creado el PodGroup. El controlador debería crear el grupo primero para acortar esta ventana.
¿Cómo se elige minCount?
Usa el paralelismo mínimo útil de la aplicación, los recursos por Pod y el tiempo de cola aceptable; luego aplica cuotas y un límite superior.
¿Cómo evitas la inanición (starvation) de los gangs?
Combina colas justas, envejecimiento, límites de tamaño de grupo, cuotas por tenant y cancelación por deadline mientras monitoreas el tiempo de espera del grupo.
¿En qué se diferencia esto de los scheduling gates?
Un gate controla cuándo un Pod individual entra en la cola de programación. Scheduling Group hace que el scheduler evalúe un conjunto a través de un PodGroup. Se pueden combinar, pero sus métricas y semánticas de fallo deben mantenerse separadas.
¿Cuándo retrasarías el despliegue?
Retrasa el despliegue si la versión del clúster, el feature gate, los plugins del scheduler o el autoscaler son incompatibles, o si la actualización y reversión de la versión alpha no han sido probadas. Usa un controlador de colas explícito como diseño provisional.
Referencias
- Documentación de Kubernetes: «Scheduling Group».
- Documentación de Kubernetes: «PodGroup Scheduling Policies».
- Documentación de Kubernetes: «Scheduling API Reference».