Introduction

PetSet is the historical name for what Kubernetes now calls a StatefulSet. If you are deploying a stateful workload on Google Cloud today, the correct workload object is StatefulSet, not PetSet. The underlying use case is the same: stable pod identities, persistent storage, and ordered rollout behavior for applications such as databases, brokers, and clustered services.

On Google Kubernetes Engine, a modern answer means combining a StatefulSet with a headless Service and persistent volumes. Once those pieces are in place, each replica gets a stable pod name and a durable volume that survives pod rescheduling.

Why StatefulSet Replaced PetSet

Stateful workloads differ from stateless replicas in two important ways:

• each pod may need a stable network identity
• each pod may need storage that stays attached to that logical replica over time

A Deployment does not guarantee those identities. A StatefulSet does. That is why the old PetSet concept evolved into today's StatefulSet API.

In GKE, that means you should use a StatefulSet whenever replica identity matters, such as db-0, db-1, and db-2, each with its own persistent volume.

Start With a Headless Service

A StatefulSet relies on a headless Service for stable DNS identities.

1apiVersion: v1
2kind: Service
3metadata:
4  name: web
5spec:
6  clusterIP: None
7  selector:
8    app: web
9  ports:
10    - port: 80
11      targetPort: 8080

With this in place, pods get predictable names such as web-0.web, web-1.web, and so on within the cluster DNS system.

Create the StatefulSet

A basic GKE-friendly StatefulSet looks like this:

1apiVersion: apps/v1
2kind: StatefulSet
3metadata:
4  name: web
5spec:
6  serviceName: web
7  replicas: 3
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:1.27
19          ports:
20            - containerPort: 8080
21          volumeMounts:
22            - name: data
23              mountPath: /usr/share/nginx/html
24  volumeClaimTemplates:
25    - metadata:
26        name: data
27      spec:
28        accessModes: ["ReadWriteOnce"]
29        resources:
30          requests:
31            storage: 10Gi

Apply it with:

kubectl apply -f service.yaml
kubectl apply -f statefulset.yaml

Each replica gets its own persistent volume claim derived from volumeClaimTemplates. That is the storage behavior stateful workloads usually need.

What This Gives You on GKE

With a StatefulSet, GKE provides the Kubernetes guarantees that matter for stateful apps:

• ordered pod creation and deletion
• stable pod names
• durable volume attachment per replica
• rolling updates that respect pod ordering

This is important for clustered systems that bootstrap in sequence or replicate data between known peers.

It is also worth remembering what Kubernetes does not do for you. A StatefulSet helps with orchestration identity and storage binding, but it does not turn any application into a distributed database automatically. Your application still needs its own clustering and recovery logic.

Operate It Carefully

Check the rollout and the claims after deployment:

kubectl get statefulset web
kubectl get pods -l app=web
kubectl get pvc

When scaling, Kubernetes preserves the pod ordinals. If you scale from 3 replicas down to 1, the PVCs are not automatically deleted. That is intentional for data safety.

If you need to delete the workload entirely, plan the storage lifecycle explicitly. Stateful storage should never disappear by surprise.

Common Pitfalls

The biggest mistake is following old PetSet wording literally and searching for an obsolete API object. The current object is StatefulSet.

Another issue is forgetting the headless Service. Without it, stable pod DNS identities do not work as expected.

A third problem is assuming persistent volumes disappear automatically when the StatefulSet scales down or is deleted. They generally do not, and that is usually the safe behavior.

Summary

• 'PetSet is the historical predecessor of today's StatefulSet.'
• On Google Cloud and GKE, use StatefulSet for workloads that need stable identity and persistent storage.
• Pair the StatefulSet with a headless Service for stable network names.
• Use volumeClaimTemplates so each replica gets its own persistent volume claim.
• Treat storage lifecycle as a deliberate operational decision, not an automatic cleanup side effect.