Provision a static local volume

Learn how to provision a static local volume for a Konvoy cluster

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 the localvolumeprovisioner 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

  1. Create a pre-provisioned cluster by following the steps outlined in the choose pre-provisioned infrastructure topic.

  2. Provision the local volume provisioner to watch for mounts in /mnt/disks on each host.

    For example, mount a tmpfs volume with ansible using the inventory.yaml provided by konvoy 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"
    
  3. 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
    
  4. 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
    
  5. 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
    
  6. 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
    
  7. 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.