Entrevista de diseño de sistemas: ¿Cómo usarías Kubernetes v1.36 DRA para los recursos de Node Allocatable?

Pregunta y alcance

Un clúster de inferencia multi-tenant asigna aceleradores mediante Asignación Dinámica de Recursos (DRA). El controlador consume CPU, memoria o hugepages por dispositivo, y algunos dispositivos requieren alineación NUMA. Diseña un plan de Node Allocatable para Kubernetes v1.36 de modo que el programador contabilice conjuntamente las asignaciones de DRA y las solicitudes ordinarias de los Pods. Explica los mapeos de ResourceSlice, el estado del Pod, el despliegue, la monitorización y los límites de rollback.

La actualización oficial de DRA de la versión 1.36 describe los recursos de Node Allocatable como una primera iteración que incorpora CPU, memoria y hugepages gestionados por DRA a la contabilidad estándar del nodo. La funcionalidad todavía está en fase alfa, por lo que el diseño necesita salvaguardas para características experimentales.

Contexto y límites

Esta pregunta se centra en la contabilidad de recursos previa a la programación, las restricciones de topología y la seguridad del release. La asignación de hardware dentro del controlador y la tolerancia a fallos a nivel de negocio son dependencias externas; la respuesta debe indicar la versión de la API, el feature gate, la política de actualización (freshness), la consistencia del registro contable (ledger) y las condiciones de rollback.

Qué evalúa el entrevistador

• Si puedes conectar el registro contable de recursos, el programador, el controlador de DRA, el ResourceSlice y el estado del Pod.
• Si distingues la capacidad del dispositivo de los recursos del nodo consumidos por la asignación de un dispositivo y de las solicitudes ordinarias de los Pods.
• Si gestionas NUMA, hugepages, actualizaciones desordenadas, reinicios del controlador y ResourceSlices obsoletos.
• Si puedes desplegar un feature gate alfa con canarios, observabilidad, rollback y compatibilidad con controladores antiguos.
• Si las actualizaciones de estado están restringidas a subrecursos sintéticos de DRA y permisos con ámbito de nodo.

Respuesta de 30 segundos

“Haría que el controlador de DRA declare la contribución de CPU, memoria o hugepages de cada dispositivo en nodeAllocatableResourceMappings en un ResourceSlice. El programador fusiona las asignaciones de los claims vinculados con las solicitudes ordinarias de los Pods en el registro contable del nodo, contando cada claim una sola vez. Una huella fija puede usar allocationMultiplier; una huella basada en capacidad puede usar capacityKey. El estado del Pod expone el resultado a través de nodeAllocatableResourceClaimStatuses. Habilitaría DRANodeAllocatableResources solo en nodos canario, probaría NUMA, actualizaciones obsoletas y comportamiento en estado pendiente, y detendría nuevos claims si el registro contable o el mapeo se vuelven inseguros”.

Solución paso a paso

1. Definir el modelo de recursos. Almacena el ID del dispositivo, ResourceClaim, nodo, zona NUMA, nombre del recurso, unidad, versión del mapeo y tiempo de observación en un registro contable reproducible. Separa la capacidad del dispositivo del consumo de CPU, memoria y hugepages; un claim debe ingresar al registro contable una sola vez.

1. Publicar los mapeos de ResourceSlice. El controlador de DRA escribe nodeAllocatableResourceMappings en un ResourceSlice. Las claves de mapeo pueden representar CPU, memoria, ephemeral-storage o hugepages. Una huella fija por dispositivo se puede representar con allocationMultiplier; el consumo basado en capacidad puede usar capacityKey.

resourceSlice:
  nodeAllocatableResourceMappings:
    cpu:
      allocationMultiplier: 2
    memory:
      allocationMultiplier: 4Gi
    hugepages-2Mi:
      capacityKey: consumed

