A storage vendor wants their proprietary networked storage system to work with Kubernetes so that clusters can provision, attach, and mount volumes from it, without the vendor needing their code merged into the Kubernetes source tree or tied to Kubernetes release cycles. Which standardised mechanism is designed to let such third-party storage integrate with Kubernetes in this decoupled way?
- AA Container Storage Interface driver deployed to the cluster Correct
- BA ConfigMap that describes the vendor's storage endpoints
- CAn in-tree volume plugin compiled into Kubernetes itself
- DA DaemonSet that mounts the vendor's storage on each node
Why A is correct: The Container Storage Interface defines a standard API so a vendor ships a CSI driver deployed to the cluster, letting Kubernetes provision, attach, and mount their storage without upstream code changes or release coupling.
Why B is wrong: A ConfigMap can hold configuration values a driver reads, which makes it seem relevant, but it cannot provision or attach volumes and provides no integration interface for a storage system.
Why C is wrong: In-tree plugins did once integrate storage, so this is a believable answer, but they require the vendor's code inside the Kubernetes tree and tie it to release cycles, which is exactly what the vendor wants to avoid.
Why D is wrong: A DaemonSet is often part of how a driver runs a component per node, which makes it tempting, but on its own it is just a workload controller and defines no standard storage integration contract.