Static PV workflow

Mon, 01 Jan 0001 00:00:00 +0000

1. Create the PersistentVolume

apiVersion: v1
kind: PersistentVolume
metadata:
 name: lustre-static-pv
spec:
 capacity:
 storage: 10Gi
 accessModes:
 - ReadWriteMany
 storageClassName: klustre-csi-static
 persistentVolumeReclaimPolicy: Retain
 csi:
 driver: lustre.csi.klustrefs.io
 volumeHandle: lustre-static-pv
 volumeAttributes:
 source: 10.0.0.1@tcp0:/lustre-fs
 mountOptions: flock,user_xattr

volumeHandle just needs to be unique within the cluster; it is not used by the Lustre backend.
volumeAttributes.source carries the Lustre management target and filesystem path.

2. Bind with a PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: lustre-static-pvc
spec:
 accessModes:
 - ReadWriteMany
 storageClassName: klustre-csi-static
 volumeName: lustre-static-pv
 resources:
 requests:
 storage: 10Gi

Even though Lustre capacity is managed outside Kubernetes, the storage field should match the PV so the binder succeeds.

Volume attributes and mount options

Mon, 01 Jan 0001 00:00:00 +0000

`volumeAttributes`

Key	Example	Purpose
`source`	`10.0.0.1@tcp0:/lustre-fs`	Host(s) and filesystem path given to `mount.lustre`.
`mountOptions`	`flock,user_xattr`	Comma-separated Lustre mount flags.

Additional keys (e.g., subdir) can be added in the future; the driver simply passes the map to the Lustre helper script.

Storage class tuning

See the storage class reference for details on:

allowedTopologies – keep workloads on nodes with the Lustre label.
reclaimPolicy – typically Retain for static PVs.
mountOptions – defaults to flock and user_xattr, but you can add noatime, flock, user_xattr, etc.

Override mount options per volume by setting volumeAttributes.mountOptions. This is useful when a subset of workloads needs different locking semantics.