Kubernetes Deployment vs StatefulSet: Choosing the Right Workload Strategy

Voiced by Amazon Polly

When managing applications in Kubernetes, two important options for running workloads are Deployments and StatefulSets. While they may seem similar at first glance, they serve different purposes, particularly when dealing with the statefulness or statelessness of the application. This blog will explore what each object is, the key differences, the benefits of using each, and a practical lab exercise to apply this knowledge.

Customized Cloud Solutions to Drive your Business Success

Cloud Migration
Devops
AIML & IoT

Know More

What is a Deployment?

A Deployment in Kubernetes is used to manage stateless applications. These are applications that do not require persistent data across pod restarts. A Deployment ensures that a specific number of pod replicas are running at any given time, and it handles updates and rollbacks of the application with ease.

Key Characteristics of Deployments:

Stateless Applications: Each pod in a Deployment is independent, meaning no pod stores data that is required for its future restarts or replacements. If a pod crashes or needs to be updated, a new one is simply created to take its place.
- Use cases: Web servers (like Nginx or Apache), microservices, and APIs that do not retain data locally.
Pod Scalability and Replication: Deployments allow you to specify how many pod replicas you want to run. Kubernetes will maintain this number even if individual pods fail.
Rolling Updates and Rollbacks: Deployments offer the ability to perform rolling updates, gradually replacing old pods with new ones. If an update goes wrong, a rollback can easily revert to the last known good state.
No Pod Identity: In a Deployment, individual pods have no stable or unique identities. They are interchangeable.

Benefits of Deployments:

Easy Updates: With rolling updates, your application can be updated without downtime, ensuring a smooth transition to new versions.
Self-Healing: If a pod crashes, Kubernetes automatically replaces it, ensuring high availability.
High Scalability: Deployments allow for easy scaling by simply increasing the number of replicas.

When to Use Deployments:

Use for stateless workloads like web servers, RESTful APIs, or microservices where each pod performs the same task without needing persistent data.
Applications that can handle pods being replaced without concern for data persistence or unique identities.

What is a StatefulSet?

StatefulSets are designed to manage stateful applications, where each pod requires a unique identity and persistent storage. Unlike Deployments, which treat all pods as equal, StatefulSets ensure that each pod has a stable network identity and retains its own storage, even if it’s recreated or rescheduled.

Key Characteristics of StatefulSets:

Stateful Applications: Ideal for applications that require a unique, persistent identity, such as databases (MySQL, PostgreSQL), distributed systems (Kafka, Elasticsearch), and caching systems (Redis).
- Use cases: Databases, distributed applications where order and identity matter, or any app requiring persistent storage across restarts.
Stable Network Identity: Each pod in a StatefulSet gets a unique, persistent name. Even if a pod is rescheduled or restarted, it will always retain its original identity (e.g., redis-0, redis-1).
Persistent Storage: StatefulSets work with Persistent Volume Claims (PVCs) to ensure that each pod has its own storage that survives restarts and doesn’t interfere with other pods.
Ordered Operations: Pods are created, scaled, and terminated in order. This ensures that specific dependencies are met before changes are made, which is important for distributed systems.

Benefits of StatefulSets:

Unique Pod Identity: Each pod retains its name and identity, allowing for more predictable behavior in stateful applications.
Persistent Volumes: Ensures that every pod has its own volume, even after it is recreated, which is crucial for databases and other apps that store data.
Ordered Scaling: Pods are created and destroyed in a specific order, ensuring dependencies are respected.

When to Use StatefulSets:

Use for stateful workloads like databases (MySQL, PostgreSQL), distributed data stores (Cassandra, Kafka), or any other service requiring persistent data and stable identities.
Applications where pod identity, storage, and startup order matter.

Comparison Table:

Feature	Deployments	StatefulSets
Pod Identity	No stable identity, pods are stateless	Each pod has a stable, unique identity
Pod Creation Order	No guaranteed order	Pods are created and deleted in order
Storage	No persistent storage	Each pod has its persistent storage
Use Case	Stateless applications (web apps, APIs)	Stateful applications (databases, Kafka)
Rolling Updates	Yes	Yes, but pods are updated in order
Pod Failures	Automatically replaced	Automatically replaced, with identity preserved