Esto solo ilustra la semántica del mapeo. Los tipos de campo y las unidades deben verificarse con el esquema actual de la API de Kubernetes y la implementación del controlador; no es un objeto listo para enviar.

1. Fusionar el registro contable de programación. El programador lee los ResourceSlices y los ResourceClaims vinculados, calcula la contribución de DRA y suma las solicitudes ordinarias de los Pods. Utiliza una clave de claim estable para la deduplicación. Si un ResourceSlice está obsoleto o falta su mapeo, mantén los nuevos Pods en estado pendiente y genera una alerta en lugar de programar sobre una capacidad antigua.

1. Manejar NUMA y el ordenamiento. Registra la afinidad NUMA y las versiones. Confirma una asignación, liberación o actualización de ResourceSlice solo cuando el orden de versiones del nodo sea monotónico. Durante el reinicio de un controlador, reconstruye los mapeos antes de aceptar nuevos claims para evitar una doble asignación temporal.

1. Exponer el estado y la telemetría. El status.nodeAllocatableResourceClaimStatuses del Pod registra el estado de los recursos de nodo del claim. Realiza un seguimiento de la capacidad del registro contable, el uso, la antigüedad del mapeo, los motivos de estado pendiente, el recuento de rechazos por duplicación y los fallos de ubicación en NUMA. Correlaciona las escrituras de estado y las decisiones de programación con el UID del claim.

1. Canario y rollback. Una vez confirmada la compatibilidad del plano de control, el programador y el controlador, habilita DRANodeAllocatableResources únicamente para los nodos canario. Prueba ResourceSlices, Pods ordinarios mezclados con claims, reinicios de nodos, actualizaciones de controladores y liberaciones. En caso de fallo, detén los nuevos claims, preserva los vínculos existentes, exporta el registro contable, repara los mapeos y reanuda por versión. No asumas que todos los clústeres pueden habilitar de forma segura una capacidad alfa.

1. Límite de seguridad. Otorga al controlador de DRA solo los permisos sobre subrecursos sintéticos necesarios para sus actualizaciones de estado. Los controladores locales al nodo utilizan verbos conscientes del nodo y RBAC de mínimo privilegio. Las escrituras fallidas deben alertar y reintentarse; ampliar los permisos no repara la inconsistencia del registro contable.

Respuesta modelo

Trataría Node Allocatable como un registro contable de recursos versionado. El controlador declara las contribuciones de los dispositivos a CPU, memoria o hugepages en nodeAllocatableResourceMappings; las contribuciones fijas utilizan allocationMultiplier y las contribuciones basadas en capacidad utilizan capacityKey. El programador lee los claims vinculados, fusiona la contribución de cada claim con las solicitudes ordinarias de los Pods y deduplica por UID de claim para que el uso del dispositivo y el uso de recursos del nodo no se cuenten dos veces.

El registro contable almacena el nodo, el dispositivo, NUMA, la versión del mapeo y el tiempo de observación. Ante un ResourceSlice obsoleto, una regresión de versión o el reinicio de un controlador, los nuevos Pods permanecen en estado pendiente en lugar de programarse sobre capacidad antigua. El nodeAllocatableResourceClaimStatuses del Pod admite lectura y diagnóstico, pero no reemplaza las comprobaciones de consistencia del registro contable.

Debido a que la versión 1.36 sigue en alfa, habilitaría DRANodeAllocatableResources primero en nodos canario y probaría claims y Pods mixtos, NUMA, reinicio de nodos, liberación y actualizaciones de controladores. El rollback detiene los nuevos claims, preserva los vínculos existentes y exporta el registro contable antes de reparar el mapeo. El RBAC se limita a subrecursos sintéticos de DRA y permisos con ámbito de nodo.

Errores comunes

