Entrevista de diseño de sistemas: ¿cómo diseñarías el gang scheduling consciente de la topología para cargas de trabajo de Kubernetes?

Problema y escenarios aplicables

Eres responsable de una plataforma de entrenamiento distribuido en Kubernetes. Una carga de trabajo se representa mediante un PodGroup, y sus Pods deben compartir un rack o zona para reducir la latencia de comunicación. Si un dominio de topología no puede alojar al menos minCount Pods, la carga de trabajo debe permanecer no programable (unschedulable).

Esto se adapta a entrevistas de ingeniería de plataformas, SRE y diseño de sistemas. Asume Topology-Aware Scheduling alpha de Kubernetes v1.36, deshabilitado de forma predeterminada, con una restricción de topología por PodGroup.

Qué evalúa el entrevistador

• Si distingues entre el balanceo entre dominios con dispersión de topología (topology spread) y la ubicación en el mismo dominio para un gang.
• Si PodGroup, las etiquetas de nodos, las ubicaciones de candidatos, la viabilidad de recursos y el enlace atómico (atomic binding) forman un único flujo de datos.
• Si explicas minCount, la escasez de capacidad, el escalado horizontal (scale-up) y la ausencia de preemption activada por topología.
• Si identificas el estado alpha, los grupos heterogéneos y el riesgo de reversión (rollback) antes de calificar el diseño como listo para producción.

Preguntas aclaratorias antes de responder

1. ¿Los Pods deben compartir un rack, zona o dominio NUMA? Cada clave de topología cambia las suposiciones de latencia y capacidad.
2. ¿Todos los Pods deben iniciarse juntos, o es suficiente con minCount para progresar? Esto determina la directiva de Gang y la elasticidad.
3. ¿Los Pods son homogéneos? Diferentes solicitudes de recursos afectan si se puede encontrar una ubicación candidata.
4. ¿El clúster puede escalar o realizar preemption? El TAS de v1.36 no realiza preemption meramente para satisfacer la topología.

Marco de respuesta de 30 segundos

“Defino el objetivo como la viabilidad a nivel de grupo dentro de un solo dominio de topología, no la dispersión de réplicas. Una plantilla de Workload crea un PodGroup con gang y minCount; las etiquetas de nodo proporcionan la clave de topología. El planificador genera subconjuntos de nodos candidatos, verifica el grupo completo y califica las ubicaciones viables. Si ninguna encaja, el grupo permanece no programable. El controlador y el autoscaler razonan sobre la forma completa del recurso, y la preemption se maneja por separado porque el TAS de v1.36 no la activa. Pruebo la capacidad del dominio, la pérdida de nodos y las solicitudes heterogéneas detrás de un feature gate alpha.”

Análisis detallado paso a paso

1. Establecer la colocación, no la dispersión

topologySpreadConstraints utiliza maxSkew para balancear Pods entre dominios; esta pregunta requiere que todos los miembros compartan un solo valor de etiqueta de topología. Mezclar la semántica produce la ubicación opuesta, así que escribe el invariante como “un dominio debe alojar al menos minCount”.

2. Definir el contrato del PodGroup

La plantilla declara la directiva de Gang, minCount y una clave de topología. Una configuración ilustrativa es:

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
spec:
  schedulingPolicy:
    gang:
      minCount: 4
  schedulingConstraints:
    topology:
      - key: topology.example.com/rack

Los nodos necesitan valores de etiqueta estables y gobernados. PodGroup expresa la ubicación; el controlador de Workload aún posee la creación de miembros, las versiones y el ciclo de vida.

3. Explicar la ubicación de candidatos

El planificador primero genera subconjuntos de nodos candidatos utilizando recursos, taints, afinidad y la clave de topología. Luego verifica si el PodGroup completo encaja dentro de cada subconjunto y califica las ubicaciones viables. Esto evita enlazar Pods iniciales entre dominios y dejar a los miembros restantes incapaces de satisfacer minCount.

4. Manejar la capacidad, el escalado horizontal y la preemption

Si ningún dominio candidato tiene suficiente capacidad, todo el grupo permanece no programable. El autoscaler debe consumir la forma completa de CPU, memoria, GPU y dominio en lugar de escalar para el primer Pod en estado Pending. El TAS de v1.36 no activa la preemption de Pods o Workloads para satisfacer la topología, por lo que las reservas de capacidad, las colas o una directiva explícita de preemption aguas arriba son requisitos independientes.

5. Manejar la recreación de miembros y la adherencia al dominio

Cuando los miembros ya se ejecutan en un dominio, los Pods recreados se fuerzan a entrar en ese mismo dominio; permanecen en Pending si este carece de capacidad, incluso cuando otro dominio tiene espacio. Expón esto como una espera con adherencia al dominio (domain-sticky wait) y decide si esperar, restaurar un checkpoint o crear una nueva generación de PodGroup con una restricción diferente.