Hands-On: Demonstrating the Difference Between Deployments and StatefulSets

This lab will walk you through creating a Deployment and a StatefulSet in Kubernetes, highlighting the key differences between how each one handles pod creation, scaling, and persistence. You will see how Deployments treat pods as stateless entities, while StatefulSets assign unique identities and persistent storage to each pod.

Lab Overview:

Goal: Deploy two simple applications (one with a Deployment and one with a StatefulSet) and observe their behavior.
Tools Required:
- A running Kubernetes cluster
- kubectl CLI configured for your cluster.

Step 1: Create a Deployment (Stateless Application)

We will first create a stateless application using a Deployment. In this case, we will use Nginx (a simple web server) as an example.

Deployment YAML Definition:

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:latest

        ports:

        - containerPort: 80

apiVersion: apps/v1

kind: Deployment

metadata:

spec:

replicas: 3

selector:

matchLabels:

app: nginx

template:

metadata:

labels:

app: nginx

spec:

containers:

- name: nginx

image: nginx:latest

ports:

- containerPort: 80

Apply the deployment:

kubectl apply -f nginx-deployment.yaml

1	kubectl apply -f nginx-deployment.yaml

Verify the Deployment:

Check if the deployment and pods are running:

kubectl get deployments

kubectl get pods -l app=nginx

kubectl get deployments

kubectl get pods -l app=nginx

You should see 3 Nginx pods running. Each pod is stateless and does not have a unique identity. Kubernetes can delete or replace any pod, and the new one will work just as well.

Observe Pod Names:

Run the following command to view the pod names:

kubectl get pods -l app=nginx -o wide

1	kubectl get pods -l app=nginx -o wide

You’ll see random pod names like nginx-deployment-xxxx-xxxx. These pod names are dynamically generated and do not have any persistent identity.

Step 2: Create a StatefulSet (Stateful Application)

Now, we will create a StatefulSet for a stateful application using Redis. Redis requires stable pod identities and persistent storage, making it a good example for a StatefulSet.

StatefulSet YAML Definition:

apiVersion: apps/v1

kind: StatefulSet

metadata:

  name: redis

spec:

  serviceName: "redis"

  replicas: 3

  selector:

    matchLabels:

      app: redis

  template:

    metadata:

      labels:

        app: redis

    spec:

      containers:

      - name: redis

        image: redis:6.0

        ports:

        - containerPort: 6379

        volumeMounts:

        - name: redis-data

          mountPath: /data

  volumeClaimTemplates:

  - metadata:

      name: redis-data

    spec:

      accessModes: [ "ReadWriteOnce" ]

      resources:

        requests:

          storage: 1Gi

apiVersion: apps/v1

kind: StatefulSet

metadata:

spec:

serviceName: "redis"

replicas: 3

selector:

matchLabels:

app: redis

template:

metadata:

labels:

app: redis

spec:

containers:

- name: redis

image: redis:6.0

ports:

- containerPort: 6379

volumeMounts:

- name: redis-data

mountPath: /data

volumeClaimTemplates:

- metadata:

spec:

accessModes: [ "ReadWriteOnce" ]

resources:

requests:

storage: 1Gi

Apply the StatefulSet:

kubectl apply -f redis-statefulset.yaml

1	kubectl apply -f redis-statefulset.yaml

Verify the StatefulSet:

Check if the StatefulSet and its pods are running:

kubectl get statefulsets

kubectl get pods -l app=redis

kubectl get statefulsets

kubectl get pods -l app=redis

You should see three Redis pods running. Notice that each pod has a predictable name such as redis-0, redis-1, and redis-2. These names reflect the ordered nature of StatefulSet pods.

Step 3: Compare Pod Behavior

Deleting and Replacing Pods (Stateless vs Stateful)

Delete a pod from the Deployment (Nginx):

kubectl delete pod &lt;nginx-pod-name&gt;

1	kubectl delete pod <nginx-pod-name>

Run kubectl get pods again. You will notice that Kubernetes quickly replaces the deleted Nginx pod with a new one, but the new pod has a completely different name. This shows that Deployments treat pods as replaceable and stateless entities.

