Storage

Procedure

1. Define an OpenShift Container Platform ConfigMap that contains the environment variables by creating a configmap.yaml file that contains following contents:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: efs-provisioner
   data:
     file.system.id: <file-system-id> 1
     aws.region: <aws-region> 2
     provisioner.name: openshift.org/aws-efs 3
     dns.name: "" 4

   1

   Defines the Amazon Web Services (AWS) EFS file system ID.

   2

   The AWS region of the EFS file system, such as us-east-1.

   3

   The name of the provisioner for the associated StorageClass.

   4

   An optional argument that specifies the new DNS name where the EFS volume is located. If no DNS name is provided, the provisioner will search for the EFS volume at <file-system-id>.efs.<aws-region>.amazonaws.com.

2. After the file has been configured, create it in your cluster by running the following command:

   $ oc create -f configmap.yaml -n <namespace>

Procedure

1. Create an efs-provisioner service account:

   $ oc create serviceaccount efs-provisioner

2. Create a file, clusterrole.yaml that defines the necessary permissions:

   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: efs-provisioner-runner
   rules:
     - apiGroups: [""]
       resources: ["persistentvolumes"]
       verbs: ["get", "list", "watch", "create", "delete"]
     - apiGroups: [""]
       resources: ["persistentvolumeclaims"]
       verbs: ["get", "list", "watch", "update"]
     - apiGroups: ["storage.k8s.io"]
       resources: ["storageclasses"]
       verbs: ["get", "list", "watch"]
     - apiGroups: [""]
       resources: ["events"]
       verbs: ["create", "update", "patch"]
     - apiGroups: ["security.openshift.io"]
       resources: ["securitycontextconstraints"]
       verbs: ["use"]
       resourceNames: ["hostmount-anyuid"]

3. Create a file, clusterrolebinding.yaml, that defines a cluster role binding that assigns the defined role to the service account:

   kind: ClusterRoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: run-efs-provisioner
   subjects:
     - kind: ServiceAccount
       name: efs-provisioner
       namespace: default 1
   roleRef:
     kind: ClusterRole
     name: efs-provisioner-runner
     apiGroup: rbac.authorization.k8s.io

   1

   The namespace where the EFS provisioner pod will run. If the EFS provisioner is running in a namespace other than default, this value must be updated.

4. Create a file, role.yaml, that defines a role with the necessary permissions:

   kind: Role
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: leader-locking-efs-provisioner
   rules:
     - apiGroups: [""]
       resources: ["endpoints"]
       verbs: ["get", "list", "watch", "create", "update", "patch"]

5. Create a file, rolebinding.yaml, that defines a role binding that assigns this role to the service account:

   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: leader-locking-efs-provisioner
   subjects:
     - kind: ServiceAccount
       name: efs-provisioner
       namespace: default 1
   roleRef:
     kind: Role
     name: leader-locking-efs-provisioner
     apiGroup: rbac.authorization.k8s.io

   1

   The namespace where the EFS provisioner pod will run. If the EFS provisioner is running in a namespace other than default, this value must be updated.

6. Create the resources inside the OpenShift Container Platform cluster:

   $ oc create -f clusterrole.yaml,clusterrolebinding.yaml,role.yaml,rolebinding.yaml

Procedure

1. Define an OpenShift Container Platform ConfigMap that contains the environment variables by creating a storageclass.yaml with the following contents:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: aws-efs
   provisioner: openshift.org/aws-efs
   parameters:
     gidMin: "2048" 1
     gidMax: "2147483647" 2
     gidAllocate: "true" 3

   1

   An optional argument that defines the minimum group ID (GID) for volume assignments. The default value is 2048.

   2

   An optional argument that defines the maximum GID for volume assignments. The default value is 2147483647.

   3

   An optional argument that determines if GIDs are assigned to volumes. If false, dynamically provisioned volumes are not allocated GIDs, allowing all users to read and write to the created volumes. The default value is true.