6. Evaluar el estado alpha y los límites heterogéneos

La API de v1.36 es alpha y está deshabilitada de forma predeterminada. Las notas oficiales de la versión establecen que no se garantiza encontrar una ubicación para PodGroups heterogéneos o con dependencias entre Pods, incluso cuando existe una. Los controles de producción deben cubrir la versión, el feature gate, el plugin del scheduler, el autoscaler y la reversión; una programación exitosa no es una garantía universal.

7. Construir un ciclo de verificación y reversión

Ejecuta la misma carga de trabajo de entrenamiento con la capacidad de dominio justa, un nodo faltante, etiquetas de topología faltantes, diferentes tipos de GPU y recreación de miembros. Registra los dominios candidatos, el recuento de miembros viables, los motivos de Pending, el tiempo de espera, el tráfico entre dominios y el rendimiento (throughput) del entrenamiento. Si las pruebas canary fallan, deshabilita el feature gate o regresa al Gang scheduling ordinario mientras conservas los eventos de PodGroup para auditoría.

Respuesta de muestra de alta calidad

Definiría el invariante como “al menos minCount miembros encajan simultáneamente en un dominio de topología”, en lugar de utilizar restricciones de dispersión para balancear. Un controlador de Workload crea un PodGroup con Gang, minCount y una clave de topología, y luego crea Pods que hacen referencia a él. El planificador genera dominios candidatos a partir de recursos y etiquetas de nodo, verifica el grupo completo y califica solo los dominios viables; si ninguno funciona, el grupo permanece en Pending. El autoscaler escala a partir de la forma del grupo, mientras que la preemption es independiente porque el TAS de v1.36 no la activa. Los miembros recreados mantienen la adherencia al dominio; si ese dominio se pierde, se crea una nueva generación. Finalmente, pon a prueba la pérdida de nodos, las etiquetas faltantes, las GPU heterogéneas y la reversión detrás del feature gate alpha mientras mides el tiempo de espera, el tráfico entre dominios y el throughput del entrenamiento.

Errores comunes

• Síntoma: Explicar la ubicación en el mismo dominio con maxSkew. Por qué falla: la dispersión apunta a la distribución, lo opuesto a la coubicación de Gang. Solución: establece primero el invariante de dominio único de PodGroup.
• Síntoma: Enlazar Pods uno por uno. Por qué falla: los enlaces tempranos consumen capacidad en varios dominios y no dejan forma de alcanzar minCount. Solución: evalúa primero la ubicación candidata completa.
• Síntoma: Asumir que TAS realiza preemption automáticamente. Por qué falla: v1.36 indica explícitamente que la programación consciente de la topología no activa la preemption. Solución: diseña reservas, colas o un controlador de preemption aguas arriba.
• Síntoma: Ignorar los grupos heterogéneos y el estado alpha. Por qué falla: la ubicación no está garantizada y la funcionalidad está deshabilitada de forma predeterminada. Solución: añade comprobaciones de versión, gate, plugin y reversión.

Preguntas de seguimiento y respuestas

¿Qué pasa si un rack no puede alojar minCount, pero dos racks juntos sí pueden?

El invariante del mismo dominio no se cumple, por lo que se debe mantener el grupo en Pending o reducir minCount solo si la aplicación permite elasticidad. No recurras silenciosamente a la ubicación entre racks porque la suposición de comunicación cambió.

¿Cómo debería escalar correctamente el autoscaler?

Trata la solicitud completa de recursos, la clave de topología y minCount como una sola unidad de escalado. Predice los tipos y la cantidad de nodos requeridos en un dominio de destino, regenera candidatos después del scale-up y aplica un límite de tiempo de espera (wait deadline).

¿Por qué un miembro recreado no puede moverse a otro dominio?

El comportamiento documentado mantiene a los nuevos miembros en el dominio donde se ejecutan los miembros existentes; mover uno cambia las suposiciones de latencia y recursos compartidos. Si el dominio se pierde permanentemente, crea una nueva generación de PodGroup en lugar de mutar silenciosamente la anterior.

¿Cómo puede coexistir esto con las restricciones de dispersión de topología (topology spread constraints)?

Usa TAS para coubicar miembros dentro de un trabajo de entrenamiento; usa la dispersión para distribuir réplicas entre múltiples trabajos. Antes de colocar ambos en un Pod, prueba si sus restricciones duras tienen una intersección no vacía o los Pods podrían permanecer en Pending.

¿Cuándo sería mejor el Gang scheduling ordinario que TAS?

Elige el Gang ordinario cuando la comunicación entre dominios sea económica, la capacidad del dominio sea frecuentemente ajustada, la característica alpha no esté lista para tu despliegue o la carga de trabajo no necesite racks compartidos. Habilita TAS solo cuando las ganancias de rendimiento justifiquen la capacidad y el costo operativo.