Kubernetes Storage Availability Basics

Kubernetes Storage Availability Basics is the set of reliability considerations governing persistent storage broadly, distinct from the StatefulSet-specific identity and volume-claim-template concerns covered elsewhere, addressing CSI driver availability as a dependency shared by every volume-mounting pod on a node, access mode constraints on concurrent use, reclaim policy as a data-safety decision, and the node-affinity constraints that limit where a volume-bound pod can be rescheduled.

CSI Driver as a Shared Dependency

Node Plugin Failure Affects Every Volume on That Node

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: csi-node-plugin

The CSI node plugin runs as a DaemonSet, and its failure on a given node affects every pod on that node attempting to mount or unmount a volume through that driver, not merely one workload; this makes CSI node plugin reliability itself, its own resource sizing, restart behavior, and priority class, a dependency shared broadly across every stateful workload scheduled to that node, following the same fleet-wide dependency reasoning discussed under daemon reliability basics.

Access Modes and Concurrent Availability

ReadWriteOnce vs. ReadWriteMany

accessModes: ["ReadWriteOnce"]

accessModes: ["ReadWriteMany"]

A ReadWriteOnce volume can be mounted read-write by only a single node at a time, meaning a pod using it cannot have multiple simultaneously running replicas across different nodes without a coordination layer above Kubernetes itself, a fundamental availability constraint distinct from the workload's own replica count; ReadWriteMany, when the underlying storage backend supports it (NFS, certain distributed filesystems), removes this constraint, enabling genuine multi-node concurrent access.

The ReadWriteOncePod Refinement

accessModes: ["ReadWriteOncePod"]

ReadWriteOncePod restricts a volume to a single pod, rather than merely a single node, closing a gap where ReadWriteOnce alone did not prevent two pods on the same node from mounting the same volume simultaneously, which could otherwise cause data corruption for workloads assuming genuinely exclusive access.

Multi-Attach Errors During Rescheduling

The Detach-Before-Attach Sequencing Requirement

Warning FailedAttachVolume Multi-Attach error for volume "pvc-abc123"
Volume is already exclusively attached to one node and can't be attached to another

When a pod using a ReadWriteOnce volume is rescheduled to a new node, the volume must be fully detached from the original node before it can attach to the new one; if the original node is unreachable (the exact scenario node failure tolerance addresses), this detachment can stall, producing a multi-attach error that delays the pod's replacement well beyond a typical stateless pod's rescheduling time.

Reclaim Policy as a Data-Safety Decision

Retain vs. Delete

apiVersion: storage.k8s.io/v1
kind: StorageClass
reclaimPolicy: Retain

Delete (the common default) removes the underlying storage automatically when its PersistentVolumeClaim is deleted, convenient for ephemeral or easily reprovisioned data but destructive for anything requiring manual recovery confirmation; Retain preserves the underlying volume even after the claim is deleted, requiring explicit administrator action to actually remove the data, a meaningfully safer default for storage classes backing genuinely important, hard-to-reproduce data.

Volume Health Monitoring

CSI Volume Health Reporting

status:
  conditions:
    - type: VolumeInUse
    - type: FileSystemResizePending

Some CSI drivers support reporting volume-level health conditions (degraded performance, an underlying disk failure detected by the storage backend) surfaced as pod events or conditions, giving earlier warning of an impending storage-level failure than waiting for the workload's own application-level errors to surface the same underlying problem.

Node Affinity Constraints on Volume-Bound Pods

Volumes Restrict Where a Pod Can Be Rescheduled

apiVersion: v1
kind: PersistentVolume
spec:
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: topology.kubernetes.io/zone
              operator: In
              values: ["us-east-1a"]

A PersistentVolume provisioned in a specific zone or attached to specific node-local storage carries a node affinity constraint that limits pod rescheduling to nodes satisfying it, meaning a volume-bound workload's actual failure tolerance is bounded by the volume's own placement constraints regardless of how broadly the pod's own scheduling rules would otherwise allow it to be rescheduled, a direct interaction with the zone failure tolerance concerns covered elsewhere.

Relationship to Stateful Reliability Basics and the Reliability Model

Storage availability basics addresses the general reliability properties of persistent storage as a shared cluster dependency, complementing the StatefulSet-specific identity and per-replica volume claim mechanics covered under stateful reliability basics: together they describe why stateful workloads consistently carry higher rescheduling latency and more constrained failure-domain flexibility than stateless ones, a direct consequence of the reliability model's redundancy principles being harder to apply when durable, exclusively-attached state is involved.