2. After the file has been configured, create it in your cluster by running the following command:

   $ oc create -f storageclass.yaml

Procedure

1. Define the EFS provisioner by creating a provisioner.yaml with the following contents:

   kind: Pod
   apiVersion: v1
   metadata:
     name: efs-provisioner
   spec:
     serviceAccount: efs-provisioner
     containers:
       - name: efs-provisioner
         image: quay.io/external_storage/efs-provisioner:latest
         env:
           - name: PROVISIONER_NAME
             valueFrom:
               configMapKeyRef:
                 name: efs-provisioner
                 key: provisioner.name
           - name: FILE_SYSTEM_ID
             valueFrom:
               configMapKeyRef:
                 name: efs-provisioner
                 key: file.system.id
           - name: AWS_REGION
             valueFrom:
               configMapKeyRef:
                 name: efs-provisioner
                 key: aws.region
           - name: DNS_NAME
             valueFrom:
               configMapKeyRef:
                 name: efs-provisioner
                 key: dns.name
                 optional: true
         volumeMounts:
           - name: pv-volume
             mountPath: /persistentvolumes
     volumes:
       - name: pv-volume
         nfs:
           server: <file-system-id>.efs.<region>.amazonaws.com 1
           path: / 2

   1

   Contains the DNS name of the EFS volume. This field must be updated for the Pod to discover the EFS volume.

   2

   The mount path of the EFS volume. Each persistent volume is created as a separate subdirectory on the EFS volume. If this EFS volume is used for other projects outside of OpenShift Container Platform, then it is recommended to create a unique subdirectory OpenShift Container Platform manually on EFS for the cluster to prevent projects from accessing another project’s data. Specifying a directory that does not exist results in an error.

2. After the file has been configured, create it in your cluster by running the following command:

   $ oc create -f provisioner.yaml

Procedure (UI)

1. In the OpenShift Container Platform console, click Storage → Persistent Volume Claims.
2. In the persistent volume claims overview, click Create Persistent Volume Claim.

3. Define the required options on the resulting page.

   1. Select the storage class that you created from the list.
   2. Enter a unique name for the storage claim.
   3. Select the access mode to determine the read and write access for the created storage claim.

   4. Define the size of the storage claim.

      Note

      Although you must enter a size, every Pod that access the EFS volume has unlimited storage. Define a value, such as 1Mi, that will remind you that the storage size is unlimited.

4. Click Create to create the persistent volume claim and generate a persistent volume.

Procedure (CLI)

1. Alternately, you can define EFS PersistentVolumeClaims by creating a file, pvc.yaml, with the following contents:

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: efs-claim 1
     namespace: test-efs
     annotations:
       volume.beta.kubernetes.io/storage-provisioner: openshift.org/aws-efs
     finalizers:
       - kubernetes.io/pvc-protection
   spec:
     accessModes:
       - ReadWriteOnce 2
     resources:
       requests:
         storage: 5Gi 3
     storageClassName: aws-efs 4
     volumeMode: Filesystem

   1

   A unique name for the PVC.

   2

   The access mode to determine the read and write access for the created PVC.

   3

   Defines the size of the PVC.

   4

   Name of the StorageClass for the EFS provisioner.

2. After the file has been configured, create it in your cluster by running the following command:

   $ oc create -f pvc.yaml

Procedure

1. In the OpenShift Container Platform console, click Storage → Storage Classes.
2. In the storage class overview, click Create Storage Class.

3. Define the desired options on the page that appears.

   1. Enter a name to reference the storage class.
   2. Enter an optional description.
   3. Select the reclaim policy.
   4. Select kubernetes.io/aws-ebs from the drop down list.
   5. Enter additional parameters for the storage class as desired.
4. Click Create to create the storage class.

Procedure

1. In the OpenShift Container Platform console, click Storage → Persistent Volume Claims.
2. In the persistent volume claims overview, click Create Persistent Volume Claim.

