The localvolumeprovisioner
addon uses the local volume static provisioner to manage persistent volumes for pre-allocated disks.
It does this by watching the /mnt/disks
folder on each host and creating persistent volumes in the localvolumeprovisioner
storage class for each disk that is discovered in this folder.
-
Persistent volumes with a ‘Filesystem’ volume-mode are discovered if they are mounted under
/mnt/disks
. -
Persistent volumes with a ‘Block’ volume-mode are discovered if a symbolic link to the block device is created in
/mnt/disks
.
Before you begin
Before starting this tutorial, you should verify the following:
-
You have access to a Linux, macOS, or Windows computer with a supported operating system version.
-
You have a provisioned
konvoy
cluster that is configured to use thelocalvolumeprovisioner
addon, but have not added any addons to the cluster.
For this tutorial, do not deploy using all of the default settings as described in the Quick start.
This distinction between provisioning and deployment is important because some addons depend on the storage class provided by the localvolumeprovisioner
addon and fail to start if it is not configured yet.
Provision the cluster and a volume
-
Create a pre-provisioned cluster by following the steps outlined in the choose pre-provisioned infrastructure topic.
-
Provision the local volume provisioner to watch for mounts in
/mnt/disks
on each host.For example, mount a
tmpfs
volume withansible
using theinventory.yaml
provided bykonvoy
by running the following command:ANSIBLE_HOST_KEY_CHECKING=False ansible -i inventory.yaml node -m shell -b -a "mkdir -p /mnt/disks/example-volume && mount -t tmpfs example-volume /mnt/disks/example-volume"
-
Verify the persistent volume by running the following command:
kubectl get pv --kubeconfig=admin.conf
The command displays output similar to the following:
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE local-pv-4c7fc8ba 30Gi RWO Delete Bound kubeaddons/data-elasticsearch-kubeaddons-data-3 localvolumeprovisioner 4m9s
-
Claim the persistent volume using PersistentVolumeClaim settings by running the following command:
cat <<EOF | kubectl create -f - kind: PersistentVolumeClaim apiVersion: v1 metadata: name: example-claim spec: accessModes: - ReadWriteOnce resources: requests: storage: 100Mi storageClassName: localvolumeprovisioner EOF
-
Reference the persistent volume claim in pods by running the following command:
cat <<EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: pod-with-persistent-volume spec: containers: - name: frontend image: nginx volumeMounts: - name: data mountPath: "/var/www/html" volumes: - name: data persistentVolumeClaim: claimName: example-claim EOF
-
Verify the persistent volume claim by running the following command:
kubectl get pvc --kubeconfig=admin.conf
The command displays output similar to the following:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE example-claim Bound local-pv-4c7fc8ba 3986Mi RWO localvolumeprovisioner 78s
-
Verify the persistent volume by running the following command:
kubectl get pv --kubeconfig=admin.conf
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE local-pv-4c7fc8ba 3986Mi RWO Delete Bound default/example-claim localvolumeprovisioner 15m
As soon as the persistent volume claim is deleted, the corresponding persistent volume resource is deleted (mandated by the “Delete” reclaim policy), causing all data on the volume to be removed.