Persistent Storage: Nutanix CSI, Volumes, and Data Services
Nutanix CSI is the bridge between Kubernetes PVCs and Nutanix storage. The exam asks which storage type fits an access mode, how snapshots and clones are declared, and where CSI stops and Data Services begins.
What CSI provisions
- Nutanix Volumes - iSCSI block. StorageClass uses
storageType: NutanixVolumes. Access mode ReadWriteOnce; ReadWriteMany is not supported for block. - Nutanix Files - NFS.
storageType: NutanixFiles, supports ReadWriteMany for shared content. - The StorageClass names a storage container, a filesystem type, and optionally the iSCSI data-services IP and a segmented iSCSI network. Snapshots use a VolumeSnapshotClass with driver
csi.nutanix.com. - Volume expansion and cloning are supported; clones are storage-efficient.
Where Data Services fits
Nutanix Data Services for Kubernetes (NDK) sits above CSI: application-consistent snapshots with pre/post hooks, clones, backup to S3-compatible object storage, and cross-cluster restore for DR. Use NDK when a crash-consistent PV snapshot is not good enough for a database.
Worked example
A PVC is Pending on a new cluster. The StorageClass exists, so inspect events: storageContainer not found means the named container is absent in Prism Central; auth errors mean the CSI secret or Prism credentials are stale. If the pod is stuck ContainerCreating instead, the iSCSI data-services IP is usually unreachable from the node - check routing and the segmented network.
Traps
Requesting RWX from a Volumes StorageClass; forgetting the VolumeSnapshotClass so snapshots never bind; assuming CSI provides application consistency; ignoring the iSCSI data services IP during build; treating Nutanix Files as block storage for latency-sensitive databases.