OpenShift Volume Concepts
Internal
The Volume Mechanism
Volumes are mounted filesystems available to pods and their containers. Volumes may be backed by a number of host-local or network attached storage endpoints. The simplest volume type is EmptyDir, which is a temporary directory on a single machine. Administrators may also allow to request and attach Persistent Volumes.
Various contexts list the following objects as "volumes":
Volume Security
Volume Types
Persistent Volume Claim
A persistent volume claim is a request for a persistence resource with specific attributes, such as storage size. The persistent volume claims are created by the developers who manage the pods. Persistent volume claims are project-specific objects.
Persistent volume claims are matched to available volumes and binds the pod to the volume. This process allows a claim to be used as a volume in a pod: OpenShift finds the volume backing the claim and mounts it into the pod. Multiple PVCs within the same project can bind to the same PV. Once a PVC binds to a PV, that PV cannot be bound by a claim outside the first claim's project - the PV "belongs" to the project. If the underlying storage needs to be accessed by multiple projects, that can be implemented by declaring multiple PVs, where each project needs its own PV, which can then point to the same physical storage.
The pod can be disassociated from the persistent volume by deleting the persistent volume claim. The persistent volume transitions from a "Bound" to "Released" state. To make the persistent volume "Available" again, edit it and remove the persistent volume claim reference, as shown here. Transitioning the persistent volume from "Released" to "Available" state does not clear the storage content - this will have to be done manually.
All persistent volume claims for the current project can be listed with:
oc get pvc
EmptyDir
An "emptyDir", also known as a "temporary pod volume", is created when the pod is assigned to a node, and exists as long as the pod is running on the node. It is initially empty. Containers in a pod can all read and write the same files in the "emptyDir" volume, though the volume can be mounted at the same or different paths in each container.
When the pod is removed from the node, the data is deleted. If the container crashes, that does not remove the pod from a node, so data in an empty dir is safe across container crashes.
The "emptyDir" volumes are stored on whatever medium is backing the node (disk, network storage). The mapping on the local file system backing the node can be discovered by identifying the container and then executing a docker inspect:
"Mounts": [
{
"Source": "/var/lib/origin/openshift.local.volumes/pods/1806c74f-0ad4-11e8-85a1-525400360e56/volumes/kubernetes.io~empty-dir/emptydirvol1",
"Destination": "/something",
"Mode": "Z",
"RW": true,
"Propagation": "rprivate"
}
...
"emptyDir" volume storage may be restricted by a quota based on the pod’s FSGroup, if the FSGroup parameter is enabled by your cluster administrator,
EmptyDir Operations
ConfigMap
A ConfigMap is a component that holds key/value pairs of configuration data, and that can be consumed by pods, or can be used to store configuration for OpenShift system components such as controllers. It is a mechanism to inject containers with configuration while keeping the containers agnostic of the OpenShift platform. Aside from fine-grained information like individual properties, ConfigMaps can also store coarse-grained information such as entire configuration files or JSON blobs. The ConfigMaps can populate environment variables, set command-line arguments in a container and populate configuration files in a volume.
A ConfigMap is similar to a secret, but designed to be more convenient when working with strings that do not contain sensitive information.
ConfigMap can be created from directories, files, literal values.
The ConfigMaps must be created before they are consumed in pods. They cannot be shared between projects. If the ConfigMap is updated, it must be redeployed in then pod for the pod to see the changes.
Downward API
The downward API allows containers to consume information about OpenShift objects. The field within a pod are selected using 'fieldRef' API type, which has two types: 'fieldPath', the path of field to select relative to the pod and 'apiVersion'. The downward API exposes the following selectors:
- metadata.name: the pod name.
- metadata.namespace: pod namespace.
- metadata.labels
- metadata.annotations
- status.podIP
'resourceFieldRef'/'resource', which refers to the resource entries.
The information can be exposed to pods via environment variables and volumes.
hostPath
Secret
NFS
Persistent Volume
Persistent volumes are created by the cluster administrators.
Persistent volumes can be listed with oc get pv.