3. Define the desired options on the page that appears.

   1. Select the storage class created previously from the drop-down menu.
   2. Enter a unique name for the storage claim.
   3. Select the access mode. This determines the read and write access for the created storage claim.
   4. Define the size of the storage claim.
4. Click Create to create the persistent volume claim and generate a persistent volume.

Procedure

1. In the OpenShift Container Platform console, click Storage → Storage Classes.
2. In the storage class overview, click Create Storage Class.

3. Define the desired options on the page that appears.

   1. Enter a name to reference the storage class.
   2. Enter an optional description.
   3. Select the reclaim policy.

   4. Select kubernetes.io/azure-disk from the drop down list.

      1. Enter the storage account type. This corresponds to your Azure storage account SKU tier. Valid options are Premium_LRS, Standard_LRS, StandardSSD_LRS, and UltraSSD_LRS.
      2. Enter the kind of account. Valid options are shared, dedicated, and managed.
   5. Enter additional parameters for the storage class as desired.
4. Click Create to create the storage class.

Procedure

1. In the OpenShift Container Platform console, click Storage → Persistent Volume Claims.
2. In the persistent volume claims overview, click Create Persistent Volume Claim.

3. Define the desired options on the page that appears.

   1. Select the storage class created previously from the drop-down menu.
   2. Enter a unique name for the storage claim.
   3. Select the access mode. This determines the read and write access for the created storage claim.
   4. Define the size of the storage claim.
4. Click Create to create the persistent volume claim and generate a persistent volume.

Procedure

1. Create a Secret that contains the Azure File credentials:

   $ oc create secret generic <secret-name> --from-literal=azurestorageaccountname=<storage-account> \ 1
     --from-literal=azurestorageaccountkey=<storage-account-key> 2

   1

   The Azure File storage account name.

   2

   The Azure File storage account key.

2. Create a PersistentVolume that references the Secret you created:

   apiVersion: "v1"
   kind: "PersistentVolume"
   metadata:
     name: "pv0001" 1
   spec:
     capacity:
       storage: "5Gi" 2
     accessModes:
       - "ReadWriteOnce"
     storageClassName: azure-file-sc
     azureFile:
       secretName: <secret-name> 3
       shareName: share-1 4
       readOnly: false

   1

   The name of the PersistentVolume.

   2

   The size of this PersistentVolume.

   3

   The name of the Secret that contains the Azure File share credentials.

   4

   The name of the Azure File share.

3. Create a PersistentVolumeClaim that maps to the PersistentVolume you created:

   apiVersion: "v1"
   kind: "PersistentVolumeClaim"
   metadata:
     name: "claim1" 1
   spec:
     accessModes:
       - "ReadWriteOnce"
     resources:
       requests:
         storage: "5Gi" 2
     storageClassName: azure-file-sc 3
     volumeName: "pv0001" 4

   1

   The name of the PersistentVolumeClaim.

   2

   The size of this PersistentVolumeClaim.

   3

   The name of the StorageClass that is used to provision the PersistentVolume. Specify the StorageClass used in the PersistentVolume definition.

   4

   The name of the existing PersistentVolume that references the Azure File share.

1. Ensure that the executable file exists on all nodes in the cluster.
2. Place the executable file at the volume plug-in path: /etc/kubernetes/kubelet-plugins/volume/exec/<vendor>~<driver>/<driver>.

Procedure

1. In the OpenShift Container Platform console, click Storage → Storage Classes.
2. In the storage class overview, click Create Storage Class.

3. Define the desired options on the page that appears.

   1. Enter a name to reference the storage class.
   2. Enter an optional description.
   3. Select the reclaim policy.
   4. Select kubernetes.io/gce-pd from the drop down list.
   5. Enter additional parameters for the storage class as desired.
4. Click Create to create the storage class.

Procedure

1. In the OpenShift Container Platform console, click Storage → Persistent Volume Claims.
2. In the persistent volume claims overview, click Create Persistent Volume Claim.

3. Define the desired options on the page that appears.

   1. Select the storage class created previously from the drop-down menu.
   2. Enter a unique name for the storage claim.
   3. Select the access mode. This determines the read and write access for the created storage claim.
   4. Define the size of the storage claim.
