Introduction

The first thing to know is that PetSet was renamed to StatefulSet. The storage idea stayed the same: if you want a stateful workload to use existing storage, you do not point the pod directly at random disks. Instead, you make sure the PersistentVolumes and PersistentVolumeClaims line up so the StatefulSet can bind to the volumes you already have.

How StatefulSet Storage Works

A StatefulSet usually uses volumeClaimTemplates. For each replica, Kubernetes creates a PersistentVolumeClaim with a predictable name and binds that claim to a suitable PersistentVolume.

That means an existing volume can be reused if the cluster already has a matching PersistentVolume available. In practice, the match depends on things such as:

• storage class
• capacity
• access mode
• volume mode
• selector or pre-binding rules

So the real answer is not "attach this old disk directly to the PetSet." The answer is "prepare PersistentVolumes that match the claims the StatefulSet will create."

A Typical StatefulSet Template

Here is the basic shape of a StatefulSet with one volume claim template:

1apiVersion: apps/v1
2kind: StatefulSet
3metadata:
4  name: web
5spec:
6  serviceName: web
7  replicas: 2
8  selector:
9    matchLabels:
10      app: web
11  template:
12    metadata:
13      labels:
14        app: web
15    spec:
16      containers:
17        - name: app
18          image: nginx:stable
19          volumeMounts:
20            - name: data
21              mountPath: /usr/share/nginx/html
22  volumeClaimTemplates:
23    - metadata:
24        name: data
25      spec:
26        accessModes:
27          - ReadWriteOnce
28        storageClassName: fast-storage
29        resources:
30          requests:
31            storage: 10Gi

For this StatefulSet, the generated claim names will be predictable, such as data-web-0 and data-web-1.

Reuse Existing PersistentVolumes

To use existing storage, create PersistentVolumes that match the claims the StatefulSet will request. A simple static PV looks like this:

1apiVersion: v1
2kind: PersistentVolume
3metadata:
4  name: pv-web-0
5spec:
6  capacity:
7    storage: 10Gi
8  accessModes:
9    - ReadWriteOnce
10  storageClassName: fast-storage
11  hostPath:
12    path: /data/web-0

If the storage class, size, and access mode match, Kubernetes can bind the generated claim to that PV. For more deterministic reuse, you can also pre-bind with claim metadata or other matching rules so the right PV goes to the right ordinal.

That is especially helpful when each replica must get a specific existing dataset.

Plan the Binding Names Carefully

StatefulSet claim naming is predictable, and that predictability is what makes reuse possible. If the claim template is named data, the StatefulSet is named web, and the pod ordinal is 0, the generated PVC name will follow that pattern.

That lets you prepare existing storage ahead of time. The cluster does not need a dynamic provisioner if you have already created PVs that satisfy the claims.

The storage lifecycle is also important. Deleting or recreating pods does not automatically delete the associated volumes, which is one reason StatefulSet is the right controller for stateful workloads.

When Manual PVCs Make Sense

In some cases, instead of relying entirely on volumeClaimTemplates, teams pre-create PersistentVolumeClaims and reference them directly in a plain pod or Deployment. That can be simpler for a single-instance workload.

For a true StatefulSet, though, the claim-template pattern is usually better because each replica gets a stable claim identity. The challenge is just making sure the existing PVs are prepared to satisfy those claims.

Common Pitfalls

The biggest mistake is thinking PetSet or StatefulSet can directly "mount an existing PV" without the PVC binding layer. Kubernetes storage is built around PV and PVC matching, so the controller still expects claims.

Another common problem is mismatched storage classes or access modes. If the claim asks for fast-storage and the PV has no matching class, the claim will stay pending.

Capacity mismatches are another easy way to get stuck. The existing PV must satisfy the requested size, not just be close.

Finally, remember that PetSet is old terminology. If you search current Kubernetes documentation, the modern object is StatefulSet, so use that term in manifests and newer operational guides.

Summary

• 'PetSet was renamed to StatefulSet.'
• A StatefulSet uses PVCs, so existing storage must be exposed through matching PV and PVC bindings.
• Pre-provision existing PersistentVolumes with the right class, access mode, and capacity.
• Predictable claim names make per-replica storage reuse possible.
• If the claims stay pending, check the PV and PVC matching rules before anything else.