Klustre on KlustreFS

Overview

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

Klustre CSI Plugin is an open-source Container Storage Interface (CSI) node driver that lets Kubernetes workloads mount existing Lustre file systems. The project focuses on high-performance computing (HPC), AI/ML training, and media workloads that need shared ReadWriteMany semantics with the bandwidth of Lustre.

What does it provide?

Kubernetes-native storage – Exposes Lustre exports via CSI objects such as CSIDriver, PersistentVolume, and PersistentVolumeClaim.
Node daemonset – Runs a privileged pod on every Lustre-capable worker node to perform mounts and unmounts using the host’s Lustre client.
Static provisioning – Administrators define PersistentVolumes that point at existing Lustre paths (for example 10.0.0.1@tcp0:/lustre-fs) and bind them to workloads.
Helm and raw manifests – Install using the published manifests in manifests/ or the OCI Helm chart oci://ghcr.io/klustrefs/charts/klustre-csi-plugin.
Cluster policy alignment – Default RBAC, topology labels, and resource requests are tuned so scheduling is constrained to nodes that actually have the Lustre client installed.

Why would I use it?

Use the Klustre CSI plugin when you:

Requirements

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

Use this page when you need the full checklist (versions, node prep, and registry access) before installing Klustre CSI. The Quickstart and Introduction pages summarize this information, but this serves as a canonical reference.

Kubernetes cluster

Kubernetes v1.20 or newer with CSI v1.5 enabled.
Control plane and kubelets must allow privileged pods (hostPID, hostNetwork, SYS_ADMIN capability).
Cluster-admin kubectl access.

Lustre-capable worker nodes

Install the Lustre client packages (mount.lustre, kernel modules, user-space tools) on every node that will host Lustre-backed workloads.

Quickstart

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

Looking for the fastest path from zero to a mounted Lustre volume? Follow this TL;DR workflow, then explore the detailed installation pages if you need customization.

Requirements

Before you sprint through the commands below, complete the requirements checklist. You’ll need:

kubectl, git, and optionally helm.
Worker nodes with the Lustre client installed and reachable MGS/MDS/OSS endpoints.
Nodes labeled lustre.csi.klustrefs.io/lustre-client=true.
The klustre-system namespace plus optional GHCR image pull secret (see the requirements page for the canonical commands).

Step 1 — Install Klustre CSI

export KLUSTREFS_VERSION=main
kubectl apply -k "github.com/klustrefs/klustre-csi-plugin//manifests?ref=$KLUSTREFS_VERSION"

Step 2 — Verify the daemonset

Wait for the DaemonSet rollout to complete:

Kind Quickstart

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

This walkthrough targets Linux hosts with Docker/Podman because Kind worker nodes run as containers. macOS and Windows hosts cannot load kernel modules required by Lustre, but you can still observe the driver boot sequence. The shim below fakes mount.lustre with tmpfs so you can run the end-to-end demo locally.

Requirements

Docker 20.10+ (or a compatible container runtime supported by Kind).
Kind v0.20+.
kubectl v1.27+ pointed at your Kind context.
A GitHub personal access token with read:packages if you plan to pull images from GitHub Container Registry via an image pull secret (optional but recommended).

1. Create a Kind cluster

Save the following Kind configuration and create the cluster:

Label Lustre-capable nodes

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

The default klustre-csi-static storage class restricts scheduling to nodes labeled lustre.csi.klustrefs.io/lustre-client=true. Use this runbook whenever you add or remove nodes from the Lustre client pool.

Requirements

Cluster-admin access with kubectl.
Nodes already have the Lustre client packages installed and can reach your Lustre servers.

Steps

Identify nodes that can mount Lustre
```
kubectl get nodes -o wide
```
Cross-reference with your infrastructure inventory or automation outputs to find the node names that have Lustre connectivity.

Node maintenance checklist

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

1. Cordon and drain

kubectl cordon <node>
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data

Because the Klustre CSI daemonset is a DaemonSet, it is unaffected by --ignore-daemonsets, but draining ensures your workloads move off the node before reboot.

2. Verify daemonset status