4. Click Create to create the persistent volume claim and generate a persistent volume.

Procedure

1. Define the persistent volume (PV). Create a file, pv.yaml, with the PersistentVolume object definition:

     apiVersion: v1
     kind: PersistentVolume
     metadata:
       name: task-pv-volume 1
       labels:
         type: local
     spec:
       storageClassName: manual 2
       capacity:
         storage: 5Gi
       accessModes:
         - ReadWriteOnce 3
       persistentVolumeReclaimPolicy: Retain
       hostPath:
         path: "/mnt/data" 4

   1

   The name of the volume. This name is how it is identified by PersistentVolumeClaims or Pods.

   2

   Used to bind PersistentVolumeClaim requests to this PersistentVolume.

   3

   The volume can be mounted as read-write by a single node.

   4

   The configuration file specifies that the volume is at /mnt/data on the cluster’s node.

2. Create the PV from the file:

   $ oc create -f pv.yaml

3. Define the persistent volume claim (PVC). Create a file, pvc.yaml, with the PersistentVolumeClaim object definition:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: task-pvc-volume
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 1Gi
     storageClassName: manual

4. Create the PVC from the file:

   $ oc create -f pvc.yaml

Procedure

1. Create the local-storage project:

   $ oc new-project local-storage

2. Optional: Allow local storage creation on master and infrastructure nodes.

   You might want to use the Local Storage Operator to create volumes on master and infrastructure nodes, and not just worker nodes, to support components such as logging and monitoring.

   To allow local storage creation on master and infrastructure nodes, add a toleration to the DaemonSet by entering the following commands:

   $ oc patch ds local-storage-local-diskmaker -n local-storage -p '{"spec": {"template": {"spec": {"tolerations":[{"operator": "Exists"}]}}}}'

   $ oc patch ds local-storage-local-provisioner -n local-storage -p '{"spec": {"template": {"spec": {"tolerations":[{"operator": "Exists"}]}}}}'

1. Log in to the OpenShift Container Platform web console.
2. Navigate to Operators → OperatorHub.
3. Type Local Storage into the filter box to locate the Local Storage Operator.
4. Click Install.
5. On the Create Operator Subscription page, select A specific namespace on the cluster. Select local-storage from the drop-down menu.
6. Adjust the values for Update Channel and Approval Strategy to the values that you want.
7. Click Subscribe.

From the CLI

1. Install the Local Storage Operator from the CLI.

   1. Create an object YAML file to define a Namespace, OperatorGroup, and Subscription for the Local Storage Operator, such as local-storage.yaml:

      Example local-storage

        apiVersion: v1
        kind: Namespace
        metadata:
          name: local-storage
        ---
        apiVersion: operators.coreos.com/v1alpha2
        kind: OperatorGroup
        metadata:
          name: local-operator-group
          namespace: local-storage
        spec:
          targetNamespaces:
            - local-storage
        ---
        apiVersion: operators.coreos.com/v1alpha1
        kind: Subscription
        metadata:
          name: local-storage-operator
          namespace: local-storage
        spec:
          channel: "{product-version}" 1
          installPlanApproval: Automatic
          name: local-storage-operator
          source: redhat-operators
          sourceNamespace: openshift-marketplace

      1

      This field can be edited to match your release selection of OpenShift Container Platform.

2. Create the Local Storage Operator object by entering the following command:

   $ oc apply -f local-storage.yaml

   At this point, the Operator Lifecycle Manager (OLM) is now aware of the Local Storage Operator. A ClusterServiceVersion (CSV) for the Operator should appear in the target namespace, and APIs provided by the Operator should be available for creation.

