Skip to content

Latest commit

 

History

History
146 lines (122 loc) · 4.79 KB

persistent_storage_cinder.adoc

File metadata and controls

146 lines (122 loc) · 4.79 KB

Persistent Storage Using OpenStack Cinder

Overview

You can provision your {product-title} cluster with persistent storage using OpenStack Cinder. Some familiarity with Kubernetes and OpenStack is assumed.

Important

Before creating persistent volumes using Cinder, {product-title} must first be properly configured for OpenStack.

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. OpenStack Cinder volumes can be provisioned dynamically. Persistent volumes are not bound to a single project or namespace; they can be shared across the {product-title} cluster. Persistent volume claims, however, are specific to a project or namespace and can be requested by users.

For a detailed example, see the guide for WordPress and MySQL using persistent volumes.

Important

High-availability of storage in the infrastructure is left to the underlying storage provider.

Provisioning

Storage must exist in the underlying infrastructure before it can be mounted as a volume in {product-title}. After ensuring {product-title} is configured for OpenStack, all that is required for Cinder is a Cinder volume ID and the PersistentVolume API.

Creating the Persistent Volume

Note

Cinder does not support the 'Recycle' reclaim policy.

You must define your persistent volume in an object definition before creating it in {product-title}:

Example 1. Persistent Volume Object Definition Using Cinder
apiVersion: "v1"
kind: "PersistentVolume"
metadata:
  name: "pv0001" (1)
spec:
  capacity:
    storage: "5Gi" (2)
  accessModes:
    - "ReadWriteOnce"
  cinder: (3)
    fsType: "ext3" (4)
    volumeID: "f37a03aa-6212-4c62-a805-9ce139fab180" (5)

  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, in this case the cinder plug-in.

  4. File system type to mount.

  5. This is the Cinder volume that will be used.

Important

Changing the value of the fstype parameter after the volume has been formatted and provisioned can result in data loss and pod failure.

Save your definition to a file, for example cinder-pv.yaml, and create the persistent volume:

# oc create -f cinder-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

Users can then request storage using persistent volume claims, which can now utilize your new persistent volume.

Important

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 {product-title} 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 using unformatted Cinder volumes as persistent volumes, because {product-title} formats them before the first use.