Prompt and scope
The cluster uses Dynamic Resource Allocation (DRA) for GPUs or network devices. A container needs PCI, interface, or driver attributes for its allocated device but must not receive Kubernetes API access. Design the driver-to-container metadata path and explain versioning, isolation, failure, and upgrade behavior.
What interviewer is testing
- Whether you understand the responsibility boundary between a DRA driver, ResourceClaim, kubelet, and container.
- Whether you can specify metadata paths, generation timing, mounting, and cleanup lifecycle.
- Whether you handle untrusted driver fields, cross-node leakage, version compatibility, and Pod restarts.
- Whether you check feature state and supported versions instead of treating alpha as a stable contract.
Clarifying questions
- Is the metadata discovery data, network configuration, or sensitive material such as credentials?
- Which fields and schema versions are required, and can the application tolerate missing or late data?
- Do the cluster and nodes support DRA device metadata, and does the driver use the official library?
- What invalidates the file after reallocation, Pod restart, driver upgrade, or node failure?
A 30-second answer
I would have the driver expose only non-sensitive metadata for the current ResourceClaim and let kubelet generate versioned JSON during device preparation, mounted read-only at a documented path. The application reads a file, not the API; creation, update, unmount, and cleanup follow the Pod lifecycle. Validate fields and size, and make driver failures observable instead of exposing partial files. Because the capability is alpha, keep version detection and a fallback to environment variables, probes, or an older driver path.
Step-by-step design
1. Define the data and trust boundary
DRA allocates a device to a ResourceClaim, the driver knows the physical device, and the application consumes the result. Metadata should be limited to device attributes or interface details, never private keys, tokens, or cross-tenant identifiers. Bind driver input to the claim, request, and node so another device cannot be projected into the Pod.
2. Use a stable delivery mechanism
The documentation defines a well-known path inside the container and JSON files for device attributes. Use read-only mounts and deterministic directory levels so applications read files instead of querying the API. Include a schema or version field so applications can reject unknown versions and choose compatibility logic.
3. Handle lifecycle and failure
Create the file only after allocation and preparation succeed; remove it during unprepare, Pod deletion, or claim release. A generation, write, or JSON-validation failure must not expose a partial file. Report an observable driver or kubelet error and prevent the application from using invalid data. After restart, regenerate from the current claim rather than reusing a stale node file.
4. Plan upgrades and observability
Document a version matrix for the driver library, kubelet, node, and application. Monitor generation latency, failure rate, schema rejection, driver version, and Pod restarts; log claim, request, and node identifiers without metadata contents. Gate alpha upgrades with compatible schemas, feature gates, and a tested rollback.
Model high-quality answer
I would make device metadata a read-only projection of a DRA allocation. The driver writes only non-sensitive attributes for the current ResourceClaim and node; kubelet turns them into versioned JSON and mounts it read-only at a well-known path after device preparation. The application needs no Kubernetes API permission. Before writing, validate claim, request, node binding, an allowlist, and size; after writing, validate the schema. On failure, do not mount a partial file and expose an observable error. Clean up on release or Pod deletion and regenerate after restart. Since the capability is alpha, detect support, use a feature gate, keep an older-path or explicit-environment fallback, and monitor failures, latency, and driver versions rather than promising cross-version file stability.
Common mistakes
- Giving the container Kubernetes API access or overly broad RBAC.
- Exposing every driver field, including credentials or another tenant's device data.
- Omitting a version field, allowlist, and JSON schema validation.
- Keeping a stale node file after a Pod restart or claim release.
- Mounting an empty file after generation failure so the application assumes the device is usable.
- Treating an alpha feature as a stable API across all versions.
Follow-up questions and responses
Why not use environment variables directly?
Environment variables fit a few static values but are awkward for multiple devices, structured fields, and lifecycle changes. A read-only JSON file carries structure and explicit version and failure semantics.
How do you prevent cross-tenant leakage?
Use the claim, request, and node as the write authorization boundary; allow the driver to write only the allocated device, filter sensitive fields, isolate mounts per Pod, and test that another claim is unreadable.
How would you launch an alpha capability?
Confirm cluster version, feature state, driver library, and kubelet compatibility; canary a small node pool behind the feature gate, keep an application or driver fallback, and include schema changes in rollback and alerting.