Purpose
Ceph-CSI turns a Ceph cluster into a Kubernetes storage backend, and it does it with a cephx identity that every workload in the cluster is transitively trusting. The common failures are a StorageClass pointing at the wrong pool, a CSI identity with far more capability than it needs, and a multi-zone cluster scheduling a pod away from the zone its volume lives in. This checklist is the gate before workloads start requesting persistent volumes.
Order of work
The list runs in four passes. The driver pass is csi-driver: provisioner and
node plugins healthy on every node, since nothing else can be tested until they
are. The consumption pass is storageclass, topology and snapshots -
what a developer can actually ask for, and what the scheduler knows about where
those volumes live. The trust pass is caps, which is reviewed separately
from the driver’s health because a working driver and a correctly scoped driver
are different questions. The operations pass is monitoring.
Before you start
Have the workload-to-pool mapping, the zone layout if the cluster spans more than one, and the current cephx capabilities for each CSI identity.
Verification
The integration is ready when every critical item is checked and a test claim has been provisioned, mounted, written to, and deleted. Mark an item N/A rather than leaving it unchecked when it does not apply to this cluster.
Escalation
An over-broad CSI capability set is a security finding. Raise it with the platform and storage owners before granting cluster tenants access.