IT 3300 : Virtualization

Kubernetes — Storage

The problem, again

  • Pods are ephemeral; their filesystems die with them
  • Databases and stateful apps need storage that outlives the pod
  • Kubernetes abstracts storage so pods don't care where it lives

Volumes

  • A Volume is storage attached to a pod
  • Outlives container restarts within the pod
  • Many types: emptyDir, hostPath, NFS, cloud disks, Ceph...
  • Most types of volumes will be related to the type of cloud provider you are running on. For us to do in microk8s, you must microk8s enable storage (allocates storage from host directory)
  • So a pod will only access storage on the node it runs on

The PV / PVC model

  • PersistentVolume (PV) — a real piece of storage in the cluster
  • PersistentVolumeClaim (PVC) — a pod's request for storage
  • The pod asks (PVC); Kubernetes binds it to a PV
  • Decouples "I need 5Gi" from "where does it come from"

A claim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 5Gi

Using the claim in a pod

    volumes:
      - name: data
        persistentVolumeClaim:
          claimName: data
    # in the container:
    volumeMounts:
      - name: data
        mountPath: /var/lib/data

StorageClasses

  • Manually creating PVs doesn't scale
  • A StorageClass provisions storage on demand when a PVC is made
  • Ties into a backend: NFS, Ceph, cloud disks
  • This is dynamic provisioning — the normal way to do storage

Access modes

  • ReadWriteOnce — one node mounts read/write (typical for DBs)
  • ReadOnlyMany — many nodes, read-only
  • ReadWriteMany — many nodes read/write (needs NFS/CephFS)

It ties back to Unit 1

  • The same shared/distributed storage from Proxmox (NFS, Ceph) can
    back your Kubernetes StorageClasses
  • The stack reuses ideas at every layer