deployment-vs-statefulset.md

In Kubernetes, Deployment and StatefulSet are both controllers used to manage Pods, but they serve different purposes based on the application's requirements. Here’s a breakdown of their key differences:

1. Use Case

Deployment:
- Best for stateless applications (e.g., web servers, REST APIs).
- Pods are interchangeable (no unique identity or persistent storage).
- Scaling up/down or rolling updates don’t require stable identities or ordered operations.
StatefulSet:
- Designed for stateful applications (e.g., databases like MySQL, Kafka, Elasticsearch).
- Pods have stable, unique identities (pod-0, pod-1, etc.) and persistent storage.
- Ensures ordered, graceful deployment/scaling (Pods are created/terminated sequentially).

2. Pod Identity & Naming

Deployment:
- Pods get random hashes in their names (e.g., nginx-deploy-5c6f866d4b-2xz8q).
- No guaranteed hostname or network identity after rescheduling.
StatefulSet:
- Pods have fixed, ordered names (e.g., mysql-0, mysql-1).
- Hostname and DNS records remain stable even after Pod restarts.

3. Storage

Deployment:
- Typically uses shared storage (e.g., emptyDir or dynamically provisioned PersistentVolumeClaims).
- No guarantee of data retention if Pods are rescheduled.
StatefulSet:
- Uses dedicated, persistent storage per Pod (via volumeClaimTemplates).
- Each Pod gets its own PersistentVolume (PV), ensuring data persistence across restarts.

4. Scaling Behavior

Deployment:
- Scaling is instant and parallel (no order enforced).
- No guarantee of Pod startup/shutdown sequence.
StatefulSet:
- Scaling follows a strict order (e.g., scale up: pod-0 → pod-1 → pod-2; scale down: reverse order).
- Ensures data consistency in clustered applications (e.g., primary-replica databases).

5. Network Identity (DNS)

Deployment:
- Pods share the same Service DNS name (load-balanced).
- No individual DNS for each Pod.
StatefulSet:
- Each Pod gets a unique DNS entry (e.g., mysql-0.mysql-svc.default.svc.cluster.local).
- A headless Service (ClusterIP: None) is typically used to manage Pod DNS records.

6. Rolling Updates

Deployment:
- Supports rolling updates and rollbacks.
- Updates can be done in parallel (configurable via strategy).
StatefulSet:
- Updates are sequential (one Pod at a time, in reverse order).
- Ensures stateful applications maintain quorum during updates.

When to Use Which?

Feature	Deployment	StatefulSet
Stateless	✅ Yes	❌ No
Stateful	❌ No	✅ Yes
Scaling Speed	Fast & Parallel	Slow & Ordered
Stable Network ID	❌ No	✅ Yes
Persistent Storage	❌ (Shared)	✅ (Per Pod)
Use Cases	Web apps, APIs	Databases, message queues

Example YAML Snippets

Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest

StatefulSet

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql-svc  # Requires a headless Service
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        volumeMounts:
        - name: mysql-data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:  # Each Pod gets its own PVC
  - metadata:
      name: mysql-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

Summary

Use Deployment for stateless, scalable, and replaceable Pods (e.g., frontend apps).
Use StatefulSet for stateful apps requiring stable identities, ordered scaling, and persistent storage (e.g., databases).

gengwg/deployment-vs-statefulset.md