Planteamiento y alcance
Un clúster multiinquilino tiene memoria de GPU y ancho de banda de NIC virtual que no pueden asignarse únicamente como dispositivos completos. La plataforma requiere que varios Pods compartan un único dispositivo, mientras que cada solicitud tiene un mínimo, un incremento (step), un límite superior y una identidad de asignación rastreable. Diseña el modelo de recursos y el flujo de extremo a extremo utilizando la capacidad consumible de Kubernetes DRA.
Asume Kubernetes 1.34 y un controlador (driver) capaz de aplicar límites de capacidad. El programador (scheduler) no debe sobreasignar ningún dispositivo. Kubernetes 1.34 promovió las APIs centrales de DRA a disponibilidad general (GA), mientras que la capacidad consumible es una funcionalidad en fase alfa; una respuesta sólida delimita con claridad las APIs estables, los feature gates y las garantías específicas del driver.
Qué evalúa el entrevistador
La respuesta debe asignar responsabilidades claras a DeviceClass, ResourceSlice, ResourceClaim, DeviceRequest, el scheduler y el driver. Debe establecer el invariante de que la capacidad asignada para un dispositivo nunca exceda su capacidad total, y explicar allowMultipleAllocations, RequestPolicy, ShareID y DistinctAttribute.
El entrevistador también verifica si confundes una decisión de programación exitosa con la limitación (throttling) a nivel de aplicación. Un diseño para producción requiere la aplicación de límites por parte del driver, reporte de estado, autorización de namespaces, recuperación ante fallas de nodos y un despliegue reversible.
Preguntas para clarificar
¿Se puede aislar el recurso?
Confirma si el hardware o el driver pueden aplicar el aislamiento. Si no es posible, la plataforma puede ofrecer cuotas blandas o asignación de dispositivos completos, pero no puede prometer QoS basándose únicamente en un campo de la API.
¿Cuáles son los límites de uso compartido y autorización?
Pregunta si distintos namespaces pueden compartir un mismo dispositivo, si se permite el acceso de administrador y qué atributos o capacidades de los dispositivos pueden leer los inquilinos. Las respuestas alteran los selectores, las validaciones de admisión y el alcance de auditoría.
¿Qué debe sobrevivir a una falla?
Aclara qué sucede tras un fallo de programación, un error de asignación del driver, la pérdida de un nodo o la recreación de un Pod: liberación, retención de lease o reencolamiento. Los reintentos transitorios y las fallas permanentes de hardware requieren estados diferenciados.
Estructura de respuesta en 30 segundos
«Defino primero el invariante de capacidad y el límite del inquilino. DeviceClass describe los dispositivos elegibles, ResourceSlice publica la capacidad y la política de solicitudes, y ResourceClaim expresa la necesidad del Pod. El scheduler selecciona un dispositivo sin exceder la capacidad; el driver utiliza un ShareID para aplicar el límite real de memoria o ancho de banda y reporta el estado. El uso compartido entre namespaces requiere autorización y auditoría. Cada liberación es idempotente. Realizo el despliegue por cada clase de dispositivo individualmente y comparo la capacidad asignada, los límites reales, la latencia de programación, la tasa de rechazo y el tiempo de recuperación».
Análisis detallado paso a paso
Paso uno: definir el modelo de recursos
DeviceClass describe el tipo de dispositivo y los selectores CEL. ResourceSlice publica cada dispositivo, sus atributos, capacidad y si se permiten múltiples asignaciones. ResourceClaim utiliza un DeviceRequest para indicar la clase y la capacidad. Mantén la capacidad total del dispositivo separada de la capacidad de la solicitud; un conteo de dispositivos de uno no es un valor de capacidad.
Paso dos: establecer el invariante de capacidad
Para cada dispositivo, rastrea la capacidad asignada, las unidades y la política de solicitudes. Si un dispositivo tiene 40 GiB y las solicitudes deben ser de al menos 5 GiB en pasos de 5 GiB, cada solicitud debe cumplir esos límites y todos los ShareIDs activos deben sumar como máximo 40 GiB. Las operaciones de liberación y reintento utilizan una versión de asignación para que las devoluciones de llamada (callbacks) duplicadas no resten dos veces.
Paso tres: describir el flujo de datos del scheduler y del driver
El scheduler lee ResourceSlice, filtra selectores, rangos de capacidad y allowMultipleAllocations, reserva un candidato y vincula el ResourceClaim. El driver recibe la asignación, crea un límite independiente indexado por ShareID, lo aplica al dispositivo y reporta datos dinámicos en el estado de ResourceClaim. Si la programación tiene éxito pero el driver rechaza la asignación, el controlador expone un estado reintentable o terminal; no debe marcar el Pod como Ready.
Paso cuatro: gestionar namespaces y dispositivos duplicados
Un dispositivo compartido no elimina el límite de namespace del ResourceClaim. La admisión debe restringir el uso de DeviceClass, el acceso de administrador y la configuración del driver. DistinctAttribute evita que un mismo claim seleccione el mismo dispositivo subyacente dos veces, como cuando dos interfaces de red deben conectarse a subredes distintas. Audita el inquilino, el claim, el ShareID, la capacidad y la versión de la política en lugar de limitarte al nombre final del dispositivo.
Paso cinco: diseñar la gestión de fallas y la recuperación
Tras el reinicio del driver, recupera los ShareIDs y los límites reales a partir de un estado duradero. Tras la pérdida de un nodo, marca las asignaciones como desconocidas y no otorgues inmediatamente la capacidad a otro Pod hasta que un lease, un aislamiento (device fence) o la confirmación del driver demuestren que la asignación anterior ya no existe. La eliminación de Pods, la expiración de claims y el rollback de programación deben ser repetibles. Las asignaciones existentes conservan su instantánea de política; los nuevos claims utilizan la política actualizada.
Paso seis: despliegue, SLOs y cálculo de capacidad
Asume 100 dispositivos de 40 GiB cada uno y un objetivo de utilización promedio del 70 por ciento. La capacidad programable lógica es de aproximadamente 2,800 GiB, lo cual no es una promesa de throughput; reserva margen para la sobrecarga del driver, la fragmentación y la tolerancia a fallos. Establece SLOs para el p99 de programación, el p99 de configuración del driver, la tasa de rechazo de capacidad y la convergencia de estado. Habilita el feature gate por cada DeviceClass. Compara el throughput, la latencia de cola, la fragmentación y la recuperación frente a la asignación de dispositivos completos.
Paso siete: comparar con una alternativa
Si el hardware solo admite particiones fijas, MIG o DeviceClasses preparticionadas resultan más simples y fáciles de validar, a costa de fragmentación y menor elasticidad. Si el driver no puede aplicar límites detallados, recurre a la asignación de dispositivos completos o a la expansión de capacidad; no asumas que un campo de capacidad proporciona aislamiento por sí solo.
Respuesta de ejemplo de alta calidad
Primero verifico si el dispositivo puede aplicar el aislamiento de capacidad. Si no puede, el diseño es meramente una selección declarativa y no ofrece garantías de QoS. Si puede, DeviceClass describe los dispositivos elegibles, ResourceSlice publica la capacidad y la política de solicitudes, y ResourceClaim transporta la solicitud del inquilino. El scheduler vincula el recurso solo cuando los selectores coinciden y la suma de capacidades se mantiene por debajo del límite del dispositivo; luego, el driver crea un límite con ámbito de ShareID y reporta el estado.
Defino la suma de capacidad, la versión de política y la liberación idempotente como invariantes explícitos. El uso compartido entre namespaces emplea admisión, autorización de administración y auditoría; DistinctAttribute evita la selección duplicada del dispositivo subyacente dentro de un mismo claim. Ante fallas del driver o del nodo, mantengo una asignación en estado desconocido hasta contar con aislamiento (fencing) o confirmación antes de reclamarla. El despliegue comienza con una sola clase y mide el p99 de programación, el p99 del driver, rechazos, aplicación real de límites y recuperación. El hardware de partición fija utiliza un diseño preparticionado.
Errores comunes
- Síntoma → colocar un valor de capacidad únicamente en ResourceClaim → Por qué falla → el driver podría no aplicar un límite real → Solución → validar la ruta de aplicación y el reporte de estado.
- Síntoma → usar el conteo de dispositivos como la suma de capacidad → Por qué falla → las solicitudes concurrentes generan sobreasignación o desperdician fragmentos → Solución → rastrear la capacidad asignada por dispositivo y por versión.
- Síntoma → tratar los dispositivos compartidos como un uso compartido sin restricciones entre inquilinos → Por qué falla → desaparecen los límites de namespace y de autorización → Solución → incorporar admisión, control de acceso de administrador y auditoría.
- Síntoma → liberar capacidad inmediatamente tras la pérdida de un nodo → Por qué falla → el driver anterior aún podría estar aplicando la asignación, causando una doble asignación → Solución → aplicar fencing, confirmar un lease o mantener un estado desconocido explícito.
- Síntoma → prometer SLOs estables para un feature gate en fase alfa → Por qué falla → el comportamiento de las APIs, del driver y de las actualizaciones varía → Solución → delimitar versiones y validar mediante un despliegue canary.
Preguntas de seguimiento y respuestas sólidas
Pregunta de seguimiento 1: Dos namespaces solicitan los últimos 10 GiB simultáneamente. ¿Cómo evitas una condición de carrera?
Utiliza una versión de ResourceSlice o un control de concurrencia optimista equivalente al reservar capacidad. Si la vinculación falla, vuelve a leer el estado actual y reintenta. Una devolución de llamada del driver no puede eludir el invariante del scheduler; el plano de control confirma la asignación final.
Pregunta de seguimiento 2: El driver reporta un ShareID, pero el Pod nunca inicia. ¿Qué sucede?
Separa el estado de asignación del estado de preparación (readiness) del Pod. Tras un tiempo de espera (timeout), el controlador ejecuta una liberación idempotente o entra en un estado visible para el operador reteniendo el ShareID, la versión del claim y el motivo. No descartes la capacidad ni los datos de auditoría solo porque el Pod no esté en estado Running.
Pregunta de seguimiento 3: La política cambia de un mínimo de 5 GiB a 10 GiB. ¿Cambian los claims existentes?
Las asignaciones completadas conservan la instantánea de la política bajo la cual fueron otorgadas; los nuevos claims utilizan la nueva política. El reequilibrio requiere un flujo de migración explícito, soporte en el driver para redimensionamiento y una secuencia reversible de liberación y reasignación.
Pregunta de seguimiento 4: ¿Cómo demuestras que el ancho de banda compartido se está limitando realmente?
Ejecuta una prueba base de inquilino único y una prueba de carga con múltiples ShareIDs con tráfico, nodos y versiones de driver fijos. Compara el throughput por inquilino, el p99, la pérdida de paquetes y el límite máximo de aplicación de políticas. El estado de ResourceClaim por sí solo no demuestra la QoS a nivel de hardware.