On-disk files in a Container are ephemeral, which presents some problems for non-trivial applications when running in Containers. First, when a Container crashes, kubelet will restart it, but the files will be lost - the Container starts with a clean state. Second, when running Containers together in a Pod it is often necessary to share files between those Containers. The Kubernetes Volume abstraction solves both of these problems.
Docker also has a concept of volumes, though it is somewhat looser and less managed. In Docker, a volume is simply a directory on disk or in another Container.
A Kubernetes volume, on the other hand, has an explicit lifetime - the same as the Pod that encloses it. Consequently, a volume outlives any Containers that run within the Pod, and data is preserved across Container restarts. Of course, when a Pod ceases to exist, the volume will cease to exist, too. Perhaps more importantly than this, Kubernetes supports many types of volumes, and a Pod can use any number of them simultaneously.
apiVersion: v1kind: Podmetadata:name: my-podspec:containers:- image: busyboxcommand: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']name: busybox
apiVersion: v1kind: Podmetadata:name: test-pdspec:containers:- image: bitnami/nginxname: test-containervolumeMounts:
Managing storage is a distinct problem from managing compute instances. The PersistentVolume subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed.
A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes.
A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Claims can request specific size and access modes (e.g., they can be mounted once read/write or many times read-only).
While PersistentVolumeClaims allow a user to consume abstract storage resources, it is common that users need PersistentVolumes with varying properties, such as performance, for different problems. Cluster administrators need to be able to offer a variety of PersistentVolumes that differ in more ways than just size and access modes, without exposing users to the details of how those volumes are implemented. For these needs, there is the StorageClass resource.
Pods access storage by using the claim as a volume. Claims must exist in the same namespace as the Pod using the claim. The cluster finds the claim in the Pod’s namespace and uses it to get the PersistentVolume backing the claim. The volume is then mounted to the host and into the Pod.
PersistentVolumes binds are exclusive, and since PersistentVolumeClaims are namespaced objects, mounting claims with “Many” modes (ROX, RWX) is only possible within one namespace.
kind: PersistentVolumeapiVersion: v1metadata:name: my-pvspec:storageClassName: local-storagecapacity:storage: 128MiaccessModes:
apiVersion: v1kind: PersistentVolumeClaimmetadata:name: my-pvcspec:storageClassName: local-storageaccessModes:- ReadWriteOnceresources:
kind: PodapiVersion: v1metadata:name: my-podspec:containers:- name: nginximage: busyboxcommand: ['sh', '-c', 'echo $(date):$HOSTNAME Hello Kubernetes! >> /mnt/data/message.txt && sleep 3600']
Getting the Persistent Volumes in Project
oc get pv
Getting the Persistent Volume Claims
oc get pvc
Getting a specific Persistent Volume
oc get pv <pv-claim>
Getting the PersistentVolume
kubectl get pv
Getting the PersistentVolumeClaims
kubectl get pvc
|Try It Yourself|
|Setting up Persistent Volumes||Create a Persistent Volume that’s accessible from a SQL Pod.||Setting up Persistent Volumes|