Static Provisioning

Static provisioning lets you mount an existing flexFS volume into Kubernetes pods. This works with both the Enterprise and Community editions.

Prerequisites

The flexFS CSI driver is installed
A flexFS volume already exists (created during server installation or via configure.flexfs)
You have a Secret containing the admin server address and an account token

Create the PersistentVolumeClaim and PersistentVolume

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: flexfs-static
  namespace: default
spec:
  storageClassName: ""
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 8Ei

apiVersion: v1
kind: PersistentVolume
metadata:
  name: flexfs-static
spec:
  storageClassName: ""
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 8Ei
  csi:
    driver: csi.flexfs.io
    volumeHandle: <volume-name>
    nodePublishSecretRef:
      name: flexfs-secret
      namespace: default
  claimRef:
    name: flexfs-static
    namespace: default

Replace <volume-name> with the name of your existing flexFS volume.

Key fields

Field	Description
`storageClassName: ""`	Empty string prevents Kubernetes from using a default StorageClass.
`csi.driver`	Must be `csi.flexfs.io`.
`csi.volumeHandle`	The name of the flexFS volume to mount. This is the volume name as shown in `configure.flexfs`, or `free` for Community edition.
`csi.nodePublishSecretRef`	Reference to the Kubernetes Secret containing `adminAddr` and `token`.
`claimRef`	Pre-binds the PV to the PVC so they pair immediately.

Create the Secret

The Secret must contain at minimum the adminAddr and token fields. For Enterprise, configure.flexfs show account <id> displays the account token. For Community, use the free server address and the accountToken value of the free server’s credentials file:

apiVersion: v1
kind: Secret
metadata:
  name: flexfs-secret
  namespace: default
stringData:
  adminAddr: <admin-addr>
  token: <account-token>

For encrypted volumes, add the secret field:

stringData:
  adminAddr: <admin-addr>
  token: <account-token>
  secret: <encryption-secret>

See the Secret field reference for all supported fields.

Apply

kubectl apply -f secret.yaml
kubectl apply -f static-volume.yaml

Use in a pod

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: app
      image: ubuntu:latest
      command: ["sleep", "infinity"]
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: flexfs-static

Read-only mounting

To mount the volume as read-only, set readOnly: true on the pod’s claim reference:

volumes:
  - name: data
    persistentVolumeClaim:
      claimName: flexfs-static
      readOnly: true

Alternatively, list ReadOnlyMany as the PV’s first access mode (and request it in the claim). The driver mounts such a volume read-only for every pod, whatever the pod’s readOnly setting.

Setting readOnly: true under the PV’s spec.csi has no effect: for CSI volumes the kubelet takes the read-only flag from the pod’s persistentVolumeClaim.readOnly, not from the PV source. An ro entry in mountOptions is stripped by the driver, so that is not an alternative route either.

A published mount that is read-write when its PV’s access mode calls for read-only stays read-write until the pod is removed; the driver logs a warning.

Passing mount options

You can pass additional mount options via mountOptions on the PV:

spec:
  csi:
    driver: csi.flexfs.io
    volumeHandle: <volume-name>
    nodePublishSecretRef:
      name: flexfs-secret
      namespace: default
  mountOptions:
    - acl
    - xattr
    - verbose

Statically provisioned volumes and resizing

A pre-existing volume’s size is yours to manage, and a static PV keeps it that way. Kubernetes refuses to resize a claim that was not dynamically provisioned by an expansion-capable StorageClass — an attempt returns only dynamically provisioned pvc can be resized — so the ordinary static setup shown above cannot be resized at all.

Two things follow if you deviate from it. A static PV that names an expansion-enabled StorageClass and carries a controllerExpandSecretRef is resizable, and editing that claim would raise the quota on your pre-existing volume; leave one or both off if the volume’s size is managed out of band. And a volume with no quota cannot be expanded in any case — the driver refuses rather than reporting a meaningless capacity — so a volume you created without --maxBlocks is inert to resizing however the PV is written.

A static PV’s capacity field is informational: nothing enforces it. Quotas live on the volume, set with configure.flexfs update volume --maxBlocks/--maxInodes.

Multiple volumes on the same node

The driver imposes no per-node volume limit. Each volume gets its own base FUSE mount under <kubeletDir>/flexfs/<volume-name>/ — where <kubeletDir> is the configured kubelet root, /var/lib/kubelet by default — and multiple pods referencing the same volume share that one base mount through bind mounts, so the cost of extra pods on the same volume is a bind mount rather than another FUSE session.

Two consequences follow from sharing that base mount:

The mountOptions in effect are those of the PV that first mounted the volume on the node. They apply to every later pod that uses the volume there, even through a different PV. Read-write and read-only pods use separate base mounts, so each of the two takes its options independently.
A node identifies a volume by its name alone. Volume names are unique within an account, not across accounts, so if PVs for two accounts both name a volume data, a node mounts only one of them at a time. Publishing the other fails with volume "data" is mounted on this node for another account until the pods using the first are gone. Give such volumes distinct names, or schedule their pods on different nodes. A Community edition volume is always named free, so pods that use two different Community servers cannot run on the same node at the same time.