Delete a pod from the StatefulSet (Redis):

kubectl delete pod redis-0

1	kubectl delete pod redis-0

Run kubectl get pods. You will observe that Kubernetes recreates redis-0 with the same name. Unlike Deployments, StatefulSets ensure that each pod retains its identity and, if persistent storage is attached, its data.

Pod Scaling Behavior

Scale the Nginx Deployment:

kubectl scale deployment nginx-deployment --replicas=5

1	kubectl scale deployment nginx-deployment --replicas=5

Check the pods:

kubectl get pods -l app=nginx

1	kubectl get pods -l app=nginx

You will see 5 pods, all with randomly generated names. The order in which these pods are created does not matter.

Scale the Redis StatefulSet:

kubectl scale statefulset redis --replicas=5

1	kubectl scale statefulset redis --replicas=5

Check the Redis pods:

kubectl get pods -l app=redis

1	kubectl get pods -l app=redis

You will notice that two additional Redis pods are created, following the naming pattern redis-3 and redis-4. The StatefulSet creates these new pods in order, ensuring that each pod has a stable identity.

Persistence Behavior (Redis StatefulSet)

StatefulSets ensure that each pod gets its own Persistent Volume. Let’s verify this by checking the Persistent Volume Claims (PVCs):

kubectl get pvc

1	kubectl get pvc

You will see a PVC for each Redis pod, such as redis-data-redis-0, redis-data-redis-1, etc. This guarantees that each pod has its own storage, which is not shared with other pods.

Step 4: Clean Up Resources

After completing the lab, clean up your resources by deleting the Deployment and StatefulSet:

kubectl delete deployment nginx-deployment

kubectl delete statefulset redis

kubectl delete deployment nginx-deployment

kubectl delete statefulset redis

Also, delete the Persistent Volume Claims (PVCs) for the Redis pods:

kubectl delete pvc -l app=redis

1	kubectl delete pvc -l app=redis

Conclusion

Both Deployments and StatefulSets are critical components of Kubernetes but serve distinct purposes. Deployments are best for stateless applications where scalability and fast updates are required, while StatefulSets are ideal for stateful applications needing persistent storage, stable identities, and ordered deployment. Understanding these differences helps ensure you use the right tool for the right workload, making your applications more robust and efficient.
This lab demonstrated the key differences between Deployments and StatefulSets in Kubernetes:

Deployments are ideal for stateless applications, where pods are interchangeable, and no unique identity or persistent storage is required.
StatefulSets are necessary for stateful applications that require stable identities, ordered deployment, and persistent storage.

By going through this lab, you have seen firsthand how these two Kubernetes objects handle pod lifecycle, scaling, and persistence differently.

Get your new hires billable within 1-60 days. Experience our Capability Development Framework today.

Cloud Training
Customized Training
Experiential Learning

About CloudThat

CloudThat is a leading provider of Cloud Training and Consulting services with a global presence in India, the USA, Asia, Europe, and Africa. Specializing in AWS, Microsoft Azure, GCP, VMware, Databricks, and more, the company serves mid-market and enterprise clients, offering comprehensive expertise in Cloud Migration, Data Platforms, DevOps, IoT, AI/ML, and more.

CloudThat is the first Indian Company to win the prestigious Microsoft Partner 2024 Award and is recognized as a top-tier partner with AWS and Microsoft, including the prestigious ‘Think Big’ partner award from AWS and the Microsoft Superstars FY 2023 award in Asia & India. Having trained 650k+ professionals in 500+ cloud certifications and completed 300+ consulting projects globally, CloudThat is an official AWS Advanced Consulting Partner, Microsoft Gold Partner, AWS Training Partner, AWS Migration Partner, AWS Data and Analytics Partner, AWS DevOps Competency Partner, AWS GenAI Competency Partner, Amazon QuickSight Service Delivery Partner, Amazon EKS Service Delivery Partner, AWS Microsoft Workload Partners, Amazon EC2 Service Delivery Partner, Amazon ECS Service Delivery Partner, AWS Glue Service Delivery Partner, Amazon Redshift Service Delivery Partner, AWS Control Tower Service Delivery Partner, AWS WAF Service Delivery Partner and many more.