1. Documentation

Persistent Storage Using Azure Disk

Overview

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

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.

Persistent volumes are not bound to a single project or namespace; they can be shared across the OpenShift Origin 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.

Prerequisites

Before creating persistent volumes using Azure, ensure your OpenShift Origin cluster meets the following requirements:

  • OpenShift Origin 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.

Provisioning

Storage must exist in the underlying infrastructure before it can be mounted as a volume in OpenShift Origin. After ensuring OpenShift Origin is configured for Azure Disk, all that is required for OpenShift Origin and Azure is an Azure Disk Name and Disk URI and the PersistentVolume API.

Creating the Persistent Volume

Azure does not support the Recycle recycling policy.

You must define your persistent volume in an object definition before creating it in OpenShift Origin:

Example 1. Persistent Volume Object Definition Using Azure
apiVersion: "v1"
kind: "PersistentVolume"
metadata:
  name: "pv0001" (1)
spec:
  capacity:
    storage: "5Gi" (2)
  accessModes:
    - "ReadWriteOnce"
  azureDisk: (3)
    diskName: test2.vhd (4)
    diskURI: https://someacount.blob.core.windows.net/vhds/test2.vhd (5)
    cachingMode: readwrite  (6)
    fsType: ext4  (7)
    readOnly: false   (8)
1 The name of the volume. This will be how it is identified via persistent volume claims or from pods.
2 The amount of storage allocated to this volume.
3 This defines the volume type being used (azureDisk plug-in, in this example).
4 The name of the data disk in the blob storage.
5 The URI the the data disk in the blob storage.
6 Host caching mode: None, Read Only, or Read Write.
7 File system type to mount (for example, ext4, xfs, and so on).
8 Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts.

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

  1. 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

  2. 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.

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.

Volume Format

Before OpenShift Origin 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 OpenShift Origin formats them before the first use.