Storage in Kubernetes

PersistentVolume (PV)

storage resource provisioned by admin.

PersistentVolumeClaim (PVC)

user request for persistent volume.

PersistentVolumeClaimBinder

is a singleton running in master that watches all PersistentVolumeClaims in the system and binds them to the closest matching available PersistentVolume. The volume manager watches the API for newly created volumes to manage.

PersistentVolumeClaimVolumeSource

references the user's PVC in the same namespace. This volume finds the bound PV and mounts that volume for the pod. A PersistentVolumeClaimVolumeSource is, essentially, a wrapper around another type of volume that is owned by someone else (the system).

Kubernetes makes no guarantees at runtime that the underlying storage exists or is available. High availability is left to the storage provider.

Goals

Allow administrators to describe available storage
Allow pod authors to discover and request persistent volumes to use with pods
Enforce security through access control lists and securing storage to the same namespace as the pod volume
Enforce quotas through admission control
Enforce scheduler rules by resource counting
Ensure developers can rely on storage being available without being closely bound to a particular disk, server, network, or storage device.

Request Storage

Kubernetes users request persistent storage for their pod by creating a PersistentVolumeClaim. Their request for storage is described by their requirements for resources and mount capabilities.

Admin provisions storage

An administrator provisions storage by posting PVs to the API. Various way to automate this task can be scripted. Dynamic provisioning is a future feature that can maintain levels of PVs.

POST:

kind: PersistentVolume
apiVersion: v1
metadata:
  name: pv0001
spec:
  capacity:
    storage: 10
  persistentDisk:
    pdName: "abc123"
    fsType: "ext4"

Users request storage

A user requests storage by posting a PVC to the API. Their request contains the AccessModes they wish their volume to have and the minimum size needed.

The user must be within a namespace to create PVCs.

POST: 

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim-1
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3

$ kubectl get pvc

NAME                LABELS              STATUS              VOLUME
myclaim-1           map[]               pending

Claim usage

The claim holder can use their claim as a volume. The PersistentVolumeClaimVolumeSource knows to fetch the PV backing the claim and mount its volume for a pod.

The claim holder owns the claim and its data for as long as the claim exists. The pod using the claim can be deleted, but the claim remains in the user's namespace. It can be used again and again by many pods.

POST: 

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - image: nginx
      name: myfrontend
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      source:
        persistentVolumeClaim:
         accessMode: ReadWriteOnce
         claimRef:
           name: myclaim-1

When a claim holder is finished with their data, they can delete their claim.

Admins can script the recycling of released volumes. Future dynamic provisioners will understand how a volume should be recycled.

Persistent Volumes

PVs are resources in the cluster. PVCs are requests for those resources and also act as claim checks to the resource. The interaction between PVs and PVCs follows this lifecycle:

A cluster administrator will create a number of PVs. They carry the details of the real storage which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.

Using

Pods use claims as volumes. The cluster inspects the claim to find the bound volume and mounts that volume for a pod. For volumes which support multiple access modes, the user specifies which mode desired when using their claim as a volume in a pod.

When a user is done with their volume, they can delete the PVC objects from the API which allows reclamation of the resource. The volume is considered "released" when the claim is deleted, but it is not yet available for another claim. The previous claimant's data remains on the volume which must be handled according to policy.

The access modes are:

ReadWriteOnce -- the volume can be mounted as read-write by a single node ReadOnlyMany -- the volume can be mounted read-only by many nodes ReadWriteMany -- the volume can be mounted as read-write by many nodes

Relevant Docs

wallnerryan/file.md

Select an option

No results found