kubectl get pods -n klustre-system -o wide | grep <node>

Expect the daemonset pod to terminate when the node drains and recreate once the node returns.

3. Patch or reboot the node

Apply OS updates, reboot, or swap hardware as needed.
Ensure the Lustre client packages remain installed (validate with mount.lustre --version).

4. Uncordon and relabel if necessary

kubectl uncordon <node>

If the node lost the lustre.csi.klustrefs.io/lustre-client=true label, reapply it after verifying Lustre connectivity.

Node preparation

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

Install the Lustre client stack

Every node that runs Lustre-backed pods must have:

mount.lustre and umount.lustre binaries (via lustre-client RPM/DEB).
Kernel modules compatible with your Lustre servers.
Network reachability to the Lustre MGS/MDS/OSS endpoints.

Verify installation:

mount.lustre --version
lsmod | grep lustre

Label nodes

The default storage class and daemonset use the label lustre.csi.klustrefs.io/lustre-client=true.

kubectl label nodes <node-name> lustre.csi.klustrefs.io/lustre-client=true

Remove the label when a node no longer has Lustre access:

Settings ConfigMap

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

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

Key	Description	Default
`csiEndpoint`	UNIX socket path used by the node plugin. Must align with kubelet’s plugin directory.	`unix:///var/lib/kubelet/plugins/lustre.csi.klustrefs.io/csi.sock`
`driverRegistrationArg`	Argument passed to the node-driver-registrar sidecar.	`--kubelet-registration-path=/var/lib/kubelet/plugins/lustre.csi.klustrefs.io/csi.sock`
`logLevel`	Verbosity for the Klustre CSI binary (`info`, `debug`, etc.).	`info`
`nodeImage`	Container image for the Klustre CSI node plugin.	`ghcr.io/klustrefs/klustre-csi-plugin:0.0.1`
`pluginDir`	HostPath where CSI sockets live.	`/var/lib/kubelet/plugins/lustre.csi.klustrefs.io`
`priorityClassName`	Priority class applied to the daemonset pods.	`system-node-critical`
`registrarImage`	Container image for the node-driver-registrar sidecar.	`registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.10.1`
`registrationDir`	HostPath where kubelet expects CSI driver registration files.	`/var/lib/kubelet/plugins_registry`

To update any field:

Static Lustre volume demo

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

Use these snippets as starting points for demos, CI smoke tests, or reproduction cases when you report issues.

Static Lustre volume demo

Creates a static PV/PVC pointing at 10.0.0.1@tcp0:/lustre-fs and mounts it in a BusyBox deployment.

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
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: lustre-static-pvc
spec:
 accessModes:
 - ReadWriteMany
 storageClassName: klustre-csi-static
 resources:
 requests:
 storage: 10Gi
 volumeName: lustre-static-pv
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: lustre-demo
spec:
 replicas: 1
 selector:
 matchLabels:
 app: lustre-demo
 template:
 metadata:
 labels:
 app: lustre-demo
 spec:
 containers:
 - name: app
 image: busybox
 command: ["sleep", "infinity"]
 volumeMounts:
 - name: lustre-share
 mountPath: /mnt/lustre
 volumes:
 - name: lustre-share
 persistentVolumeClaim:
 claimName: lustre-static-pvc

Validate

kubectl apply -f lustre-demo.yaml
kubectl exec deploy/lustre-demo -- df -h /mnt/lustre
kubectl exec deploy/lustre-demo -- sh -c 'echo "hello $(date)" > /mnt/lustre/hello.txt'

Delete when finished:

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.

Amazon EKS Notes

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

The AWS-oriented quickstart is under construction. It will cover:

Preparing EKS worker nodes with the Lustre client (either Amazon Linux extras or the FSx-provided packages).
Handling IAM roles for service accounts (IRSA) and pulling container images from GitHub Container Registry.
Connecting to FSx for Lustre file systems (imported or linked to S3 buckets) and exposing them via static PersistentVolumes.

Until the full write-up lands, adapt the Introduction flow by:

