StatefulSets for stateful applications in Kubernetes - Step-by-Step Execution

Process Flow - StatefulSets for stateful applications

Define StatefulSet YAML

↓

kubectl apply StatefulSet

↓

Controller creates Pod 0

↓

Pod 0 gets stable network ID & storage

↓

Controller creates Pod 1

↓

Pod 1 gets stable network ID & storage

↓

Pods run with stable identity

↓

Scaling up/down maintains order & identity

↓

Pods terminate gracefully preserving data

Shows how Kubernetes StatefulSet creates pods one by one with stable network IDs and storage, maintaining order and identity for stateful apps.

Execution Sample

Kubernetes

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
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

Defines a StatefulSet named 'web' with 2 replicas, each pod gets stable network ID and storage.

Process Table

Step	Action	Pod Created	Pod Identity	Storage Volume	Status
1	Apply StatefulSet YAML	None	None	None	StatefulSet resource created
2	Controller creates first pod	web-0	web-0.nginx	PVC web-0	Pending -> Running
3	First pod ready	web-0	web-0.nginx	PVC web-0	Running
4	Controller creates second pod	web-1	web-1.nginx	PVC web-1	Pending -> Running
5	Second pod ready	web-1	web-1.nginx	PVC web-1	Running
6	Scale down to 1 replica	web-1 deleted	web-1.nginx removed	PVC web-1 retained	web-0 running
7	Scale up to 2 replicas	web-1 recreated	web-1.nginx	PVC web-1 reused	Running

💡 Pods created in order with stable network IDs and storage; scaling preserves identity and data.

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	After Step 7
Pods	None	[web-0]	[web-0, web-1]	[web-0]	[web-0, web-1]
Pod Identities	None	[web-0.nginx]	[web-0.nginx, web-1.nginx]	[web-0.nginx]	[web-0.nginx, web-1.nginx]
Storage PVCs	None	[PVC web-0]	[PVC web-0, PVC web-1]	[PVC web-0, PVC web-1]	[PVC web-0, PVC web-1]

Key Moments - 3 Insights

Why does the controller create pods one at a time instead of all at once?

The controller creates pods sequentially to ensure each pod gets a stable network ID and storage before the next pod starts, as shown in steps 2 and 4 of the execution_table.

What happens to the storage volumes when a pod is deleted during scale down?

The storage volumes (PVCs) are retained even if the pod is deleted, preserving data for when the pod is recreated, as seen in step 6 where PVC web-1 remains after pod deletion.

How does the StatefulSet maintain pod identity after scaling down and up?

When scaling down, pods are deleted but their identities and storage are preserved. When scaling up, pods are recreated with the same network IDs and storage volumes, as shown in steps 6 and 7.

Visual Quiz - 3 Questions

Look at the execution_table at step 4. Which pod is created and what is its network identity?

A Pod web-2 with network ID web-2.nginx

B Pod web-0 with network ID web-0.nginx

C Pod web-1 with network ID web-1.nginx

D No pod created at step 4

💡 Hint

Check the 'Pod Created' and 'Pod Identity' columns at step 4 in the execution_table.

At which step does the StatefulSet controller delete a pod during scaling down?

A Step 6

B Step 5

C Step 3

D Step 7

💡 Hint

Look for the row mentioning pod deletion in the 'Action' column in the execution_table.

If the number of replicas was increased to 3 initially, how would the variable_tracker's 'Pods' row change after step 4?

A [web-0, web-1, web-2]

B [web-0, web-1]

C [web-0]

D None

💡 Hint

The controller creates pods one at a time; after step 4 only two pods exist as per execution_table.

Concept Snapshot

StatefulSets manage stateful apps by creating pods in order.
Each pod gets a stable network ID and persistent storage.
Pods start one by one; scaling preserves pod identity and data.
Storage volumes (PVCs) are retained even if pods are deleted.
Use StatefulSets for apps needing stable network and storage.

Full Transcript

StatefulSets in Kubernetes help run stateful applications by creating pods one at a time. Each pod gets a stable network name and persistent storage volume. The controller applies the StatefulSet YAML, then creates pod web-0 with identity web-0.nginx and storage PVC web-0. Once web-0 is running, it creates web-1 similarly. When scaling down, pods are deleted but their storage volumes remain. Scaling up recreates pods with the same identity and storage. This ensures data is preserved and pods have stable network IDs, which is important for databases and other stateful apps.

Practice

1. What is the main purpose of a StatefulSet in Kubernetes?

easy

A. To scale stateless applications quickly without persistent storage

B. To provide load balancing for stateless services

C. To manage stateful applications with stable network IDs and persistent storage

D. To automatically update container images in deployments

Solution

1. Step 1: Understand StatefulSet role

   StatefulSets manage pods that need stable identities and persistent storage, unlike Deployments for stateless apps.

