Persistent Storage in Kubernetes: Configuring Local Path Provisioner on VPS

Running stateful applications such as databases, message brokers, and Elasticsearch in Kubernetes requires a reliable storage driver. On a single VPS node, attaching network-based block storage drivers introduces latency overhead, connection drops, and configuration complexity. Rancher's open-source Local Path Provisioner solves this by dynamically allocating directories on the host's high-speed local filesystem in response to PersistentVolumeClaims (PVCs).

Because the storage maps directly to the underlying host filesystem, applications experience native disk I/O performance without intermediate network translation layers.

In standard Kubernetes, hostPath volumes are statically bound to fixed directories specified manually in pod definitions. If multiple replicas or different namespaces request storage, manual hostPath management leads to naming collisions and permission errors. The Local Path Provisioner provides full Container Storage Interface (CSI) lifecycle management: when a PVC is created, the provisioner dynamically creates a uniquely named subdirectory on the host (such as /opt/local-path-provisioner/pvc-3f9b2d8a_default_db-data), sets appropriate POSIX permissions, mounts it into the container, and optionally deletes or archives the directory when the PVC is deleted.

Expand

Defining the StorageClass with Delayed Binding

The StorageClass should always specify volumeBindingMode: WaitForFirstConsumer. This ensures that volume allocation is delayed until a pod is scheduled, guaranteeing that the volume directory is created on the exact node hosting the pod:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-path-fast
provisioner: rancher.io/local-path
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete

The reclaimPolicy: Delete directive indicates that when a developer or CI job deletes the PVC, the provisioner automatically cleans up the corresponding host directory, reclaiming disk space on your server without leaving orphaned data artifacts.

Deploying a StatefulSet with Dynamic Volume Claims

The following StatefulSet demonstrates a production PostgreSQL deployment requesting a 10GB persistent volume from the local-path storage provisioner:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres-db
spec:
  serviceName: postgres-service
  replicas: 1
  selector:
    matchLabels:
      app: postgres-db
  template:
    metadata:
      labels:
        app: postgres-db
    spec:
      containers:
        - name: postgres
          image: postgres:16-alpine
          ports:
            - containerPort: 5432
          env:
            - name: POSTGRES_DB
              value: prod
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: password
          volumeMounts:
            - name: db-data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
    - metadata:
        name: db-data
      spec:
        accessModes: [ "ReadWriteOnce" ]
        storageClassName: local-path-fast
        resources:
          requests:
            storage: 10Gi

Inspecting Volume Allocation and Directory Mapping

Once the pod transitions to the running state, verify that the PVC is bound and locate the corresponding path on the host node:

# Check PVC binding state
kubectl get pvc

# Inspect the PersistentVolume details and mapped host path
kubectl describe pv $(kubectl get pvc db-data-postgres-db-0 -o jsonpath='{.spec.volumeName}') | grep "Path:"

# Check host disk utilization in the storage directory
sudo du -sh /opt/local-path-provisioner/*

Because the Local Path Provisioner talks directly to your VPS's underlying NVMe SSD storage through the Linux VFS (Virtual File System) layer, database write latencies (fsync calls) execute in microseconds rather than milliseconds, making it ideal for high-throughput databases.

Local Path storage gives you the agility of dynamic Kubernetes volume claims combined with bare-metal SSD speed.

You can spin up an Ubuntu 24.04 instance on Netbay in under 60 seconds with Intel Xeon Platinum compute and high-speed SSD storage in Lucknow — netbayhosts.in.