Create Rok Volumes

Rok volumes allow you to run your stateful applications over fast, node-local storage, e.g., local NVMe SSDs.

To achieve this, Rok employs the topology-aware dynamic provisioning feature of Kubernetes. This feature allows Kubernetes to make intelligent decisions when dynamically provisioning volumes by getting scheduler input on the best place to provision a volume for a Pod.

Rok leverages this feature by marking its volumes as being bound to a specific node, and not equally accessible by all nodes in a Kubernetes cluster. The cluster is thus segmented into "nodes" and a given volume is accessible only from one of these "nodes".

To create a Rok volume use the rok storage class:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: rok
  # Uncomment to set Rok as the default storage class. Note that you cannot
  # have more than one default storage class:
  # https://kubernetes.io/docs/tasks/administer-cluster/change-default-storage-class/#changing-the-default-storageclass
  #annotations:
  #  storageclass.kubernetes.io/is-default-class: "true"
# List of extra mount options, e.g., discard
mountOptions: []
parameters:
  rok/allow-auto-recovery: "false"
  rok/sysfs/queue/read_ahead_kb: "128"
  rok/use-dmclone: "true"
  rok/wait-for-hydration: "false"
provisioner: rok.arrikto.com
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Parameters

If the pre-defined storage class doesn't meet your requirements, you can create your own customized storage class, based on the pre-defined one.

Rok supports the following storage class parameters to further customize Rok volumes:

  • rok/allow-auto-recovery
    • Type: string
    • Values: "true" | "false"
    • Default: "false"

    Enable volume auto-recovery for volumes bound on lost nodes.

  • rok/wait-for-hydration
    • Type: string
    • Values: "true" | "false"
    • Default: "true"

    Wait for hydration to complete, when creating a volume from a snapshot.

  • rok/use-dmclone
    • Type: string
    • Values: "true" | "false"
    • Default: "false"

    Perform hydration in kernel space ("true") or in user space ("false"), when creating a volume from a snapshot.

  • rok/pre-mount-verification
    • Type: string
    • Values: "true" | "false"
    • Default: "true"

    Verify the integrity of the filesystem on the volume, before mounting it. If the filesystem has errors, Rok refuses to mount it.

  • rok/pre-clone-verification
    • Type: string
    • Values: "true" | "false"
    • Default: "true"

    Verify the integrity of the filesystem on the snapshot, before creating a volume from a snapshot.

  • rok/post-clone-verification
    • Type: string
    • Values: "true" | "false"
    • Default: "true"

    Verify the integrity of the filesystem on the cloned volume, after creating a volume from a snapshot. The verification runs if rok/wait-for-hydration is also set to "true".

  • rok/sysfs/queue/*
    • Type: string

    Change Queue sysfs settings for the underlying block device. For example, you can set the read-ahead size.

Note

To affect only a specific Rok volume you can specify any of the storage class parameters as a PVC annotation.

Volume Auto-Recovery

Since volumes created by Rok are bound to a specific node, if that node goes away, for example, node failure, these volumes will be inaccessible.

Rok supports a mechanism to automatically recover these volumes and move them to a new node. Rok will roll back the volume to its latest snapshot, which means it will populate it with the data it contained at the time the snapshot was taken.

To take advantage of this feature set the rok/allow-auto-recovery PVC/SC parameter to "true".

Volume Hydration

Rok supports provisioning volumes from snapshots. The new volume will be pre-populated with data from the snapshot. The process of populating the volume with the snapshot data is called "Volume Hydration".

You can either

  • Wait for the volume hydration to finish, before making the volume available for use.

    This ensures that all data are available locally when the application starts using the volume, and I/O performance is unaffected by the hydration process.

  • Make the volume available right away, and let the hydration happen in the background, in parallel with application I/O.

    This allows for instant snapshot clones at the cost of slightly decreased I/O performance, until the hydration finishes.

To wait for hydration to finish set the rok/wait-for-hydration PVC/SC parameter to "true".

Note

Instant clones are only available when using the in-kernel hydration mechanism, i.e., by setting the PVC/SC parameter rok/use-dmclone to "true".

Create Empty RWO PVC on Rok

Create a ReadWriteOnce (RWO) PVC object and set the StorageClass to rok:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mypvc
spec:
  storageClassName: rok
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Create Empty RWX PVC on Rok

Create a ReadWriteMany (RWX) PVC object and set the StorageClass to rok:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mypvc
spec:
  storageClassName: rok
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi