StatefulSets for stateful applications in Kubernetes - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a StatefulSet in Kubernetes?

A StatefulSet is a Kubernetes resource used to manage stateful applications. It ensures that pods have stable, unique network IDs and persistent storage, keeping their state across restarts.

intermediate

How does a StatefulSet differ from a Deployment?

Unlike Deployments, StatefulSets provide stable pod identities and persistent storage. Deployments are for stateless apps where pods are interchangeable, but StatefulSets keep pods ordered and unique.

beginner

What is the role of PersistentVolumeClaims (PVCs) in StatefulSets?

Each pod in a StatefulSet gets its own PersistentVolumeClaim, which provides stable storage that remains even if the pod is deleted or rescheduled. This keeps the pod's data safe.

intermediate

Explain the importance of stable network identities in StatefulSets.

Stable network IDs let each pod keep the same hostname and network identity even after restarts. This is important for apps like databases that need to recognize each other consistently.

intermediate

What happens when you scale down a StatefulSet?

When scaling down, pods are terminated in reverse order (highest ordinal first). Their storage remains, so if scaled back up, pods keep their data and identity.

Which Kubernetes resource is best for managing stateful applications?

A ReplicaSet

B Deployment

C DaemonSet

D StatefulSet

StatefulSet is designed for stateful apps needing stable identities and storage.

What does a StatefulSet guarantee for its pods?

A Random pod names and ephemeral storage

B Stable network IDs and persistent storage

C No storage and no network identity

D Pods are always scheduled on the same node

StatefulSets give pods stable network IDs and persistent storage.

How are pods terminated when scaling down a StatefulSet?

A In reverse ordinal order (highest number first)

B Random order

C In creation order (lowest number first)

D All at once

Pods are terminated starting from the highest ordinal number.

What is the purpose of PersistentVolumeClaims in StatefulSets?

A To provide stable storage for each pod

B To assign IP addresses

C To schedule pods on nodes

D To manage pod replicas

PVCs provide persistent storage that stays with each pod.

Which feature is NOT provided by StatefulSets?

A Stable pod hostnames

B Persistent storage

C Automatic load balancing

D Ordered pod deployment

Load balancing is handled by Services, not StatefulSets.

Describe how StatefulSets manage pod identity and storage for stateful applications.

Think about what makes stateful apps different from stateless ones.

Explain the difference between a Deployment and a StatefulSet in Kubernetes.

Focus on pod identity and storage.

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