Installing the Lustre client on your managed node groups (e.g., with yum install lustre-client in your AMI or through user data).
Labeling the nodes that have Lustre access with lustre.csi.klustrefs.io/lustre-client=true.
Applying the Klustre CSI manifests or Helm chart in the klustre-system namespace.

Feedback on which AWS-specific topics matter most (FSx throughput tiers, PrivateLink, IAM policies, etc.) is welcome in the community discussions.

Bare Metal Notes

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

This guide will describe how to prepare on-prem or colocation clusters where you manage the operating systems directly (kernel modules, Lustre packages, kubelet paths, etc.). While the detailed walkthrough is in progress, you can already follow the general Introduction page and keep the following considerations in mind:

Ensure every node that should host Lustre-backed pods has the Lustre client packages installed via your distribution’s package manager (for example, lustre-client RPM/DEB).
Label those nodes with lustre.csi.klustrefs.io/lustre-client=true.
Grant the klustre-system namespace Pod Security admission exemptions (e.g., pod-security.kubernetes.io/enforce=privileged) because the daemonset requires hostPID, hostNetwork, and SYS_ADMIN.

If you are interested in helping us document more advanced configurations (multiple interfaces, bonded networks, RDMA, etc.), please open an issue or discussion in the GitHub repository.

Node integration flow

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

Daemonset host mounts

DaemonSet/klustre-csi-node mounts the following host paths:

/var/lib/kubelet/plugins and /var/lib/kubelet/pods – required for CSI socket registration and mount propagation.
/dev – ensures device files (if any) are accessible when mounting Lustre.
/sbin, /usr/sbin, /lib, /lib64 – expose the host’s Lustre client binaries and libraries to the container.

If your kubelet uses custom directories, update pluginDir and registrationDir in the settings ConfigMap.

CSI socket lifecycle

The node plugin listens on csiEndpoint (defaults to /var/lib/kubelet/plugins/lustre.csi.klustrefs.io/csi.sock).
The node-driver-registrar sidecar registers that socket with kubelet via registrationDir.
Kubelet uses the UNIX socket to call NodePublishVolume and NodeUnpublishVolume when pods mount or unmount PVCs.

If the daemonset does not come up or kubelet cannot reach the socket, run:

Share a dataset between prep and training jobs

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

This tutorial wires a simple data pipeline together:

Create a static Lustre PersistentVolume and bind it to a PersistentVolumeClaim.
Run a data-prep job that writes artifacts into the Lustre mount.
Start a training deployment that reads the prepared data.
Validate shared access and clean up.

Requirements

Klustre CSI Plugin installed and verified (see the Introduction).
An existing Lustre export, e.g., 10.0.0.1@tcp0:/lustre-fs.
kubectl access with cluster-admin privileges.

1. Define the storage objects

Save the following manifest as lustre-pipeline.yaml. Update volumeAttributes.source to match your Lustre target and tweak mountOptions if required.

Storage class parameters

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

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).

Update the Klustre CSI image

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

Use this guide to bump the Klustre CSI image version (for example, when adopting a new release).

Requirements

Cluster-admin access.
The new image is pushed to a registry reachable by your cluster (GHCR or a mirror).
The ghcr-secret or equivalent image pull secret already contains credentials for the registry.

Steps

Edit the settings ConfigMap

The manifests and Helm chart both reference ConfigMap/klustre-csi-settings. Update the nodeImage key with the new tag:

Upgrade guide

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

1. Review release notes

Check the klustre-csi-plugin GitHub releases for breaking changes, minimum Kubernetes versions, and image tags.

2. Update the image reference

Helm users: bump image.tag and nodePlugin.registrar.image.tag in your values file, then run helm upgrade.
Manifest users: edit manifests/configmap-klustre-csi-settings.yaml (nodeImage, registrarImage) and reapply the manifests.

See Update the node daemonset image for detailed steps.

3. Roll out sequentially

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

The daemonset restarts one node at a time, keeping existing mounts available.

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.

Collect diagnostics

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

When reporting an issue, provide the following artifacts so maintainers can reproduce the problem.

1. Capture pod logs

kubectl logs -n klustre-system daemonset/klustre-csi-node -c klustre-csi --tail=200 > klustre-csi.log
kubectl logs -n klustre-system daemonset/klustre-csi-node -c node-driver-registrar --tail=200 > node-driver-registrar.log

