Entrevista de diseño de sistemas: ¿Cómo utilizarías el estado de salud de dispositivos de Kubernetes para gobernar fallas de GPU?

Consigna y contexto

Una plataforma de inferencia de GPU multi-inquilino utiliza Kubernetes Device Plugins y Dynamic Resource Allocation (DRA). Cuando un controlador detecta una tarjeta desconectada, el sistema anterior expone el error únicamente en los registros del nodo; el Pod se reinicia y reclama repetidamente el mismo dispositivo. Diseña la gobernanza de fallas en torno a allocatedResourcesStatus en el Pod .status: los operadores y controladores deben poder ver la salud del dispositivo, poner en cuarentena las tarjetas dañadas, manejar Unknown de manera segura y evitar la eliminación masiva a partir de una señal transitoria.

Kubernetes v1.36 promueve el estado de salud de los recursos a fase Beta. Las notas de la versión oficial indican que el estado del Pod reporta la salud de los dispositivos asignados y que kubectl describe pod puede exponer Unhealthy o Unknown; el mecanismo abarca tanto las rutas tradicionales de Device Plugins como las de DRA.

Qué evalúa el entrevistador

• ¿Puedes distinguir entre el éxito de la asignación, la salud del dispositivo, la preparación del contenedor (readiness) y los SLO del negocio?
• ¿Puedes diagramar el flujo de datos entre el controlador de dispositivo, kubelet, el estado del Pod, los controladores, el planificador y el sistema de alertas?
• ¿Puedes tratar Unhealthy y Unknown de forma diferenciada en lugar de convertir una observación faltante en una falla definitiva?
• ¿Puedes diseñar una cuarentena idempotente, concesiones (leases), reintentos, límites de tasa y reingreso tras la recuperación?
• ¿Puedes explicar que el estado es una señal de diagnóstico y no un reemplazo automático de las políticas de planificación o de los sondeos de negocio?

Preguntas para aclarar primero

• ¿Qué controladores generan información de salud y cuáles son sus retrasos de actualización y periodos de latido (heartbeat)?
• Un Pod puede contener varias tarjetas; si una falla, ¿el trabajo puede degradarse parcialmente o debe migrarse como una unidad completa?
• ¿Unknown significa una desconexión transitoria, una caída del nodo o un comportamiento no compatible del controlador? ¿Cuál es la ventana de tolerancia?
• ¿La cuarentena se aplica por dispositivo, nodo, ResourceClaim o carga de trabajo del inquilino, y quién puede levantarla?
• ¿Los trabajos cuentan con puntos de control (checkpoints), confirmaciones idempotentes y un presupuesto de reintentos? ¿Cuánto recambio (churn) de GPU puede provocar la migración?

Respuesta en 30 segundos

"Trataría la salud del dispositivo como una entrada de estado y no como un comando para eliminar el Pod. Después de que el controlador de dispositivo y kubelet actualizan allocatedResourcesStatus, un controlador agrega la información por ID de dispositivo: Unhealthy entra en cuarentena y genera alertas, mientras que Unknown recibe primero una ventana de tolerancia de latidos. Claves de idempotencia y concesiones (leases) bloquean nuevas asignaciones, y los trabajos con puntos de control migran con límites de tasa por nodo. La recuperación ejecuta un sondeo y una pequeña prueba canario antes de la liberación. Validaría la antigüedad del estado, las falsas cuarentenas, el éxito de la migración y los SLO del negocio".

Análisis detallado paso a paso

1. Definir el modelo de estados. Registra la identidad del dispositivo, Pod, contenedor, ResourceClaim, nodo, valor de salud, mensaje, hora de observación y versión del estado. Mantén Unhealthy (falla confirmada) separado de Unknown (no confirmada) para que un solo booleano no maneje todas las automatizaciones.

1. Construir el flujo de datos. DRA o un Device Plugin asigna un dispositivo a un Pod; kubelet escribe la salud reportada por el controlador en el estado del Pod. Un observador de estado vigila los cambios en los Pods, desduplica por clave de dispositivo y escribe un directorio de dispositivos reproducible. Las alertas y los controladores leen ese directorio en lugar de escanear la API de forma independiente.

1. Poner en cuarentena nuevas asignaciones. Para un dispositivo no saludable confirmado, crea un registro de cuarentena interno y exclúyelo de las extensiones del planificador, de la selección de ResourceClaim o de las vistas de capacidad de los nodos. No edites el estado del Pod ni conviertas inmediatamente un evento aislado en un Node NotReady. La acción de cuarentena requiere una razón, un actor y una expiración.

1. Gestionar trabajos en ejecución. El controlador verifica los puntos de control y las confirmaciones idempotentes antes de adquirir una concesión de migración. Un trabajo recuperable detiene nuevas solicitudes, guarda un punto de control, libera el dispositivo y se reconstruye en un dispositivo saludable. Un trabajo no recuperable preserva evidencia y notifica al inquilino. Solo un flujo de migración puede poseer un dispositivo y un trabajo.

1. Proteger ante Unknown. Unknown puede provenir de kubelet, del controlador de dispositivo o de una interrupción de red en el nodo. Aplica una ventana de tolerancia basada en latidos y un retroceso exponencial; alerta durante la ventana y restringe la asignación solo después de que expire. Para una interrupción completa del nodo, utiliza las concesiones del nodo y la detección de fallas existente en lugar de inferir que todos los dispositivos están rotos a partir del estado de un único Pod.

