Kubernetes Storage Basics

Introduction to Kubernetes Storage

Container storage is ephemeral by default - when a container restarts or a pod is rescheduled, any data stored inside the container is lost. For applications that need to store data persistently, Kubernetes provides a robust storage abstraction system.

In this section, we’ll explore how Kubernetes manages persistent storage through PersistentVolumes (PVs), PersistentVolumeClaims (PVCs), and StorageClasses.

Core Storage Concepts

PersistentVolumes (PVs)

A PersistentVolume represents a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using StorageClasses. It is a resource in the cluster just like a node, and exists independently from any individual pod.

Key characteristics:

  • Volume plugins (AWS EBS, Azure Disk, NFS, etc.)
  • Storage capacity
  • Access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany)
  • Reclaim policies (Delete, Retain)
  • Mount options

PersistentVolumeClaims (PVCs)

A PersistentVolumeClaim is a request for storage by a user. It’s similar to a pod in that pods consume node resources and PVCs consume PV resources. PVCs can request specific size, access mode, and storage class.

StorageClasses

StorageClasses provide a way to describe different “classes” of storage offered in a cluster. Different classes might map to quality-of-service levels, backup policies, or arbitrary policies determined by the cluster administrators.

The Relationship Between PVs, PVCs, and StorageClasses

  1. Admin creates StorageClasses that define available storage types
  2. User creates a PVC requesting storage of a particular StorageClass
  3. The system either:
    • Binds the PVC to an existing, suitable PV (static provisioning)
    • Dynamically provisions a new PV based on the StorageClass (dynamic provisioning)
  4. User references the PVC in a pod spec
  5. Kubernetes mounts the underlying storage when the pod is scheduled

Static vs. Dynamic Provisioning

Static Provisioning

In static provisioning, a cluster administrator creates a number of PVs in advance. 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.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: nfs-server.default.svc.cluster.local
    path: "/exports"

Dynamic Provisioning

Dynamic provisioning eliminates the need for cluster administrators to pre-provision storage. Instead, it automatically provisions storage when it is requested by users through PVCs.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/azure-disk
parameters:
  skuName: Premium_LRS
  location: westus2
  cachingMode: ReadOnly

Then, a user can request storage from this class:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: fast

Using Storage in Pod Specifications

Once you have a PVC, you can reference it in a pod specification:

apiVersion: v1
kind: Pod
metadata:
  name: data-pod
spec:
  containers:
  - name: data-container
    image: nginx
    volumeMounts:
    - name: data-volume
      mountPath: /usr/share/nginx/html
  volumes:
  - name: data-volume
    persistentVolumeClaim:
      claimName: mypvc

This mounts the storage represented by the PVC mypvc into the container at the path /usr/share/nginx/html.

Further Reading and Resources