If a specific pod is failing, target it directly:

kubectl logs -n klustre-system <pod-name> -c klustre-csi --previous

2. Describe pods and daemonset

kubectl describe daemonset klustre-csi-node -n klustre-system > klustre-csi-daemonset.txt
kubectl describe pods -n klustre-system -l app.kubernetes.io/name=klustre-csi > klustre-csi-pods.txt

3. Export relevant resources

kubectl get csidriver lustre.csi.klustrefs.io -o yaml > csidriver.yaml
kubectl get storageclass klustre-csi-static -o yaml > storageclass.yaml
kubectl get configmap klustre-csi-settings -n klustre-system -o yaml > configmap.yaml

Remove sensitive data (e.g., registry credentials) before sharing.

Helm values

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

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.

Path	Default	Purpose
`image.repository`	`ghcr.io/klustrefs/klustre-csi-plugin`	Node plugin image repository.
`image.tag`	`0.1.1`	Node plugin tag.
`imagePullSecrets`	`[]`	Global image pull secrets applied to all pods.
`nodePlugin.pluginDir`	`/var/lib/kubelet/plugins/lustre.csi.klustrefs.io`	Host path for CSI sockets.
`nodePlugin.kubeletRegistrationPath`	`/var/lib/kubelet/plugins/lustre.csi.klustrefs.io/csi.sock`	Path passed to kubelet registrar.
`nodePlugin.logLevel`	`info`	Verbosity for the node binary.
`nodePlugin.resources`	`requests: 50m/50Mi`, `limits: 200m/200Mi`	Container resource settings.
`nodePlugin.registrar.image.repository`	`registry.k8s.io/sig-storage/csi-node-driver-registrar`	Sidecar repository.
`nodePlugin.registrar.image.tag`	`v2.10.1`	Sidecar tag.
`nodePlugin.extraVolumes` / `extraVolumeMounts`	`[]`	Inject custom host paths (e.g., additional libraries).
`storageClass.create`	`true`	Toggle creation of `klustre-csi-static`.
`storageClass.allowedTopologies[0].matchLabelExpressions[0].key`	`lustre.csi.klustrefs.io/lustre-client`	Node label key for placement.
`storageClass.mountOptions`	`["flock","user_xattr"]`	Default Lustre mount flags.
`settingsConfigMap.create`	`true`	Controls whether the chart provisions `klustre-csi-settings`.
`serviceAccount.create`	`true`	Create the node service account automatically.
`rbac.create`	`true`	Provision RBAC resources (ClusterRole/Binding).

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:

Install with Helm

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

The Helm chart is published under oci://ghcr.io/klustrefs/charts/klustre-csi-plugin.

1. Authenticate (optional)

If you use a GitHub personal access token for GHCR:

helm registry login ghcr.io -u <github-user>

Skip this step if anonymous pulls are permitted in your environment.

2. Install or upgrade

helm upgrade --install klustre-csi \
 oci://ghcr.io/klustrefs/charts/klustre-csi-plugin \
 --version 0.1.1 \
 --namespace klustre-system \
 --create-namespace \
 --set imagePullSecrets[0].name=ghcr-secret

Adjust the release name, namespace, and imagePullSecrets as needed. You can omit the secret if GHCR is reachable without credentials.

Parameter reference

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

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.

Component / flag	Env var	Purpose	Default source
`klustre-csi --node-id`	`KUBE_NODE_NAME`	Unique identifier sent to the CSI sidecars and kubelet. Normally the Kubernetes node name.	Downward API (`spec.nodeName`).
`klustre-csi --endpoint`	`CSI_ENDPOINT`	Path to the CSI UNIX socket served by the node plugin. Must match kubelet registration path.	`csiEndpoint` in the settings ConfigMap.
`klustre-csi --log-level`	`LOG_LEVEL`	Driver verbosity (`error`, `warn`, `info`, `debug`, `trace`).	`logLevel` in the settings ConfigMap.
`PATH`	`PATH`	Ensures `mount.lustre`, `umount.lustre`, and related tools are found inside the container.	`/host/usr/sbin:/host/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin`.
`LD_LIBRARY_PATH`	`LD_LIBRARY_PATH`	Points to host library directories required by the Lustre client binaries.	`/host/lib:/host/lib64:/host/usr/lib:/host/usr/lib64`.
`node-driver-registrar --csi-address`	n/a	Location of the CSI socket inside the pod.	`/csi/csi.sock`.
`node-driver-registrar --kubelet-registration-path`	n/a (derived from ConfigMap)	Host path where kubelet looks for CSI drivers.	`driverRegistrationArg` from the settings ConfigMap.

