Persistent Storage Using Azure File

Overview

OKD supports Microsoft Azure File volumes. You can provision your OKD cluster with persistent storage using Azure. Some familiarity with Kubernetes and Azure is assumed.

Before you begin

1. Install samba-client, samba-common, and cifs-utils on all nodes:

   $ sudo yum install samba-client samba-common cifs-utils

2. Enable SELinux booleans on all nodes:

   $ /usr/sbin/setsebool -P virt_use_samba on
   $ /usr/sbin/setsebool -P virt_sandbox_use_samba on

3. Run the mount command to check dir_mode and file_mode permissions, for example:

   $ mount

If the dir_mode and file_mode permissions are set to 0755, change the default value 0755 to 0777 or 0775. This manual step is required because the default dir_mode and file_mode permissions changed from 0777 to 0755 in OKD 3.9. The following examples show configuration files with the changed values.

Considerations when using Azure File

The following file system features are not supported by Azure File:

• Symlinks

• Hard links

• Extended attributes

• Sparse files

• Named pipes

Additionally, the owner user identifier (UID) of the Azure File mounted directory is different from the process UID of the container.

Workaround for using MySQL with Azure File

If you use MySQL containers, you must modify the PV configuration as a workaround to a file ownership mismatch between the mounted directory UID and the container process UID. Make the following changes to your PV configuration file:

1. Specify the Azure File mounted directory UID in the runAsUser variable in the PV configuration file:

   spec:
     containers:
       ...
     securityContext:
       runAsUser: <mounted_dir_uid>

2. Specify the container process UID under mountOptions in the PV configuration file:

   mountOptions:
     - dir_mode=0700
     - file_mode=0600
     - uid=<container_process_uid>
     - gid=0

Example configuration files

The following example configuration file displays a PV configuration using Azure File:

PV configuration file example

apiVersion: "v1"
kind: "PersistentVolume"
metadata:
  name: "azpv"
spec:
  capacity:
    storage: "1Gi"
  accessModes:
    - "ReadWriteMany"
  azureFile:
    secretName: azure-secret
    shareName: azftest
    readOnly: false
  mountOptions:
    - dir_mode=0777
    - file_mode=0777

The following example configuration file displays a storage class using Azure File:

Storage class configuration file example

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azurefile
provisioner: kubernetes.io/azure-file
mountOptions:
  - dir_mode=0777
  - file_mode=0777
parameters:
  storageAccount: ocp39str
  location: centralus

Configuring Azure File for regional cloud

While Azure Disk is compatible with multiple regional clouds, Azure File supports only the Azure public cloud, because the endpoint is hard-coded.

Creating the Azure Storage Account secret

Define the Azure Storage Account name and key in a secret configuration, which is then converted to base64 for use by OKD.

1. Obtain an Azure Storage Account name and key and encode to base64:

   apiVersion: v1
   kind: Secret
   metadata:
     name: azure-secret
   type: Opaque
   data:
     azurestorageaccountname: azhzdGVzdA==
     azurestorageaccountkey: eElGMXpKYm5ub2pGTE1Ta0JwNTBteDAyckhzTUsyc2pVN21GdDRMMTNob0I3ZHJBYUo4akQ2K0E0NDNqSm9nVjd5MkZVT2hRQ1dQbU02WWFOSHk3cWc9PQ==

2. Save the secret definition to a file, for example azure-secret.yaml, then create the secret:

   $ oc create -f azure-secret.yaml

3. Verify that the secret was created:

   $ oc get secret azure-secret
   NAME          TYPE      DATA      AGE
   azure-secret   Opaque    1         23d

4. Define the PV in an object definition before creating it in OKD:

   PV object definition using Azure File example

   apiVersion: "v1"
   kind: "PersistentVolume"
   metadata:
     name: "pv0001" (1)
   spec:
     capacity:
       storage: "5Gi" (2)
     accessModes:
       - "ReadWriteMany"
     azureFile: (3)
       secretName: azure-secret (4)
       shareName: example (5)
       readOnly: false (6)

   1	The name of the volume. This is how it is identified via PV claims or from pods.
   2	The amount of storage allocated to this volume.
   3	This defines the volume type being used: azureFile plug-in.
   4	The name of the secret used.
   5	The name of the file share.
   6	Defaults to false (read/write). ReadOnly here forces the ReadOnly setting in VolumeMounts.

5. Save your definition to a file, for example azure-file-pv.yaml, and create the PV:

   $ oc create -f azure-file-pv.yaml
   persistentvolume "pv0001" created

6. Verify that the PV was created:

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

You can now request storage using PV claims, which can now use your new PV.