PersistentVolumes and PVCs in a Single-Node Cluster

Containers are ephemeral: anything written to a pod's local filesystem disappears when the pod is deleted or rescheduled. Applications like databases and file storage need data to outlive pods. Kubernetes solves this with PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs). A PV is a piece of storage in the cluster; a PVC is a request for storage that binds to a PV. Pods then mount the PVC and get stable storage.

The storage request model

The key insight is the separation of request from supply. You (or an application) request storage with a PVC describing how much and how fast. The cluster finds or creates a matching PV and binds them. Pods never reference storage directly — they reference the PVC.

On single-node k3s, the local-path provisioner supplies storage by carving directories out of the node's disk. That is perfect for learning and for single-node workloads.

Creating a PVC

Here is a PVC requesting 2 GiB of fast local access. local-path provides it automatically.

apiVersion: v1
kind: PVC
metadata:
  name: data-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
  storageClassName: local-path

Using the PVC in a pod

A workload references the PVC in its volume and volumeMount sections. The pod gets a directory on the node that persists across pod restarts.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: db
spec:
  replicas: 1
  selector:
    matchLabels:
      app: db
  template:
    metadata:
      labels:
        app: db
    spec:
      containers:
        - name: db
          image: postgres:16
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: data-pvc

The lifecycle of a claim

Inspecting storage objects

Verify binding and capacity with the standard get commands.

kubectl get pvc
kubectl get pv
kubectl describe pvc data-pvc
kubectl get pv -o wide

You will see the PVC turn from Pending to Bound once local-path provisions the underlying directory.

The single-node caveat

Because storage lives on the one node, a node failure takes data with it. For real resilience you need backups or replicated storage on multiple nodes. On a single-node cluster, treat automated backup as part of the design rather than an afterthought.

Takeaway

PVs are the storage, PVCs are the request, and pods mount claims rather than raw storage. The k3s local-path provisioner makes trying this trivial — create a PVC, mount it in a postgres Deployment, restart the pod, and watch data persist. Experiment on a Netbay VPS and you will have the pattern down; just remember the single-node backup caveat — netbayhosts.in.