DEV Community

Nitesh More
Nitesh More

Posted on

Pods, ReplicaSets, Deployments, and StatefulSets: What’s the Difference?

#devops #kubernetes #cka #ckad

When I started with Kubernetes, one of the most confusing things was figuring out why there are so many different objects just to run a container. I thought, “Why can’t I just run my app as a Pod and be done with it?”

Turns out, Pods are just the beginning. As you scale, update, and manage real-world apps, you’ll need ReplicaSets, Deployments, and sometimes StatefulSets. Let’s walk through each one in plain English.

pod

🟦 Pod: The Basic Building Block

A Pod is the smallest thing you can run in Kubernetes. It usually holds one container, sometimes more if they’re tightly coupled (like a sidecar).

Think of a Pod as a little wrapper around your app. It gives it an IP address, some storage, and a place to live inside the cluster.

The catch? Pods are ephemeral. If one dies, it’s gone. Kubernetes won’t automatically bring it back unless you add another layer on top.

👉 Example Pod:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80
Enter fullscreen mode Exit fullscreen mode

Great for testing. Not so great for production.

🟧 ReplicaSet: Keeping Things Alive

That’s where a ReplicaSet comes in. Imagine you want three Pods running at all times. If one crashes, the ReplicaSet creates a new one.

It’s like a babysitter for Pods — making sure the right number are always running.

👉 Example:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
Enter fullscreen mode Exit fullscreen mode

Still, ReplicaSets are rarely used directly. We usually let Deployments handle them.

🟨 Deployment: The Real Hero

A Deployment is what you’ll use most of the time. It manages ReplicaSets for you and makes rolling updates painless.

Say you want to update your app to a new version. With a Deployment, Kubernetes replaces Pods one by one, so your service never goes down. And if something breaks, you can roll back instantly.

👉 Example Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
Enter fullscreen mode Exit fullscreen mode

This is the bread and butter for running web apps, APIs, or really any stateless service.

🟩 StatefulSet: For Apps That Remember Things

Finally, there’s the StatefulSet. This one is special. While Deployments treat Pods as disposable, StatefulSets give each Pod a stable identity — along with its own persistent storage.

This is exactly what you need for databases, queues, or anything that can’t just “forget” its data when restarted.

  • Pods get predictable names (db-0, db-1, db-2).
  • Each Pod can have its own volume that sticks around even if the Pod is deleted.

👉 Example StatefulSet:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi
Enter fullscreen mode Exit fullscreen mode

Now each Pod (web-0, web-1) has its own storage that won’t get mixed up.

💡 Wrapping It Up

Here’s how I like to remember it:

  • Pod → Just runs your container. Great for testing, not production.
  • ReplicaSet → Babysits Pods, keeps the right number running.
  • Deployment → The real workhorse. Handles updates and rollbacks.
  • StatefulSet → For stateful apps like databases that need stable IDs and storage.

If you’re starting out, you’ll almost always use Deployments. When you need databases or apps that care about persistence, that’s when you bring in StatefulSets.

Everything else (Pods, ReplicaSets) are still there under the hood, but you don’t usually manage them directly.

👉 Next time you see kubectl get all showing Pods, ReplicaSets, Deployments, and maybe a StatefulSet, you’ll know exactly what role each one plays.

Top comments (0)