3. Verify local storage installation by checking that all Pods and the Local Storage Operator have been created:

   1. Check that all the required Pods have been created:

      $ oc -n local-storage get pods
      NAME                                      READY   STATUS    RESTARTS   AGE
      local-storage-operator-746bf599c9-vlt5t   1/1     Running   0          19m

   2. Check the ClusterServiceVersion (CSV) YAML manifest to see that the Local Storage Operator is available in the local-storage project:

      $ oc get csvs -n local-storage
      NAME                                         DISPLAY         VERSION               REPLACES   PHASE
      local-storage-operator.4.2.26-202003230335   Local Storage   4.2.26-202003230335              Succeeded

Procedure

1. Create the local volume resource. This must define the nodes and paths to the local volumes.

   Note

   Do not use different StorageClass names for the same device. Doing so will create multiple persistent volumes (PVs).

   Example: Filesystem

   apiVersion: "local.storage.openshift.io/v1"
   kind: "LocalVolume"
   metadata:
     name: "local-disks"
     namespace: "local-storage" 1
   spec:
     nodeSelector: 2
       nodeSelectorTerms:
       - matchExpressions:
           - key: kubernetes.io/hostname
             operator: In
             values:
             - ip-10-0-140-183
             - ip-10-0-158-139
             - ip-10-0-164-33
     storageClassDevices:
       - storageClassName: "local-sc"
         volumeMode: Filesystem 3
         fsType: xfs 4
         devicePaths: 5
           - /path/to/device 6

   1

   The namespace where the Local Storage Operator is installed.

   2

   Optional: A node selector containing a list of nodes where the local storage volumes are attached. This example uses the node host names, obtained from oc get node. If a value is not defined, then the Local Storage Operator will attempt to find matching disks on all available nodes.

   3

   The volume mode, either Filesystem or Block, defining the type of the local volumes.

   4

   The file system that is created when the local volume is mounted for the first time.

   5

   The path containing a list of local storage devices to choose from.

   6

   Replace this value with your actual local disks filepath to the LocalVolume resource, such as /dev/xvdg. PVs are created for these local disks when the provisioner is deployed successfully.

   Example: Block

   apiVersion: "local.storage.openshift.io/v1"
   kind: "LocalVolume"
   metadata:
     name: "local-disks"
     namespace: "local-storage" 1
   spec:
     nodeSelector: 2
       nodeSelectorTerms:
       - matchExpressions:
           - key: kubernetes.io/hostname
             operator: In
             values:
             - ip-10-0-136-143
             - ip-10-0-140-255
             - ip-10-0-144-180
     storageClassDevices:
       - storageClassName: "localblock-sc"
         volumeMode: Block  3
         devicePaths: 4
           - /path/to/device 5

   1

   The namespace where the Local Storage Operator is installed.

   2

   Optional: A node selector containing a list of nodes where the local storage volumes are attached. This example uses the node host names, obtained from oc get node. If a value is not defined, then the Local Storage Operator will attempt to find matching disks on all available nodes.

   3

   The volume mode, either Filesystem or Block, defining the type of the local volumes.

   4

   The path containing a list of local storage devices to choose from.

   5

   Replace this value with your actual local disks filepath to the LocalVolume resource, such as /dev/xvdg. PVs are created for these local disks when the provisioner is deployed successfully.

2. Create the local volume resource in your OpenShift Container Platform cluster, specifying the file you just created:

   $ oc create -f <local-volume>.yaml

3. Verify the provisioner was created, and the corresponding DaemonSets were created:

   $ oc get all -n local-storage
   
   NAME                                          READY   STATUS    RESTARTS   AGE
   pod/local-disks-local-provisioner-h97hj       1/1     Running   0          46m
   pod/local-disks-local-provisioner-j4mnn       1/1     Running   0          46m
   pod/local-disks-local-provisioner-kbdnx       1/1     Running   0          46m
   pod/local-disks-local-diskmaker-ldldw         1/1     Running   0          46m
   pod/local-disks-local-diskmaker-lvrv4         1/1     Running   0          46m
   pod/local-disks-local-diskmaker-phxdq         1/1     Running   0          46m
   pod/local-storage-operator-54564d9988-vxvhx   1/1     Running   0          47m
   
   NAME                              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)     AGE
   service/local-storage-operator    ClusterIP   172.30.49.90     <none>        60000/TCP   47m
   
   NAME                                           DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   daemonset.apps/local-disks-local-provisioner   3         3         3       3            3           <none>          46m
   daemonset.apps/local-disks-local-diskmaker     3         3         3       3            3           <none>          46m
   
   NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/local-storage-operator   1/1     1            1           47m
   
   NAME                                                DESIRED   CURRENT   READY   AGE
   replicaset.apps/local-storage-operator-54564d9988   1         1         1       47m

   Note the desired and current number of DaemonSet processes. If the desired count is 0, it indicates the label selectors were invalid.

