The Kubernetes persistent volume framework allows administrators to provision a cluster with persistent storage and gives users a way to request those resources without having any knowledge of the underlying infrastructure.
Azure Disk volumes can be provisioned dynamically. Persistent volumes are not bound to a single project or namespace; they can be shared across the OKD cluster. Persistent volume claims, however, are specific to a project or namespace and can be requested by users.
High availability of storage in the infrastructure is left to the underlying storage provider.
Before creating persistent volumes using Azure, ensure your OKD cluster meets the following requirements:
OKD must first be configured for Azure Disk.
Each node host in the infrastructure must match the Azure virtual machine name.
Each node host must be in the same resource group.
Storage must exist in the underlying infrastructure before it can be mounted as
a volume in OKD. After ensuring OKD is
for Azure Disk, all that is required for OKD and Azure is an Azure
Disk Name and Disk URI and the
Azure has multiple regions on which to deploy an instance. To specify a desired region, add the following to the azure.conf file:
The region can be any of the following:
You must define your persistent volume in an object definition before creating it in OKD:
name: "pv0001" (1)
storage: "5Gi" (2)
diskName: test2.vhd (4)
diskURI: https://someacount.blob.core.windows.net/vhds/test2.vhd (5)
cachingMode: ReadWrite (6)
fsType: ext4 (7)
readOnly: false (8)
|The name of the volume. This will be how it is identified via persistent volume claims or from pods.
|The amount of storage allocated to this volume.
|This defines the volume type being used (azureDisk plug-in, in this example).
|The name of the data disk in the blob storage.
|The URI of the data disk in the blob storage.
|Host caching mode: None, ReadOnly, or ReadWrite.
|File system type to mount (for example,
xfs, and so on).
ReadOnly here will force the
ReadOnly setting in
Changing the value of the
Save your definition to a file, for example azure-pv.yaml, and create the persistent volume:
# oc create -f azure-pv.yaml persistentvolume "pv0001" created
Verify that the persistent volume was created:
# oc get pv NAME LABELS CAPACITY ACCESSMODES STATUS CLAIM REASON AGE pv0001 <none> 5Gi RWO Available 2s
Now you can request storage using persistent volume claims, which can now use your new persistent volume.
For a pod that has a mounted volume through an Azure disk PVC, scheduling the pod to a new node takes a few minutes. Wait for two to three minutes to complete the Disk Detach operation, and then start a new deployment. If a new pod creation request is started before completing the Disk Detach operation, the Disk Attach operation initiated by the pod creation fails, resulting in pod creation failure.
Persistent volume claims only exist in the user’s namespace and can only be referenced by a pod within that same namespace. Any attempt to access a persistent volume from a different namespace causes the pod to fail.
Before OKD mounts the volume and passes it to a container, it checks
that it contains a file system as specified by the
fsType parameter in the
persistent volume definition. If the device is not formatted with the file
system, all data from the device is erased and the device is automatically
formatted with the given file system.
This allows unformatted Azure volumes to be used as persistent volumes because OKD formats them before the first use.