Planteamiento y alcance
El clúster utiliza Dynamic Resource Allocation (DRA) para GPUs o dispositivos de red. Un contenedor necesita atributos de PCI, interfaz o driver para su dispositivo asignado, pero no debe recibir acceso a la API de Kubernetes. Diseña la ruta de metadatos del driver al contenedor y explica el versionado, el aislamiento, las fallas y el comportamiento durante las actualizaciones.
Qué evalúa el entrevistador
- Si comprendes el límite de responsabilidad entre un driver de DRA, ResourceClaim, kubelet y el contenedor.
- Si puedes especificar las rutas de metadatos, el momento de generación, el montaje y el ciclo de vida de limpieza.
- Si manejas campos no confiables del driver, fugas entre nodos, compatibilidad de versiones y reinicios de Pods.
- Si verificas el estado de la funcionalidad y las versiones compatibles en lugar de tratar una versión alpha como un contrato estable.
Preguntas de clarificación
- ¿Los metadatos son datos de descubrimiento, configuración de red o material sensible como credenciales?
- ¿Qué campos y versiones de esquema se requieren, y puede la aplicación tolerar datos faltantes o tardíos?
- ¿El clúster y los nodos admiten metadatos de dispositivos DRA, y el driver utiliza la biblioteca oficial?
- ¿Qué invalida el archivo tras una reasignación, reinicio del Pod, actualización del driver o falla del nodo?
Una respuesta de 30 segundos
Haría que el driver exponga únicamente metadatos no sensibles para el ResourceClaim actual y que kubelet genere JSON versionado durante la preparación del dispositivo, montado como solo lectura en una ruta documentada. La aplicación lee un archivo, no la API; la creación, actualización, desmontaje y limpieza siguen el ciclo de vida del Pod. Valida los campos y el tamaño, y haz que las fallas del driver sean observables en lugar de exponer archivos parciales. Dado que la funcionalidad está en alpha, mantén la detección de versiones y un mecanismo de respaldo (fallback) hacia variables de entorno, sondeos o una ruta de driver anterior.
Diseño paso a paso
1. Definir el límite de datos y confianza
DRA asigna un dispositivo a un ResourceClaim, el driver conoce el dispositivo físico y la aplicación consume el resultado. Los metadatos deben limitarse a atributos del dispositivo o detalles de la interfaz, nunca claves privadas, tokens o identificadores entre diferentes tenants. Vincula la entrada del driver al claim, a la solicitud y al nodo para que no se pueda proyectar otro dispositivo en el Pod.
2. Utilizar un mecanismo de entrega estable
La documentación define una ruta conocida dentro del contenedor y archivos JSON para los atributos del dispositivo. Utiliza montajes de solo lectura y niveles de directorio deterministas para que las aplicaciones lean archivos en lugar de consultar la API. Incluye un campo de esquema o versión para que las aplicaciones puedan rechazar versiones desconocidas y elegir la lógica de compatibilidad.
3. Gestionar el ciclo de vida y las fallas
Crea el archivo solo después de que la asignación y la preparación se completen con éxito; elimínalo durante la des-preparación (unprepare), la eliminación del Pod o la liberación del claim. Una falla de generación, escritura o validación de JSON no debe exponer un archivo parcial. Reporta un error observable del driver o de kubelet y evita que la aplicación use datos inválidos. Después de un reinicio, regenera a partir del claim actual en lugar de reutilizar un archivo de nodo obsoleto.
4. Planificar actualizaciones y observabilidad
Documenta una matriz de versiones para la biblioteca del driver, kubelet, el nodo y la aplicación. Monitorea la latencia de generación, la tasa de fallas, el rechazo de esquemas, la versión del driver y los reinicios de Pods; registra identificadores de claim, solicitud y nodo sin el contenido de los metadatos. Controla las actualizaciones alpha con esquemas compatibles, feature gates y un rollback probado.
Respuesta modelo de alta calidad
Haría que los metadatos del dispositivo sean una proyección de solo lectura de una asignación de DRA. El driver escribe solo atributos no sensibles para el ResourceClaim y el nodo actuales; kubelet los convierte en JSON versionado y los monta en modo de solo lectura en una ruta conocida tras la preparación del dispositivo. La aplicación no necesita permisos en la API de Kubernetes. Antes de escribir, valida el claim, la solicitud, la vinculación del nodo, una lista de permitidos y el tamaño; después de escribir, valida el esquema. Ante una falla, no montes un archivo parcial y expón un error observable. Limpia tras la liberación o eliminación del Pod y regenera tras un reinicio. Como la funcionalidad está en alpha, detecta el soporte, usa un feature gate, mantén un fallback a rutas anteriores o entornos explícitos, y monitorea fallas, latencia y versiones del driver en lugar de prometer estabilidad de archivos entre versiones.
Errores comunes
- Dar al contenedor acceso a la API de Kubernetes o permisos RBAC excesivamente amplios.
- Exponer todos los campos del driver, incluidas credenciales o datos de dispositivos de otros tenants.
- Omitir un campo de versión, la lista de permitidos y la validación del esquema JSON.
- Mantener un archivo de nodo obsoleto tras el reinicio de un Pod o la liberación de un claim.
- Montar un archivo vacío tras una falla de generación, haciendo que la aplicación asuma que el dispositivo es utilizable.
- Tratar una funcionalidad alpha como una API estable entre todas las versiones.
Preguntas de seguimiento y respuestas
¿Por qué no usar variables de entorno directamente?
Las variables de entorno se adaptan a unos pocos valores estáticos, pero resultan incómodas para múltiples dispositivos, campos estructurados y cambios de ciclo de vida. Un archivo JSON de solo lectura ofrece estructura y semántica explícita de versionado y fallas.
¿Cómo evitas la fuga de información entre tenants?
Usa el claim, la solicitud y el nodo como límite de autorización de escritura; permite que el driver escriba solo el dispositivo asignado, filtra campos sensibles, aísla los montajes por Pod y prueba que otro claim sea ilegible.
¿Cómo lanzarías una funcionalidad alpha?
Confirma la versión del clúster, el estado de la funcionalidad, la biblioteca del driver y la compatibilidad de kubelet; realiza un despliegue canary en un grupo pequeño de nodos detrás del feature gate, mantén un respaldo a nivel de aplicación o driver, e incluye los cambios de esquema en el rollback y las alertas.