4. Verify that the PersistentVolumes were created:

   $ oc get pv
   
   NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
   local-pv-1cec77cf   100Gi      RWO            Delete           Available           local-sc                88m
   local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
   local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                48m

Procedure

1. Create the PVC using the corresponding StorageClass:

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: local-pvc-name 1
   spec:
     accessModes:
     - ReadWriteOnce
     volumeMode: Filesystem 2
     resources:
       requests:
         storage: 100Gi 3
     storageClassName: local-sc 4

   1

   Name of the PVC.

   2

   The type of the PVC. Defaults to Filesystem.

   3

   The amount of storage available to the PVC.

   4

   Name of the StorageClass required by the claim.

2. Create the PVC in the OpenShift Container Platform cluster, specifying the file you just created:

   $ oc create -f <local-pvc>.yaml

Procedure

1. Include the defined claim in the resource’s Spec. The following example declares the PVC inside a Pod:

   apiVersion: v1
   kind: Pod
   spec:
     ...
     containers:
       volumeMounts:
       - name: localpvc 1
         mountPath: "/data" 2
     volumes:
     - name: localpvc
       persistentVolumeClaim:
         claimName: localpvc 3

   1

   Name of the volume to mount.

   2

   Path inside the Pod where the volume is mounted.

   3

   Name of the existing PVC to use.

2. Create the resource in the OpenShift Container Platform cluster, specifying the file you just created:

   $ oc create -f <local-pod>.yaml

Procedure

1. Create an object definition for the PV:

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: pv0001 1
   spec:
     capacity:
       storage: 5Gi 2
     accessModes:
     - ReadWriteOnce 3
     nfs: 4
       path: /tmp 5
       server: 172.17.0.2 6
     persistentVolumeReclaimPolicy: Retain 7

   1

   The name of the volume. This is the PV identity in various oc <command> pod commands.

   2

   The amount of storage allocated to this volume.

   3

   Though this appears to be related to controlling access to the volume, it is actually used similarly to labels and used to match a PVC to a PV. Currently, no access rules are enforced based on the accessModes.

   4

   The volume type being used, in this case the nfs plug-in.

   5

   The path that is exported by the NFS server.

   6

   The host name or IP address of the NFS server.

   7

   The reclaim policy for the PV. This defines what happens to a volume when released.

   Note

   Each NFS volume must be mountable by all schedulable nodes in the cluster.

2. Verify that the PV was created:

   $ oc get pv
   NAME     LABELS    CAPACITY     ACCESSMODES   STATUS      CLAIM  REASON    AGE
   pv0001   <none>    5Gi          RWO           Available                    31s

3. Create a persistent volume claim that binds to the new PV:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: nfs-claim1
   spec:
     accessModes:
       - ReadWriteOnce 1
     resources:
       requests:
         storage: 5Gi 2

   1

   As mentioned above for PVs, the accessModes do not enforce security, but rather act as labels to match a PV to a PVC.

   2

   This claim looks for PVs offering 5Gi or greater capacity.

4. Verify that the persistent volume claim was created:

   $ oc get pvc
   NAME         STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   nfs-claim1   Bound    pv0001   5Gi        RWO            gp2            2m

Procedure

