- Kubernetes v1.16+
- LINODE_API_TOKEN: Personal Access Token with:
- Read/Write access to Volumes
- Read/Write access to Linodes
- Sufficient "Expiry" for continued use
- LINODE_REGION: Linode Region
Generate a Personal Access Token (PAT) using the Linode Cloud Manager.
There are two primary methods to deploy the CSI Driver:
- Using Helm (Recommended)
- Using kubectl
- The deployment assumes that the Linode Cloud Controller Manager (CCM) is running.
helm repo add linode-csi https://linode.github.io/linode-blockstorage-csi-driver/
helm repo update linode-csi
export LINODE_API_TOKEN="...your Linode API token..."
export REGION="your preferred region"
helm install linode-csi-driver \
--set apiToken="${LINODE_API_TOKEN}" \
--set region="${REGION}" \
linode-csi/linode-blockstorage-csi-driver
See helm install for command documentation.
helm uninstall linode-csi-driver
See helm uninstall for command documentation.
export LINODE_API_TOKEN="...your Linode API token..."
export REGION="your preferred region"
helm upgrade linode-csi-driver \
--install \
--set apiToken="${LINODE_API_TOKEN}" \
--set region="${REGION}" \
linode-csi/linode-blockstorage-csi-driver
See helm upgrade for command documentation.
- Modify variables using the
--set var=value
flag or by providing a customvalues.yaml
with-f custom-values.yaml
. - For a comprehensive list of configurable variables, refer to
helm-chart/csi-driver/values.yaml
.
Use a custom values.yaml
file to override variables to avoid template rendering errors.
apiVersion: v1
kind: Secret
metadata:
name: linode
namespace: kube-system
stringData:
token: "your linode api token"
region: "your preferred region"
Apply the secret to the cluster:
kubectl apply -f secret.yaml
Verify the secret was created:
kubectl get secret linode -n kube-system
Apply the deployment manifest (changes on the main branch):
kubectl apply -f https://raw.githubusercontent.com/linode/linode-blockstorage-csi-driver/master/internal/driver/deploy/releases/linode-blockstorage-csi-driver.yaml
To deploy a specific release version:
kubectl apply -f https://raw.githubusercontent.com/linode/linode-blockstorage-csi-driver/master/internal/driver/deploy/releases/linode-blockstorage-csi-driver-v0.5.3.yaml
-
Storage Classes
- Default Storage Class:
linode-block-storage-retain
Learn More- Reclaim Policy:
Retain
- Volumes created by this CSI driver will default to using the
linode-block-storage-retain
storage class if one is not specified. Upon deletion of all PersistentVolumeClaims, the PersistentVolume and its backing Block Storage Volume will remain intact. - This behavior can be modified in the
csi-storageclass.yaml
section of the deployment by toggling thestorageclass.kubernetes.io/is-default-class
annotation.
- Volumes created by this CSI driver will default to using the
- Reclaim Policy:
- Alternative Storage Class:
linode-block-storage
- Reclaim Policy:
Delete
- This policy will delete the volume when the PersistentVolumeClaim (PVC) or PersistentVolume (PV) is deleted.
- Reclaim Policy:
You can verify the storage classes with:
kubectl get storageclass
- Default Storage Class:
-
Linode Cloud Controller Manager (CCM)
- The deployment assumes that the Linode CCM is initialized and running.
- If you intend to run this on a cluster without the Linode CCM, you must modify the init container script in the
cm-get-linode-id.yaml
ConfigMap and remove the line containingexit 1
.
-
Maximum Volume Attachments
- The Linode Block Storage CSI Driver supports attaching more than 8 volumes for larger Linode instances. The maximum number of attachable volumes (including instance disks) scales with the instance's memory, up to a maximum of 64 attachments.
Instance Type Memory/RAM Max. Volume + Disk Attachments g6-nanode-1 1GB 8 g6-standard-1 2GB 8 g6-standard-2 4GB 8 g6-standard-4 8GB 8 g6-standard-6 16GB 16 g6-standard-8 32GB 32 g6-standard-16 64GB 64 g6-standard-20 96GB 64 g6-standard-24 128GB 64 g6-standard-32 192GB 64 This scaling also applies to dedicated, premium, GPU, and high-memory instance classes. The number of attached volumes is a combination of block storage volumes and instance disks (e.g., the boot disk).
Note: To support this change, block storage volume attachments are no longer persisted across reboots.