Reference

• 1: Settings ConfigMap
• 2: Storage class parameters
• 3: Helm values
• 4: Parameter reference

1 - Settings ConfigMap

ConfigMap/klustre-csi-settings provides runtime configuration to the node daemonset. Each key maps to either an environment variable or a command-line argument.

To update any field:

kubectl -n klustre-system edit configmap klustre-csi-settings
kubectl rollout restart daemonset/klustre-csi-node -n klustre-system

Ensure any customized paths (e.g., pluginDir) match the volumes mounted in the daemonset spec.

2 - Storage class parameters

The manifests bundle a StorageClass named klustre-csi-static. It targets pre-provisioned Lustre exports and enforces node placement.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: klustre-csi-static
allowedTopologies:
- matchLabelExpressions:
  - key: lustre.csi.klustrefs.io/lustre-client
    values:
    - "true"
mountOptions:
- flock
- user_xattr
provisioner: lustre.csi.klustrefs.io
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer

Field summary

• provisioner – Must stay lustre.csi.klustrefs.io so PVCs bind to the Klustre driver.
• allowedTopologies – Uses the lustre.csi.klustrefs.io/lustre-client=true label to ensure only Lustre-capable nodes run workloads. Update the label key/value if you customize node labels.
• mountOptions – Defaults to flock and user_xattr. Add or remove Lustre options as needed (e.g., nolock, noatime).
• reclaimPolicy – Retain keeps the PV around when a PVC is deleted, which is typical for statically provisioned Lustre shares.
• volumeBindingMode – WaitForFirstConsumer defers binding until a pod is scheduled, ensuring topology constraints match the consuming workload.

Customization tips

• Create additional storage classes for different mount flag sets or topology labels. Ensure each class references the same provisioner.
• If you disable topology constraints, remove allowedTopologies, but be aware that pods might schedule onto nodes without Lustre access.
• For multi-cluster environments, consider namespacing storage class names (e.g., klustre-csi-static-prod).

3 - Helm values

The chart is published as oci://ghcr.io/klustrefs/charts/klustre-csi-plugin. Run helm show values oci://ghcr.io/klustrefs/charts/klustre-csi-plugin --version 0.1.1 for the full schema. This page summarizes frequently tuned fields.

Example override file

image:
  tag: 0.1.2
nodePlugin:
  logLevel: debug
  extraVolumeMounts:
    - name: host-etc
      mountPath: /host/etc
  extraVolumes:
    - name: host-etc
      hostPath:
        path: /etc
storageClass:
  mountOptions:
    - flock
    - user_xattr
    - noatime

Install with:

helm upgrade --install klustre-csi \
  oci://ghcr.io/klustrefs/charts/klustre-csi-plugin \
  --version 0.1.1 \
  --namespace klustre-system \
  --create-namespace \
  -f overrides.yaml

4 - Parameter reference

The node daemonset containers accept a small set of flags and environment variables. Most values are sourced from ConfigMap/klustre-csi-settings. Use this table as a quick lookup when you need to override behavior.

How to override

1. Edit the settings ConfigMap:

   kubectl -n klustre-system edit configmap klustre-csi-settings
   

   Change csiEndpoint, driverRegistrationArg, or logLevel as needed.

2. If you must customize PATH or LD_LIBRARY_PATH, edit the daemonset directly (Helm users can override nodePlugin.pathEnv or nodePlugin.ldLibraryPath values).

3. Restart the daemonset pods:

   kubectl rollout restart daemonset/klustre-csi-node -n klustre-system
   

Notes

• --node-id should stay aligned with the Kubernetes node name unless you have a strong reason to deviate (CSI treats it as the authoritative identifier).
• Changing CSI_ENDPOINT or driverRegistrationArg requires matching host path mounts in the daemonset (pluginDir, registrationDir).
• Increasing LOG_LEVEL to debug or trace is useful for troubleshooting but may emit sensitive information—reset it after collecting logs.