1. Recuperar y verificar. Cuando un dispositivo vuelve a reportarse como saludable, ejecuta un sondeo del controlador, un trabajo pequeño y una ventana de estabilidad antes de levantar la cuarentena. Supervisa la antigüedad del estado, la duración de Unknown, la tasa de falsas cuarentenas, el éxito de la migración, el tiempo de GPU inactiva y los errores del negocio. Reproduce eventos duplicados y fuera de orden, y reinicia el controlador para probar la recuperación.

Device health event
  -> Pod status observer
  -> deduplicate by (node, deviceID, statusVersion)
  -> device quarantine record with lease and expiry
  -> scheduler/claim filter excludes unhealthy device
  -> checkpointed workload migration
  -> probe + canary
  -> release quarantine

Respuesta modelo

Crearía un directorio de estados a nivel de dispositivo que vincule el controlador de dispositivo, kubelet, el Pod, el ResourceClaim y el trabajo. Unhealthy es una falla confirmada, por lo que creo una cuarentena respaldada por concesiones (leases) con tiempo de expiración, bloqueo nuevas asignaciones y genero alertas. Unknown entra primero en una ventana de tolerancia de latidos y solo restringe la asignación tras expirar dicha ventana. El observador desduplica por ID de dispositivo, y un controlador reiniciado reconstruye su estado a partir de eventos y registros persistidos en lugar de banderas en memoria.

La migración depende de puntos de control, confirmaciones idempotentes y la prioridad del inquilino. Los trabajos recuperables generan puntos de control, liberan el dispositivo y se reconstruyen en uno saludable; los trabajos no recuperables preservan evidencia. La recuperación comienza con un sondeo del controlador y un pequeño canario. Las extensiones del planificador, la selección en DRA y las vistas de capacidad consumen el registro de cuarentena, mientras que el estado permanece como una entrada de diagnóstico y no como readiness o un SLO de negocio. Demostraría la solidez del diseño mediante métricas de antigüedad del estado, falsos positivos, éxito de la migración y errores de negocio.

Errores comunes

• Síntoma: Eliminar todos los Pods cuando el estado es Unknown → Por qué falla: Una brecha de observación transitoria se convierte en una perturbación masiva del clúster → Solución: Utilizar una concesión, una ventana de latidos y límites de tasa.
• Síntoma: Poner en cuarentena únicamente el nodo y omitir la identidad del dispositivo → Por qué falla: Una sola tarjeta dañada inhabilita dispositivos saludables → Solución: Claves de registros por dispositivo y ResourceClaim, escalando al nodo solo cuando esté justificado.
• Síntoma: Editar el estado del Pod para hacer que un dispositivo parezca saludable → Por qué falla: Se corrompe la fuente de la verdad y la recuperación puede ser incorrecta → Solución: Preservar el estado de kubelet y crear un estado de cuarentena auditable por separado.
• Síntoma: Devolver un dispositivo recuperado a carga completa de inmediato → Por qué falla: Una recuperación transitoria o un controlador inestable pueden fallar nuevamente → Solución: Sondear, probar con canario y luego aumentar gradualmente.

Preguntas de seguimiento y respuestas

Falló una GPU pero el Pod posee otras. ¿Debe migrarse solo una parte del trabajo?

Primero verifica si el framework admite reducción dinámica y revinculación. Si el modelo requiere una topología de dispositivos fija, migra el trabajo completo. Si puede dividirse en fragmentos (sharding), mueve solo el fragmento afectado preservando la semántica de ResourceClaim y de los puntos de control para los dispositivos restantes.

El valor es Healthy pero el mensaje de estado es antiguo. ¿Qué haces?

Separa el valor de salud de la antigüedad del estado. Tras superar el límite de latidos, realiza la transición a Unknown en lugar de tratar un Healthy obsoleto como prueba actual; las alertas y las barreras de planificación utilizan la antigüedad.

¿Cómo evitas que múltiples controladores migren el mismo trabajo?

Utiliza una clave de idempotencia construida a partir del ID de dispositivo, el ID de trabajo y la versión de estado, junto con una concesión con expiración o una actualización de versión optimista. Un controlador que pierde la concesión se detiene, y un reemplazo se reanuda a partir del registro persistido.

¿Cuándo puede regresar el dispositivo al grupo de capacidad?

Un reporte saludable del controlador es necesario pero insuficiente. Exige un sondeo del dispositivo, un trabajo pequeño, una ventana de estabilidad y un motivo de cuarentena cerrado; cualquier falla extiende la cuarentena y bloquea la liberación forzada manual.

Referencias

• Kubernetes v1.36: Haru
• Kubernetes v1.36: More Drivers, New Features, and the Next Era of DRA
• Kubernetes v1.34: Pods Report DRA Resource Health
• Documentación de Dynamic Resource Allocation

Lista de verificación para la entrevista

Dibuja el flujo desde el controlador de dispositivo hasta el estado del Pod, el observador, la cuarentena y el filtro de planificación. Separa Unhealthy de Unknown y luego añade concesiones, puntos de control, límites de tasa, un canario de recuperación y métricas.

Conclusión en una sola frase

La salud de los dispositivos hace que las fallas de hardware sean observables en Kubernetes, pero una recuperación segura todavía requiere cuarentena a nivel de dispositivo, barreras de protección para Unknown, migración idempotente y reutilización escalonada.