2.12 Kubernetes Storage Architecture

Kubernetes Storage Architecture is the specific internal arrangement of the components responsible for attaching storage to Pods, describing how the external provisioner, the Container Storage Interface driver, and the kubelet's own volume manager are layered together to provision, attach, and mount a volume onto the correct node before a Pod's containers start.

Provisioning Layer Architecture

External Provisioner Watching Claims

Dynamic provisioning is architected around an external provisioner component that watches for new PersistentVolumeClaims referencing a given StorageClass, and upon seeing one, calls out to the underlying storage system to create a matching volume, then creates the corresponding PersistentVolume object to represent it.

Decoupled from the Core Control Plane

This provisioning logic is architected to run as a separate component from the core control plane binaries, communicating with the API server the same way any other controller would, rather than being embedded inside the API server or controller manager itself.

Container Storage Interface Layer

Standardized Driver Contract

The Container Storage Interface (CSI) is architected as a standardized gRPC contract between Kubernetes and a storage driver, defining operations such as volume creation, attachment, and mounting, allowing storage vendors to implement a single driver usable across multiple container orchestration systems, not just Kubernetes.

Controller and Node Plugin Split

A CSI driver is architected as two cooperating parts: a controller plugin, running once or in a small number of replicas, handling volume provisioning and attachment decisions, and a node plugin, running on every node, handling the actual mounting of an already-attached volume into a Pod's filesystem.

Attach and Mount Sequencing

Attach-Detach Controller

An attach-detach controller, running as part of the control plane, is architected to track which volumes need to be attached to which nodes based on Pod scheduling decisions, issuing attach and detach operations to the CSI controller plugin accordingly.

kubelet Volume Manager

On the node itself, the kubelet's volume manager is architected to wait for a volume to be reported as attached, then invoke the CSI node plugin to mount it into the specific path a Pod's container expects, only allowing the container to start once this mount has completed.

Why This Layering Exists

Separating Slow, Infrequent Operations from Fast, Frequent Ones

This architecture separates provisioning and attachment, relatively slow and infrequent operations often involving external API calls to a storage backend, from mounting, a faster, more frequent operation performed locally on the node, allowing each to be optimized and scaled independently.

Storage Architecture Layering Diagram