305-998-7702 | 415-800-2922 info@rx-m.com

Understanding Kubernetes Storage Objects

Learn how to put the latest open source technology into practice with hands-on training, delivered by industry experts, aligned to your desired business outcomes

Volumes are the primary way to configure storage for apps running under Kubernetes. Volumes are declared at the pod level, then mounted at the container level, as shown below:

apiVersion: v1
kind: Pod
metadata:
  name: cka-volumes
spec:
  restartPolicy: OnFailure
  containers:
    - name: cka-volume
      image: alpine
      command:
      - top
      volumeMounts:
      - name: applogs
        mountPath: /logs
  volumes:
    - name: applogs
      hostPath:
        path: /tmp/app/logs

Most volume lifespans are tied to the pods they are configured for, and usually expire when the pod is removed. To decouple storage from pod lifecycles, Kubernetes has PersistentVolume objects. PersistentVolumes are resources within the cluster that provide storage that persists outside of pod lifespans.

$ kubectl get pv

NAME         CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                 STORAGECLASS   REASON   AGE
app-log-pv   1Gi        RWO,ROX        Retain           Bound       default/app-log-pvc                           89m
fivegigpv    5Gi        RWO            Retain           Available                                                 78m

$

Pods may use PersistentVolumes (PVs) directly, but another way to use PVs are through PersistentVolumeClaims (PVCs). PVCs are abstract requests for storage that claim persistent volumes. If a PVC finds an existing PV that fulfills its requests (access mode and capacity), then that PV is bound to the PVC. PVCs can also describe PVs as templates that dynamically provision PVs from the desired specifications.

$ kubectl get pvc

NAME          STATUS   VOLUME       CAPACITY   ACCESS MODES   STORAGECLASS   AGE
app-log-pvc   Bound    app-log-pv   1Gi        RWO,ROX                       85m

$

StorageClasses allow PVCs to dynamically provision PVs. Each StorageClass object uses a plugin specific to a storage provider’s backend to create a new PV. The example below shows a basic gp2 StorageClass for AWS:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: mod4-aws-storageclass
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2

Learn more about how Kubernetes handles storage