Planteamiento y caso de uso
Una plataforma por lotes crea miles de Pods a la vez, pero las imágenes, las cuotas, la topología o los recursos externos no están listos. Diseña un mecanismo que cree Pods sin enviarlos inmediatamente al programador (scheduler) de Kubernetes y que luego los libere cuando se cumplan las condiciones. Explica cómo evitar el desperdicio de trabajo del scheduler y del Cluster Autoscaler en Pods pendientes inválidos, y cómo manejar los tiempos de espera (timeouts) de los gates, los fallos del controlador y el aislamiento entre inquilinos (tenants).
Qué evalúa el entrevistador
- Separar el estado creado del estado programable.
- Comprender la creación, la eliminación y la restricción de no adición de
spec.schedulingGates. - Diseñar flujos idempotentes de liberación, tiempo de espera, autorización y recuperación.
- Distinguir entre SchedulingGated, Unschedulable y fallos en tiempo de ejecución.
- Demostrar que el sistema no puede estancarse silenciosamente mediante métricas, eventos y registros de auditoría.
Preguntas para aclarar primero
- ¿Quién añade cada gate y quién confirma su condición?
- ¿La condición tiene alcance de Pod, de lote o de inquilino, y se requiere gang scheduling?
- ¿Cuáles son la latencia de liberación, la política de expiración, el límite de concurrencia y el objetivo de costo?
- ¿Cómo deben comportarse los reinicios del controlador, los reintentos de la API, el escalado de nodos y la revocación de permisos?
Respuesta en treinta segundos
Crearía el Pod con schedulingGates con alcance de namespace y haría que el precalentamiento de imágenes, las cuotas y la disponibilidad de recursos externos sean condiciones observables. Un controlador solo elimina los gates de los que es propietario y nunca añade un nuevo gate después de la creación; vuelve a verificar la cuota del inquilino y la política de lotes antes de la liberación. Las métricas distinguen los Pods con gates de los Pods genuinamente no programables, y la expiración pasa a un estado explícito de fallo o revisión humana con condiciones versionadas y registros de auditoría.
Respuesta detallada paso a paso
1. Definir la máquina de estados
Separa Created, SchedulingGated, ReadyToSchedule, Unschedulable, Running y Expired. La API aún puede leer un Pod, pero el scheduler no intenta programar un Pod cuya lista de gates no esté vacía.
2. Elegir los nombres de los gates
Cada gate es una condición de tipo cadena, como batch.example.com/image-ready. Coloca el namespace, el lote y las versiones del controlador en etiquetas (labels) o anotaciones; mantén el nombre del gate como una declaración de una condición no cumplida en lugar de un contenedor para datos dinámicos.
3. Establecer gates en la creación
Un gate puede inicializarse en la creación del Pod mediante el cliente o un mutador de admisión (admission mutator). Los gates existentes pueden eliminarse en cualquier orden después de la creación, pero no se puede añadir un nuevo gate, por lo que cada posible condición de bloqueo debe enumerarse en el momento de la creación.
4. Diseñar el controlador de liberación
El controlador observa los Pods, la cuota, el precalentamiento de imágenes y los eventos de recursos externos, calcula el conjunto de condiciones y aplica un parche versionado por recurso (resource-versioned patch). Los eventos duplicados deben converger al mismo resultado; cada controlador elimina únicamente sus propios gates para que los controladores no se sobrescriban entre sí.
5. Manejar lotes y concurrencia
Registra los recursos a nivel de lote en un objeto independiente, mientras que el gate de un Pod espera la decisión del controlador de lotes. Elimina los gates en lotes conscientes del inquilino, la prioridad y la concurrencia, para que el scheduler y el autoscaler no reciban un pico repentino de presión.
6. Diseñar la expiración y la intervención humana
Persiste el tiempo de creación, el último progreso de la condición y la fecha límite (deadline). Al expirar, no elimines un gate silenciosamente; registra un motivo, emite un evento y elige la cancelación, el reintento o una cola de revisión humana. Los reintentos necesitan un retroceso exponencial (backoff) y un límite máximo.
7. Observar las colas reales
Kubernetes expone la etiqueta gated en scheduler_pending_pods para distinguir los Pods explícitamente no listos de los Pods que se intentaron programar y resultaron no programables. Combínala con las condiciones del Pod, los eventos, la longitud de la cola del controlador, los percentiles de antigüedad de los gates y la actividad del autoscaler para localizar el cuello de botella.
8. Restringir la autorización y recuperarse
La política de admisión limita quién puede crear gates, y el controlador solo puede eliminar gates con un namespace y un prefijo permitidos. Después de un reinicio, reconstruye el estado a partir de la API; en caso de conflicto de parches, vuelve a leer y compara la versión del recurso. Si el controlador sigue sin estar disponible, el personal de guardia necesita un procedimiento seguro de cancelación o liberación respaldado por el registro de auditoría.
Compensaciones y límites
Los scheduling gates controlan si un Pod entra en la fase de programación; no reemplazan la afinidad de nodos, las solicitudes de recursos, las restricciones de topología ni la preparación en tiempo de ejecución. Demasiados gates ocultan problemas reales de capacidad en una capa de aplicación; muy pocos envían Pods no preparados al scheduler. Mantén las condiciones no cumplidas separadas de un clúster sin capacidad y no trates un gate como un bloqueo de transacción general entre objetos.
Plan de despliegue y evidencia
- Registra el propietario de cada gate, la fuente de la condición, la expiración y los permisos de eliminación.
- Valida los prefijos de los gates, la cuota del inquilino y el conjunto completo de condiciones en el momento de la creación en la admisión.
- Realiza pruebas de carga en el scheduler, el autoscaler, el servidor de la API y los conflictos de parches del controlador, primero con lotes pequeños.
- Monitorea
scheduler_pending_pods{queue="gated"}, la antigüedad de los gates, la tasa de expiración, el rendimiento de liberación y la concurrencia por inquilino. - Ejecuta pruebas de reinicio del controlador, partición de red, revocación de permisos, cancelación de lotes y parches duplicados, y luego verifica el registro de auditoría.
Errores comunes y preguntas de seguimiento
Error 1: Añadir un gate después de la creación
La API solo permite gates en el momento de la creación y permite su eliminación posteriormente. Las condiciones dinámicas deben agregarse antes de la creación o esperarse mediante un objeto independiente antes de crear el Pod.
Error 2: Considerar SchedulingGated como un fallo de programación
Un Pod con gates no vacíos no ha sido intentado por el scheduler. Distingue entre gated, Unschedulable, ImagePullBackOff y la preparación de la aplicación.
Error 3: Usar la eliminación de gates como control de cuotas
Eliminar un gate solo permite un intento de programación; no garantiza recursos. Vuelve a verificar la cuota, la prioridad y la concurrencia del lote antes de la liberación.
Error 4: Omitir alertas de antigüedad y expiración de gates
Sin percentiles de antigüedad, un estancamiento silencioso es invisible. Registra la condición, el controlador responsable, el último progreso y una ruta de cancelación explícita.
Error 5: Ignorar el costo del autoscaler
Un gran conjunto de Pods no preparados puede desencadenar evaluaciones de escalado vertical/horizontal innecesarias. Usa métricas de colas con gates y control de flujo de liberación (throttling) para verificar que el costo realmente disminuya.