This section introduces the Qumulo Container Storage Interface (CSI) driver and explains how you can connect your Kubernetes cluster to your Qumulo cluster by using the Qumulo CSI driver.
To automate container storage, enable dynamic volumes, and help you scale your application container images based on usage and workflows, Qumulo uses the CSI driver to connect the Kubernetes orchestrator to Qumulo persistent storage. (In comparison, for example, the NFS CSI Driver for Kubernetes requires unprivileged NFS access for dynamic volumes and doesn’t support volume sizing and expansion.)
For general driver information, see the Container Storage Interface (CSI) Specification.
Supported Features
The Qumulo CSI Driver supports:
-
Static and dynamic (expansion) provisioning over NFSv3
-
The following Persistent Volume Claim access modes:
-
ReadOnlyMany -
ReadWriteMany -
ReadWriteOnce -
ReadWriteOncePodNote
TheReadWriteOncePodaccess mode requires Kubernetes 1.27 (and higher). Earlier Kubernetes versions reject this access mode when you create a Persistent Volume Claim.
-
-
NFSv4.1
Important
Even when you enable NFSv4.1 for your Qumulo cluster, you must explicitly configure NFSv4.1 to work with Kerberos.
Unsupported Features
Requirements
-
A Qumulo cluster
-
Kubernetes 1.22 (and higher)
Connecting Your Qumulo Cluster to Kubernetes
This section explains how you can configure, provision, and mount Qumulo storage for each Pod (a logical wrapper for a container) on Kubernetes by using dynamic provisioning. This gives you more control over persistent volume capacity.
Step 1: Install the Qumulo CSI Driver
- The installation pulls the CSI driver's sidecar containers from
registry.k8s.ioand the CSI driver's container frompublic.ecr.aws. If a firewall, HTTP proxy, or private registry mirror limits the registries from which your Kubernetes nodes can pull images, allow both registries (or mirror the images into your private registry) before installing the CSI driver. - For information about upgrading an existing installation, see Upgrading the Qumulo CSI Driver.
-
Connect to a machine that has
kubectland can access your Kubernetes cluster. -
Download the
.zipfile or use one of the following commands.-
S3
aws s3 cp s3://csi-driver-qumulo/deploy_v1.2.0.zip ./ -
HTTP with
wget(Linux)wget https://csi-driver-qumulo.s3.us-west-2.amazonaws.com/deploy_v1.2.0.zip -
HTTP with
curl(macOS)curl -O https://csi-driver-qumulo.s3.us-west-2.amazonaws.com/deploy_v1.2.0.zip
-
-
Extract the contents of the
.zipfile. -
Run the shell script and specify the current release version. For example:
-
Linux:
cd deploy_v1.2.0 chmod +x install-driver.sh ./install-driver.sh -
Windows:
cd deploy_v1.2.0 install-driver.bat
The script configures Qumulo’s prebuilt Elastic Container Registry (ECR) image (from
public.ecr.aws/qumulo/csi-driver-qumulo:v1.2.0) and installs it on your Kubernetes system. -
Step 2: Configure Volume and NFS Export Paths
To prepare your Qumulo cluster for connecting to your Kubernetes cluster, you must first configure your volume and NFS export paths on your Qumulo cluster by setting the following parameters for each storage class that you define.
Write down the paths for the following YAML keys for the
storageclass-qumulo.yaml file that you use when you create a storage class in step 5.-
For
storeRealPath, from the root of the Qumulo file system, create a directory for storing volumes on your Qumulo cluster, for example/csi/volumes1.Note
Because the CSI driver doesn’t create the directory listed in thestoreRealPathkey automatically, this directory must exist below the NFS export and must not be the NFS export itself. -
For
storeExportPath, create the NFS export for hosting the persistent volume. -
If your cluster has more than one tenant, specify the tenant ID that contains your NFS export for the
tenantIdparameter.Note
- If you have only one tenant, it isn't necessary to specify the `tenantId` parameter.
- You must provide the value for
tenantIdas a string. For example:"2".
Step 3: Configure Credentials
To connect your Kubernetes cluster to your Qumulo cluster, you must either use an existing account or create a new account for the CSI driver to communicate with the Qumulo API.
-
Configure a username and password for a user on your Qumulo cluster.
-
The configured username must have the following file permissions:
-
Lookup on
storeRealPath -
Create directories in
storeRealPath -
Create and modify quotas:
-
PRIVILEGE_QUOTA_READ -
PRIVILEGE_QUOTA_WRITE
-
-
Read NFS exports:
PRIVILEGE_NFS_EXPORT_READ -
Perform
TreeDeleteoperations on volume directories:PRIVILEGE_FS_DELETE_TREE_WRITE
-
For more information, see Role-Based Access Control (RBAC) with Qumulo Core on Qumulo Care.
Step 4: Create and Configure Secrets
To allow the CSI driver to operate with your Qumulo cluster, you must create and configure Secrets. You can use one of the following methods:
-
Basic authentication with a username and password
For example:
kubectl create secret generic cluster1-login \ --type="kubernetes.io/basic-auth" \ --from-literal=username=myusername \ --from-literal=password=mypassword \ --namespace=kube-system -
A bearer token (or access token)
For example:
TOKEN='access-v1:zNTc5D0zWTdNi/KsZo620fu71TweGh47u+S/5NbV...' kubectl create secret generic cluster1-login \ --from-literal=access_token="$TOKEN" \ --namespace=kube-systemFor more information, see Creating and Using Bearer Tokens to Authenticate Qumulo REST API Calls.
Configuring the CSI Driver to Verify Your Cluster’s TLS Certificate
The CSI driver communicates with your Qumulo cluster by using the Qumulo REST API over HTTPS. By default, the CSI driver accepts any TLS certificate, including self-signed certificates, without verifying the identity of the cluster that presents it.
- We strongly recommend configuring verification if your cluster's certificate allows it. Verifying your cluster's TLS certificate can help prevent someone from posing as your cluster in order to capture the CSI driver's credentials.
- Before you configure verification for a storage class in use, confirm that your certificate is current.
- When verification isn't configured, the CSI driver logs the informational warning
TLS certificate verification is DISABLED for the Qumulo cluster.for each connection to your cluster. - When verification is configured, it uses strict rules: If your cluster's certificate is expired, or the certificate's name doesn't match the
servervalue specified for your storage class, provisioning stops with anx509error until you correct the certificate or relax your verification.
To configure verification, add one of the following optional keys to the Secret that you created. The following table outlines the CSI driver’s behavior and key configuration process for each type of cluster certificate issuer.
If your storage class names different Secrets for provisioning and for expansion, add the keys to both Secrets.
| Cluster Certificate Issuer | CSI Driver Behavior | Key Configuration |
|---|---|---|
Public CA |
The CSI driver verifies the certificate against standard public CAs. |
Set the |
|
Self-Signed or Your Organization's Internal CA Note
Because a self-signed certificate provides the same protection as a certificate from a public certificate authority (CA), it isn’t necessary to replace a self-signed certificate to configure verification. |
The CSI driver verifies the certificate against only the |
Specify the If a certificate isn't available, you can retrieve it by using the When you create your Secret, specify a path to the certificate. Important
For example: |
|
Any Issuer Note
The system retains the current behavior without a log warning. |
The CSI driver skips verification and doesn't log the warning. |
Set the Important
Don't specify a value for ca_cert and set tls_insecure to true at the same time. |
Step 5: Create a Storage Class
To link your Kubernetes cluster to your Qumulo cluster, you must create a storage class on your Kubernetes cluster.
-
Begin with the example Qumulo storage class configuration.
Note
- In the following example, it is possible to use a fully qualified domain name (FQDN) for the
parameters: server:entry. - For such a configuration, all Kubernetes nodes in the cluster must be able to resolve FQDNs.
--- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: cluster1 provisioner: qumulo.csi.k8s.io parameters: server: 203.0.113.0 storeRealPath: "/regions/4234/volumes" storeExportPath: "/some/export" csi.storage.k8s.io/provisioner-secret-name: cluster1-login csi.storage.k8s.io/provisioner-secret-namespace: kube-system csi.storage.k8s.io/controller-expand-secret-name: cluster1-login csi.storage.k8s.io/controller-expand-secret-namespace: kube-system reclaimPolicy: Delete volumeBindingMode: Immediate mountOptions: - nolock - proto=tcp - vers=3 allowVolumeExpansion: true - In the following example, it is possible to use a fully qualified domain name (FQDN) for the
-
Edit the configuration for your Qumulo cluster.
-
Name your storage class.
-
Specify server and
storeRealPath. -
Specify
storeExportPath. -
(Optional) Specify
tenantId.Note
You must provide the value fortenantIdas a string. For example:"2". -
Configure the following parameters to point to the Secrets that you have created and configured in the namespace in which you installed the CSI driver:
-
controller-expand-secret-name -
controller-expand-secret-namespace -
provisioner-secret-name -
provisioner-secret-namespace
-
-
Specify the NFS
mountOptions. For example:mountOptions: - nolock - proto=tcp - vers=3 -
To create the class, apply the configuration. For example:
kubectl create -f storageclass-qumulo.yaml -
Step 6: Create a Persistent Volume Claim (PVC) and Apply it to a Pod
To apply a PVC to a Pod dynamically, you must first configure and create it.
-
Begin with the example PVC configuration.
--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: claim1 spec: accessModes: - ReadWriteOnce storageClassName: cluster1 resources: requests: storage: 1Gi -
Edit the configuration for your PVC.
-
Name your claim.
-
Change
storageClassNameto the name of your storage class. -
Specify the capacity in
spec.resources.requests.storage. This parameter lets you create a quota on your Qumulo cluster. -
To create the claim, apply the configuration. For example:
kubectl apply -f dynamic-pvc.yaml
-
-
Use the claim in a Pod or a Deployment. For example:
--- apiVersion: v1 kind: Pod metadata: name: claim1-pod spec: volumes: - name: cluster1 persistentVolumeClaim: claimName: claim1 containers: - name: claim1-container image: ... volumeMounts: - mountPath: "/cluster1" name: cluster1Important
When the PVC is released, a tree-delete is initiated on the Qumulo cluster for the directory that the PVC indicates. To prevent this behavior, setreclaimPolicytoRetainin yourStorageClassconfiguration. -
You can launch and use your container image.
Upgrading the Qumulo CSI Driver
To upgrade the CSI driver, you can install a new version without removing the previous installation.
- The upgrade doesn't require changing your existing storage classes, Persistent Volume Claims, or Secrets and doesn't disrupt any running workloads.
- The CSI driver's components restart one at a time and any volumes that are already mounted remain mounted, readable, and writable throughout the upgrade.
- The process pauses new volume creation for a few seconds while the CSI driver's controller restarts.
Prerequisites
Before you begin, confirm that your Kubernetes nodes can pull images from registry.k8s.io.
- Driver versions 1.2.0 (and higher) pull their sidecar containers from
registry.k8s.io. If a firewall, HTTP proxy, or private registry mirror limits the registries from which your Kubernetes nodes can pull images, allow both registries (or mirror the images into your private registry) before installing the CSI driver. - If the registry is unreachable, the new driver Pods remain in the
ImagePullBackOffstate until it becomes reachable and the previous driver version continues to run.
To Upgrade the Qumulo CSI Driver
-
Download the
.zipfile for the new driver version and extract its contents. -
Run the installation script.
Important
- The script applies four manifests, including the CSI driver's role-based access control (RBAC) configuration.
- Updating only the container image references leaves the previous permissions in place and can prevent volume provisioning.
- If the CSI driver can't read Secrets, ensure that the current CSI driver's RBAC manifest has been applied and isn't being overridden by an older manifest.
cd deploy_v1.2.0 chmod +x install-driver.sh ./install-driver.sh -
(Optional) To monitor the installation process, run the following commands.
kubectl -n kube-system rollout status \ deployment/csi-qumulo-controller kubectl -n kube-system rollout status \ daemonset/csi-qumulo-node -
To verify the upgrade, create a test Persistent Volume Claim against one of your storage classes, confirm that it reaches the
Boundstate, and then delete it.Any
ReadWriteOncePodclaims that an earlier driver version left in thePendingstate complete automatically after the upgrade. -
(Optional) If you created the
access-secretsrole and thedefault-to-secretsrole binding while creating and configuring Secrets for an earlier version of the CSI driver, you may remove them. Version 1.2.0 (and higher) grants this access within the CSI driver’s own RBAC configuration.kubectl delete rolebinding \ default-to-secrets --namespace kube-system kubectl delete role \ access-secrets --namespace kube-system
To roll back to the previous driver version, run install-driver.sh from the previous version’s deployment files.
The additional permissions that version 1.2.0 grants are backwards-compatible with earlier versions.