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...

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

Lab goals

  • Enable a StorageClass (hostpath or NFS)
  • Deploy a database with a PVC; write data
  • Delete the pod, let it reschedule, confirm the data persisted