• Error: Deducir la CPU del nodo una vez por dispositivo y otra vez tras el reintento de un claim → Por qué falla: no hay una clave de idempotencia estable → Solución: deduplicar por UID de claim, ID de dispositivo y versión del mapeo.
• Error: Enviar el YAML ilustrativo como un objeto de API de producción → Por qué falla: el esquema de campos y las unidades están versionados → Solución: verificar la API de ResourceSlice y la versión del controlador.
• Error: Continuar usando capacidad antigua mientras un ResourceSlice no está disponible → Por qué falla: los datos obsoletos pueden generar sobreasignación → Solución: usar una ventana de actualización (freshness window) y mantener los nuevos claims pendientes tras expirar.
• Error: Habilitar el feature gate alfa en todas partes al mismo tiempo → Por qué falla: la compatibilidad y el rollback no están probados → Solución: canarios, métricas, detención de admisión de claims y un registro contable recuperable.
• Error: Ampliar RBAC para solucionar un error de escritura de estado → Por qué falla: amplía la autoridad sin corregir la consistencia de los datos → Solución: usar subrecursos sintéticos, verbos conscientes del nodo y registros de auditoría.

Preguntas de seguimiento y respuestas

¿Cuándo deberías usar allocationMultiplier frente a capacityKey?

Usa allocationMultiplier cuando cada asignación consume una cantidad fija de CPU o memoria. Usa capacityKey cuando el consumo varía con la capacidad del dispositivo o la carga de trabajo, con una semántica auditable y definida por el controlador. Congela las unidades y el versionado para cualquiera de las dos opciones.

¿Cómo evitas contar dos veces las solicitudes ordinarias de los Pods y los mapeos de DRA?

Mantén un único registro contable: las solicitudes ordinarias ingresan al flujo de solicitudes, mientras que las contribuciones de DRA ingresan al flujo de asignaciones identificadas por el UID del claim. El programador aplica cada mapeo una sola vez y registra la fuente y la versión. Las claves duplicadas se rechazan y se alertan.

¿Debe reanudarse la programación inmediatamente después del reinicio de un controlador?

No. Reconstruye los ResourceSlices, valida los claims vinculados, confirma las versiones monotónicas y la capacidad, y luego admite nuevos claims. Durante la reconstrucción, preserva los vínculos existentes y mantén los nuevos Pods en estado pendiente.

¿Cómo demuestras que la ubicación en NUMA preserva la contabilidad?

Reproduce eventos entre diferentes zonas NUMA, en la misma zona NUMA, de reintento de liberación y de reinicio de nodos. Compara el total del nodo, los subregistros de NUMA y el estado del Pod. Realiza un seguimiento de los fallos de ubicación, la divergencia del registro contable, el tiempo en estado pendiente y el recuento de rechazos por duplicación.

¿Cuándo se puede promover una capacidad alfa?

Requiere cobertura de controladores compatibles, simulacros de rollback, reproducciones de reinicios y actualizaciones de nodos, una ventana de observación con cero divergencias y SLOs explícitos de capacidad y de estado pendiente. Una compilación exitosa o una prueba en un solo nodo no es suficiente para un despliegue completo.

Referencias

• Actualización de DRA en Kubernetes v1.36 (Blog de Kubernetes)
• Feature Gates (Documentación de Kubernetes)
• API de ResourceSlice (Documentación de Kubernetes)
• API de Pod (Documentación de Kubernetes)
• Guía de endurecimiento de DRA (Documentación de Kubernetes)

Lista de verificación para la entrevista

Dibuja el flujo desde el controlador hacia ResourceSlice, claim, programador, registro contable de Node Allocatable y estado del Pod. Luego agrega idempotencia, versiones, NUMA, canarios y mínimo privilegio.

Conclusión en una sola frase

DRA Node Allocatable tiene éxito cuando un único registro contable versionado y seguro ante rollbacks contabiliza la contribución real de recursos de nodo de cada claim.

Sigue practicando

Extiende el mapeo a ResourceClaims multinodo y explica cómo la topología, la actualización de datos (freshness) y la recuperación modifican las decisiones de programación.