2. Step 2: Compare options

   Only To manage stateful applications with stable network IDs and persistent storage describes stable network IDs and persistent storage, key features of StatefulSets.

3. Final Answer:

   To manage stateful applications with stable network IDs and persistent storage -> Option C

4. Quick Check:

   StatefulSet = stable IDs + storage [OK]

Hint: StatefulSets = stable pod names + persistent storage [OK]

Common Mistakes:

• Confusing StatefulSet with Deployment
• Thinking StatefulSet is for stateless apps
• Ignoring persistent storage role

2. Which of the following is the correct way to specify a volumeClaimTemplates section in a StatefulSet YAML?

easy

A. volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 1Gi

B. volumeClaimTemplates:
name: data
spec:
accessModes: ["ReadWriteMany"]
resources:
requests:
storage: 1Gi

C. volumeClaimTemplates:
- name: data
spec:
accessModes: ["ReadWriteOnce"]
resources:
limits:
storage: 1Gi

D. volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: ["ReadOnlyMany"]
resources:
requests:
storage: 1Gi

Solution

1. Step 1: Check YAML structure for volumeClaimTemplates

   volumeClaimTemplates must be a list with items having metadata and spec sections.

2. Step 2: Validate accessModes and resource requests

   Access mode "ReadWriteOnce" is typical for StatefulSet volumes; requests use storage size under resources.

3. Final Answer:

   volumeClaimTemplates with metadata name, spec accessModes ReadWriteOnce, and storage requests -> Option A

4. Quick Check:

   volumeClaimTemplates list with metadata + spec = A [OK]

Hint: volumeClaimTemplates is a list with metadata and spec [OK]

Common Mistakes:

• Missing metadata block under volumeClaimTemplates
• Using accessModes not supported for StatefulSets
• Incorrect indentation or YAML structure

3. Given this StatefulSet pod name pattern: web-0, web-1, web-2, what will be the hostname of the pod web-1 inside the cluster?

medium

A. web-1

B. web-1.default.svc.cluster.local

C. web-1..default.svc.cluster.local

D. web-1..default.svc.cluster.local

Solution

1. Step 1: Understand StatefulSet DNS naming

   Each pod gets a stable hostname: <podname>. within the namespace.

2. Step 2: Identify full DNS format

   Full DNS is <podname>..<namespace>.svc.cluster.local, so pod web-1's hostname includes the service name.

3. Final Answer:

   web-1.<service-name>.default.svc.cluster.local -> Option D

4. Quick Check:

   Pod hostname = podname.service.namespace.svc.cluster.local [OK]

Hint: Pod hostname includes service name, not StatefulSet name [OK]

Common Mistakes:

• Using StatefulSet name instead of service name in hostname
• Ignoring full DNS suffix
• Assuming hostname is just pod name

4. You created a StatefulSet but notice pods are stuck in Pending state. Which of these is the most likely cause?

medium

A. The volumeClaimTemplates request more storage than available in the cluster

B. The StatefulSet spec is missing the container image field

C. The StatefulSet replicas count is set to zero

D. The pod labels do not match the StatefulSet selector

Solution

1. Step 1: Analyze Pending pod reason

   Pods stuck in Pending often mean resources like storage or compute are unavailable.

2. Step 2: Check volumeClaimTemplates impact

   If requested storage exceeds cluster capacity, PersistentVolumeClaims remain unbound, blocking pod start.

3. Final Answer:

   VolumeClaimTemplates request more storage than cluster can provide -> Option A

4. Quick Check:

   Pending pods often mean storage or resource shortage [OK]

Hint: Pending pods often mean storage or resource shortage [OK]

Common Mistakes:

• Assuming missing image causes Pending (it causes CrashLoopBackOff)
• Thinking zero replicas create Pending pods (no pods created)
• Ignoring label-selector mismatch effects

5. You want to update the container image of a StatefulSet without downtime, ensuring pods restart one by one in order. Which update strategy should you use?

hard

A. RollingUpdate with partition set to the last pod index

B. RollingUpdate with partition set to 0

C. OnDelete update strategy

D. Recreate update strategy

Solution

1. Step 1: Understand StatefulSet update strategies

   RollingUpdate updates pods in order, respecting pod ordinal index; partition controls which pods update.

2. Step 2: Use partition to control update order

   Setting partition to 0 (default) updates all pods sequentially from the highest ordinal index down to 0, one by one without downtime.

3. Final Answer:

   RollingUpdate with partition set to 0 -> Option B

4. Quick Check:

   Partition controls pod update order in RollingUpdate [OK]

Hint: Use RollingUpdate with partition to update pods one by one [OK]

Common Mistakes:

• Using OnDelete causes manual pod restarts, not automatic
• Recreate deletes all pods causing downtime
• RollingUpdate with partition set to the last pod index only updates higher ordinal pods