Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 22. Configuring for Local Volume

22.1. Overview
Copia collegamento

OpenShift Container Platform can be configured to access local volumes for application data.

Local volumes are persistent volumes (PV) representing locally-mounted file systems. In the future, they may be extended to raw block devices.

Local volumes are different from a hostPath. They have a special annotation that makes any pod that uses the PV to be scheduled on the same node where the local volume is mounted.

In addition, local volume includes a provisioner that automatically creates PVs for locally mounted devices. This provisioner is currently limited and it only scans pre-configured directories. It cannot dynamically provision volumes, which may be implemented in a future release.

The local volume provisioner allows using local storage within OpenShift Container Platform and supports:

  • Volumes
  • PVs
Note

Local volumes is an alpha feature and may change in a future release of OpenShift Container Platform.

22.1.1. Enable Local Volumes
Copia collegamento

Enable the PersistentLocalVolumes feature gate on all masters and nodes.

  1. Edit or create the master configuration file on all masters (/etc/origin/master/master-config.yaml by default) and add PersistentLocalVolumes=true under the apiServerArguments and controllerArguments sections: 

    apiServerArguments:
   feature-gates:
   - PersistentLocalVolumes=true
...

controllerArguments:
   feature-gates:
   - PersistentLocalVolumes=true
...
    Copy to Clipboard Toggle word wrap

  2. On all nodes, edit or create the node configuration file (/etc/origin/node/node-config.yaml by default) and add PersistentLocalVolumes=true feature gate under kubeletArguments: 

    kubeletArguments:
   feature-gates:
     - PersistentLocalVolumes=true
    Copy to Clipboard Toggle word wrap

22.1.2. Mount Local Volumes
Copia collegamento

All local volumes must be manually mounted before they can be consumed by OpenShift Container Platform as PVs.

All volumes must be mounted into the /mnt/local-storage/<storage-class-name>/<volume> path. The administrators are required to create the local devices as needed (by using any method such as a disk partition or an LVM), create suitable file systems on these devices, and mount them using a script or /etc/fstab entries.

Example /etc/fstab entries

# device name   # mount point                  # FS    # options # extra
/dev/sdb1       /mnt/local-storage/ssd/disk1 ext4     defaults 1 2
/dev/sdb2       /mnt/local-storage/ssd/disk2 ext4     defaults 1 2
/dev/sdb3       /mnt/local-storage/ssd/disk3 ext4     defaults 1 2
/dev/sdc1       /mnt/local-storage/hdd/disk1 ext4     defaults 1 2
/dev/sdc2       /mnt/local-storage/hdd/disk2 ext4     defaults 1 2
Copy to Clipboard Toggle word wrap

All volumes must be accessible to processes running within Docker containers. Change the labels of mounted file systems to allow that: 

$ chcon -R unconfined_u:object_r:svirt_sandbox_file_t:s0 /mnt/local-storage/
Copy to Clipboard Toggle word wrap

22.1.3. Configure Local Provisioner
Copia collegamento

OpenShift Container Platform depends on an external provisioner to create PVs for local devices and to clean them up when they are not needed (to enable reuse).

Note
  • The local volume provisioner is different from most provisioners and does not support dynamic provisioning.
  • The local volume provisioner requires that the administrators preconfigure the local volumes on each node and mount them under discovery directories. The provisioner then manages the volumes by creating and cleaning up PVs for each volume.

This external provisioner should be configured using a ConfigMap to relate directories with StorageClasses. This configuration must be created before the provisioner is deployed.

Note

(Optional) Create a standalone namespace for local volume provisioner and its configuration, for example: oc new-project local-storage 

apiVersion: v1
kind: ConfigMap
metadata:
  name: local-volume-config
data:
    "local-ssd": |
1 

      {
        "hostDir": "/mnt/local-storage/ssd",
2 

        "mountDir": "/mnt/local-storage/ssd"
3 

      }
    "local-hdd": |
      {
        "hostDir": "/mnt/local-storage/hdd",
        "mountDir": "/mnt/local-storage/hdd"
      }
Copy to Clipboard Toggle word wrap
1
Name of the StorageClass.
2
Path to the directory on the host. It must be a subdirectory of /mnt/local-storage.
3
Path to the directory in the provisioner pod. We recommend using the same directory structure as used on the host.

With this configuration, the provisioner creates:

  • One PV with StorageClass local-ssd for every subdirectory in /mnt/local-storage/ssd.
  • One PV with StorageClass local-hdd for every subdirectory in /mnt/local-storage/hdd.

The LocalPersistentVolumes alpha feature now also requires the VolumeScheduling alpha feature. This is a breaking change, and the following changes are required:

  • The VolumeScheduling feature gate must also be enabled on kube-scheduler and kube-controller-manager components.
  • The NoVolumeNodeConflict predicate has been removed. For non-default schedulers, update your scheduler policy.
  • The CheckVolumeBinding predicate must be enabled in non-default schedulers.

22.1.4. Deploy Local Provisioner
Copia collegamento

Note

Before starting the provisioner, mount all local devices and create a ConfigMap with storage classes and their directories.

Install the local provisioner from the local-storage-provisioner-template.yaml file.

  1. Create a service account that allows running pods as a root user, use hostPath volumes, and use any SELinux context to be able to monitor, manage, and clean local volumes: 

    $ oc create serviceaccount local-storage-admin
$ oc adm policy add-scc-to-user privileged -z local-storage-admin
    Copy to Clipboard Toggle word wrap

    To allow the provisioner pod to delete content on local volumes created by any pod, root privileges and any SELinux context are required. hostPath is required to access the /mnt/local-storage path on the host.

  2. Install the template: 

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/storage-examples/local-examples/local-storage-provisioner-template.yaml
    Copy to Clipboard Toggle word wrap

  3. Instantiate the template by specifying values for configmap, account, and provisioner_image parameters: 

    $ oc new-app -p CONFIGMAP=local-volume-config \
  -p SERVICE_ACCOUNT=local-storage-admin \
  -p NAMESPACE=local-storage \
  -p PROVISIONER_IMAGE=registry.access.redhat.com/openshift3/local-storage-provisioner:v3.9 \
    1 
    
  local-storage-provisioner
    Copy to Clipboard Toggle word wrap
    1
    Replace v3.9 with the right OpenShift Container Platform version.

  4. Add the necessary storage classes: 

    oc create -f ./storage-class-ssd.yaml
oc create -f ./storage-class-hdd.yaml
    Copy to Clipboard Toggle word wrap

    storage-class-ssd.yaml

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: local-ssd
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
    Copy to Clipboard Toggle word wrap

    storage-class-hdd.yaml

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: local-hdd
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
    Copy to Clipboard Toggle word wrap

    See the template for other configurable options. This template creates a DaemonSet that runs a pod on every node. The pod watches directories specified in the ConfigMap and creates PVs for them automatically.

    The provisioner runs as root to be able to clean up the directories when a PV is released and all data needs to be removed.

22.1.5. Adding New Devices
Copia collegamento

Adding a new device requires several manual steps:

  1. Stop DaemonSet with the provisioner.
  2. Create a subdirectory in the right directory on the node with the new device and mount it there.
  3. Start the DaemonSet with the provisioner.
Important

Omitting any of these steps may result in the wrong PV being created.

Torna in cima
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2025 Red Hat