How to override

Edit the settings ConfigMap:

Install with kubectl/manifests

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

1. Install directly with Kustomize (no clone)

If you just want a default install, you don’t need to clone the repository. You can apply the published manifests directly from GitHub:

export KLUSTREFS_VERSION=main
kubectl apply -k "github.com/klustrefs/klustre-csi-plugin//manifests?ref=$KLUSTREFS_VERSION"

The manifests/ directory includes the namespace, RBAC, CSIDriver, daemonset, node service account, default StorageClass (klustre-csi-static), and settings config map.

2. Work from a local clone (recommended for customization)

If you plan to inspect or customize the manifests, clone the repo and work from a local checkout:

Contribution Guidelines

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

These instructions target the klustrefs/website repository. Follow them whenever you update content, navigation, or styling.

Toolchain

Static site generator: Hugo extended edition, v0.146.0 or newer.
Theme: Docsy.
Package manager: npm (used for Docsy assets).
Hosting: Netlify deploy previews triggered from pull requests.

Contribution workflow

Fork https://github.com/klustrefs/website.
Create a feature branch (docs/my-topic).
Make your edits (Markdown lives under content/en/...).
Run npm install once, then npm run dev or hugo server to preview locally.
Commit with clear messages (docs: add getting started guide).
Open a pull request against main. If the work is in progress, prefix the title with WIP.
Ensure the Netlify preview (deploy/netlify — Deploy preview ready!) renders correctly before requesting review.

All PRs need review by a maintainer before merging. We follow the standard GitHub review process.

Easy documentation with Docsy

Sat, 06 Oct 2018 00:00:00 +0000

This is a typical blog post that includes images.

The front matter specifies the date of the blog post, its title, a short description that will be displayed on the blog landing page, and its author.

Including images

Here’s an image (featured-sunset-get.png) that includes a byline and a caption.

Fetch and scale an image in the upcoming Hugo 0.43.
Photo: Riona MacNamara / CC-BY-CA

Second blog post

Sat, 06 Oct 2018 00:00:00 +0000

Text can be bold, italic, or ~~strikethrough~~. Links should be blue with no underlines (unless hovered over).

There should be whitespace between paragraphs. There should be whitespace between paragraphs. There should be whitespace between paragraphs. There should be whitespace between paragraphs.

There should be no margin above this first sentence.

Another Great Release

Thu, 04 Jan 2018 00:00:00 +0000

Text can be bold, italic, or ~~strikethrough~~. Links should be blue with no underlines (unless hovered over).

There should be whitespace between paragraphs. There should be whitespace between paragraphs. There should be whitespace between paragraphs. There should be whitespace between paragraphs.

There should be no margin above this first sentence.

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

title: Concepts description: Understand the Klustre CSI architecture, components, and data flow. weight: 2

This page explains how the Klustre CSI Plugin is structured so you can reason about what happens when volumes are created, mounted, or removed.

High-level architecture

Klustre CSI Plugin implements the CSI node service for Lustre file systems. It focuses on node-side operations only:

Kubernetes API Kubelet on each node
-------------- --------------------
PersistentVolume -> NodePublishVolume -> mount.lustre -> Pod mount
PersistentVolumeClaim NodeUnpublishVolume -> umount.lustre

There is no controller deployment or dynamic provisioning. Instead, administrators define static PersistentVolume objects that reference existing Lustre exports. The plugin mounts those exports inside pods when a PersistentVolumeClaim is bound to a workload.

Search Results

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