StatefulSets (and a first look at PVCs)

StatefulSets (and a first look at PVCs)

A Deployment treats Pods as interchangeable: random names, random order, shared storage. Databases need the opposite.

graph TB SS[StatefulSet db] --> P0[db-0<br/>PVC data-db-0] SS --> P1[db-1<br/>PVC data-db-1] SS --> P2[db-2<br/>PVC data-db-2] H[Headless Service db<br/>clusterIP: None] -.-> P0 H -.-> P1 H -.-> P2
PropertyMeaning
Stable identitydb-0, db-1, db-2 - the name survives a restart
Stable DNS namedb-0.db.default.svc.cluster.local via a headless Service
Own storagevolumeClaimTemplates - one PVC per Pod, kept on delete
Orderedstarts 0,1,2; stops 2,1,0

PV and PVC in 30 seconds

graph LR P[Pod] --> PVC[PersistentVolumeClaim<br/>I need 1Gi RWX] PVC -->|bound| PV[PersistentVolume<br/>NFS support01:/storage1]
  • PV - a piece of real storage (here: an NFS export). Cluster-scoped.
  • PVC - a request for storage, in your namespace. Kubernetes binds it to a matching PV.
  • StorageClass - creates PVs on demand. This cluster has none yet, so today PVs are created by hand. Details on Day 5.
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteMany"]
        storageClassName: ""       # bind to a pre-created PV
        resources:
          requests:
            storage: 500Mi

Watch out

  • Deleting the StatefulSet or scaling down keeps the PVCs - your data survives, clean-up is manual.
  • A StatefulSet does not replicate your data. It gives identity and storage; replication is the application’s (or an operator’s) job.

References