1. Create the virtual machine disks. Virtual machine disks (VMDKs) must be created manually before statically provisioning VMware vSphere volumes. Use either of the following methods:

   • Create using vmkfstools. Access ESX through Secure Shell (SSH) and then use following command to create a VMDK volume:

     $ vmkfstools -c <size> /vmfs/volumes/<datastore-name>/volumes/<disk-name>.vmdk

   • Create using vmware-diskmanager:

     $ shell vmware-vdiskmanager -c -t 0 -s <size> -a lsilogic <disk-name>.vmdk

2. Create a PersistentVolume that references the VMDKs. Create a file, pv1.yaml, with the PersistentVolume object definition:

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: pv1 1
   spec:
     capacity:
       storage: 1Gi 2
     accessModes:
       - ReadWriteOnce
     persistentVolumeReclaimPolicy: Retain
     vsphereVolume: 3
       volumePath: "[datastore1] volumes/myDisk"  4
       fsType: ext4  5

   1

   The name of the volume. This name is how it is identified by PersistentVolumeClaims or Pods.

   2

   The amount of storage allocated to this volume.

   3

   The volume type used, with vsphereVolume for vSphere volumes. The label is used to mount a vSphere VMDK volume into Pods. The contents of a volume are preserved when it is unmounted. The volume type supports VMFS and VSAN datastore.

   4

   The existing VMDK volume to use. If you used vmkfstools, you must enclose the datastore name in square brackets, [], in the volume definition, as shown previously.

   5

   The file system type to mount. For example, ext4, xfs, or other file systems.

   Important

   Changing the value of the fsType parameter after the volume is formatted and provisioned can result in data loss and Pod failure.

3. Create the PersistentVolume from the file:

   $ oc create -f pv1.yaml

4. Create a PersistentVolumeClaim that maps to the PersistentVolume you created in the previous step. Create a file, pvc1.yaml, with the PersistentVolumeClaim object definition:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pvc1 1
   spec:
     accessModes:
       - ReadWriteOnce 2
     resources:
      requests:
        storage: "1Gi" 3
     volumeName: pv1 4

   1

   A unique name that represents the PersistentVolumeClaim.

   2

   The PersistentVolumeClaim’s access mode. With ReadWriteOnce, the volume can be mounted with read and write permissions by a single node.

   3

   The size of the PersistentVolumeClaim.

   4

   The name of the existing PersistentVolume.

5. Create the PersistentVolumeClaim from the file:

   $ oc create -f pvc1.yaml

Procedure

1. Define a ClusterRole that allows access to create and view secrets:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
   #  name: system:azure-cloud-provider
     name: <persistent-volume-binder-role> 1
   rules:
   - apiGroups: ['']
     resources: ['secrets']
     verbs:     ['get','create']

   1

   The name of the ClusterRole to view and create secrets.

2. Add the ClusterRole to the ServiceAccount:

   $ oc adm policy add-cluster-role-to-user <persistent-volume-binder-role> system:serviceaccount:kube-system:persistent-volume-binder

3. Create the Azure File StorageClass:

   kind: StorageClass
   apiVersion: storage.k8s.io/v1
   metadata:
     name: <azure-file> 1
   provisioner: kubernetes.io/azure-file
   parameters:
     location: eastus 2
     skuName: Standard_LRS 3
     storageAccount: <storage-account> 4
   reclaimPolicy: Delete
   volumeBindingMode: Immediate

   1

   Name of the StorageClass. The PersistentVolumeClaim uses this StorageClass for provisioning the associated PersistentVolumes.

   2

   Location of the Azure storage account, such as eastus. Default is empty, meaning that a new Azure storage account will be created in the OpenShift Container Platform cluster’s location.

   3

   SKU tier of the Azure storage account, such as Standard_LRS. Default is empty, meaning that a new Azure storage account will be created with the Standard_LRS SKU.

   4

   Name of the Azure storage account. If a storage account is provided, then skuName and location are ignored. If no storage account is provided, then the StorageClass searches for any storage account that is associated with the resource group for any accounts that match the defined skuName and location.