Consigna y contexto
Operas una plataforma de GPU en Kubernetes. Los trabajos de entrenamiento y de inferencia por lotes deben esperar por cuota, recursos de nodo, ventanas de mantenimiento y políticas de seguridad antes de que se creen los Pods. Diseña la admisión con Workloads de Kueue, ClusterQueues, ResourceFlavors y AdmissionChecks, evitando la inanición y la liberación no segura.
Qué está evaluando el entrevistador
Separar el encolamiento de la admisión: que un Workload entre en una cola no significa que se puedan crear los Pods. Una ClusterQueue elige flavors a partir de grupos de recursos y cuota nominal, mientras que los AdmissionChecks permiten que controladores internos o externos influyan en la liberación. Cubre la consistencia de estado, revocación, admisión parcial, equidad entre tenants, backoff y auditabilidad.
Preguntas de clarificación para hacer primero
Recursos y prioridad
Clarifica el modelo de GPU, memoria, CPU, topología, desalojo (preemption), prioridad del tenant, equidad en la cola y tiempo máximo de espera. Contar únicamente las GPU puede crear una falsa capacidad cuando la memoria o la topología no encajan.
Dependencias de admisión externas
Identifica los controladores para ventanas de mantenimiento, escaneo de imágenes, aprobación de presupuesto y acceso a datos. Decide si los resultados son reproducibles y si el agotamiento de tiempo de espera (timeout) significa rechazar o esperar. Cada verificación externa necesita un propietario y un TTL.
Política de fallos y revocación
Define qué sucede cuando los nodos cambian, la cuota se reclama o la política se revoca después de la admisión. Los registros de admisión, la creación de Pods y las verificaciones externas necesitan una correlación idempotente para evitar liberaciones duplicadas.
Estructura de respuesta de 30 segundos
“Un Workload entra en una LocalQueue, y su ClusterQueue evalúa los grupos de recursos, flavors y la cuota de la cohorte. Todos los AdmissionCheckStates requeridos deben estar en Ready antes de la admisión; Pending permanece en cola, mientras que Rejected o el timeout sigue una política de reintentos acotados o de terminación. Se persiste un estado rastreable del workload, se vuelven a verificar los recursos y las políticas antes de crear los Pods, y se mide el uso de cuota, tiempo de espera, latencia de verificación, rechazos y revocaciones para validar la seguridad y la equidad.”
Respuesta detallada paso a paso
Paso 1: Definir los límites del Workload y de la cola
Convierte el Job del usuario en un Workload programable con PodSets, solicitudes de recursos, prioridad y cola del tenant. Una LocalQueue ordena y espera; no debe crear Pods ni eludir las restricciones de recursos de la ClusterQueue.
Paso 2: Seleccionar ResourceFlavors a través de la ClusterQueue
Describe los recursos de CPU, memoria y GPU con ResourceGroups, y luego elige una combinación de flavors con cuota nominal disponible. Coloca el modelo de GPU, la región, las etiquetas de nodo y la topología en las restricciones del flavor para que “suficientes GPU” no se convierta en una admisión falsa.
Paso 3: Orquestar la máquina de estados de AdmissionCheck
Expón estados observables de Pending, Ready, Rejected y terminales. Los controladores de seguridad, mantenimiento y presupuesto actualizan el estado de forma idempotente usando el UID del Workload. Kueue admite solo cuando cada verificación requerida está en Ready; Pending no debe etiquetarse erróneamente como fallo, y Rejected no puede ignorarse en silencio.
Paso 4: Manejar la admisión parcial y los cambios de recursos
Si se permite la admisión parcial, define el paralelismo reducible de PodSet, el tamaño mínimo y las reglas de expansión posteriores. Vuelve a evaluar los flavors y las verificaciones después de una liberación de cuota o fallo de nodo; nunca reutilices una instantánea de admisión vencida. Las solicitudes permanentemente inviables necesitan un rechazo explicativo en lugar de reintentos infinitos.
Paso 5: Preservar la equidad y prevenir la inanición
Define los límites de compartición y préstamo en cohortes entre tenants, colas y prioridades. Evita que los trabajos de alta prioridad ocupen GPUs escasas indefinidamente; agrega reglas de espera o envejecimiento (aging) para prioridades más bajas. Observa la asignación de cuota, la espera de verificación y el inicio real de Pods por separado para que una admisión rápida con inicio lento sea visible.
Paso 6: Diseñar la revocación, el reintento y la auditoría
Usa backoff con fluctuación aleatoria (jitter) y límites de reintento para timeouts o fallos del controlador. La revocación debe propagarse de manera segura al Workload y a los PodSets, no simplemente cambiar un solo campo. Registra el actor, la hora, el motivo, el flavor, la versión de cuota y la versión de verificación externa para que las decisiones sean reproducibles.
Paso 7: Validar la observabilidad y simulacros de fallos
Monitorea la espera en cola, la latencia de admisión, la duración de Pending de cada verificación, rechazos, revocaciones, utilización de cuota, selección de flavors, GPUs inactivas y el inicio de Pods. Realiza simulacros de cortes de controladores, devoluciones de llamada duplicadas, reclamación de cuota, fallo de nodos y particiones de red para demostrar que el sistema ni libera de forma no segura ni se queda atascado para siempre.
Respuesta de muestra de alta calidad
Colocaría el Workload en una LocalQueue, dejaría que la ClusterQueue seleccione una combinación de recursos viable a partir de los flavors y la cuota de la cohorte, y usaría AdmissionChecks para las condiciones de seguridad, mantenimiento y presupuesto. Se admite solo cuando cada verificación requerida está en Ready y la instantánea de recursos sigue siendo válida; Pending permanece en cola y Rejected o timeout utiliza un backoff acotado. El modelo de GPU, la topología y la región pertenecen a los flavors. La cuota del tenant y el envejecimiento protegen la equidad, mientras que las devoluciones de llamada idempotentes y la revocación se propagan de manera segura al Workload y a los PodSets.
Errores comunes
- Error: Tratar la entrada a la cola como permiso para crear Pods. → Por qué falla: El encolamiento y la admisión son estados separados. → Solución: Requerir la asignación de la ClusterQueue y que todas las verificaciones estén en Ready.
- Error: Seleccionar recursos únicamente por recuento de GPU. → Por qué falla: El modelo, la memoria, la topología o la región podrían no encajar. → Solución: Expresar las restricciones de hardware con ResourceFlavors.
- Error: Reintentar una verificación en Pending indefinidamente. → Por qué falla: La inviabilidad permanente o el fallo del controlador permanecen ocultos. → Solución: Distinguir entre Pending, Rejected y motivos mediante límites y backoff.
- Error: Revocar únicamente un campo de Workload. → Por qué falla: Los Pods existentes pueden seguir consumiendo recursos. → Solución: Definir la acción sobre PodSet, la auditoría y el comportamiento de reversión (rollback).
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿En qué se diferencia un AdmissionCheck de un Admission Webhook de Kubernetes?
AdmissionCheck es el estado de negocio de Kueue para determinar si un Workload puede iniciarse. Un webhook extiende la ruta de solicitud de la API. Pueden cooperar, pero que un webhook pase la validación no significa que se hayan asignado los recursos.
Pregunta de seguimiento 2: ¿Por qué son necesarios los ResourceFlavors?
El mismo recuento de GPU puede representar diferentes modelos, regiones o topologías. Un flavor vincula esos atributos programables a la cuota del grupo de recursos, haciendo que la selección sea explicable y segura.
Pregunta de seguimiento 3: ¿Cómo se evita que devoluciones de llamada duplicadas retrocedan el estado?
Utiliza el UID del Workload, el nombre de la verificación y la versión como clave de idempotencia. Rechaza versiones obsoletas y asegúrate de que las actualizaciones repetidas a Ready no puedan desencadenar una segunda creación de Pods.
Pregunta de seguimiento 4: ¿Cuándo se debe rechazar una solicitud en lugar de mantenerla en Pending?
Recházala cuando su flavor de recursos, política o presupuesto nunca puedan satisfacerse y proporciona el motivo. Una escasez temporal de nodos, una ventana de mantenimiento o un reintento del controlador pueden permanecer en Pending, pero necesitan un tiempo máximo de espera y alertas.