StatefulSets for stateful applications in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use StatefulSets instead of Deployments for databases?

Which of the following reasons best explains why StatefulSets are preferred over Deployments for running databases in Kubernetes?

A StatefulSets allow pods to share the same storage volume, making data sharing easier for databases.

B StatefulSets automatically scale pods horizontally without any configuration, unlike Deployments.

C StatefulSets restart pods faster than Deployments, improving database availability.

D StatefulSets provide stable network IDs and persistent storage for each pod, which databases need to maintain data consistency.

💡 Hint

Think about what databases need to keep their data safe and consistent even if pods restart.

StatefulSets assign stable network IDs and persistent storage to each pod, which is essential for databases to maintain consistent data. Deployments do not guarantee stable identities or storage.

💻 Command Output

intermediate

Output of StatefulSet pod names

Given a StatefulSet named web with 3 replicas, what will be the output of the command kubectl get pods -l app=web -o custom-columns=NAME:.metadata.name --no-headers?

Kubernetes

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "web"
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx

A

web-1
web-2
web-3

B

web
web
web

C

web-0
web-1
web-2

D

web-0
web-1

💡 Hint

StatefulSet pods have stable, ordinal names starting at 0.

StatefulSet pods are named with the StatefulSet name plus an ordinal index starting at 0, so the pods are web-0, web-1, and web-2.

❓ Configuration

advanced

Correct volumeClaimTemplates for StatefulSet

Which of the following volumeClaimTemplates configurations correctly creates persistent volumes for each pod in a StatefulSet?

Kubernetes

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  replicas: 2
  selector:
    matchLabels:
      app: db
  serviceName: "db"
  template:
    metadata:
      labels:
        app: db
    spec:
      containers:
      - name: mysql
        image: mysql
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:

A

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

B

- metadata:
    name: data
  spec:
    accessModes: ["ReadWriteMany"]
    resources:
      requests:
        storage: 1Gi

C

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

D

- metadata:
    name: data
  spec:
    accessModes: ["ReadWriteOnce"]
    resources:
      limits:
        storage: 1Gi

💡 Hint

Think about the access mode that allows a single pod to write to its volume.

StatefulSet pods require ReadWriteOnce access mode for persistent volumes so each pod can write to its own volume exclusively. ReadWriteMany or ReadOnlyMany are not suitable here.

❓ Troubleshoot

advanced

Why does a StatefulSet pod fail to attach volume?

A StatefulSet pod fails to start with an error about volume attachment. The volumeClaimTemplates are correct. What is the most likely cause?

A The PersistentVolumeClaim is bound to a PersistentVolume in a different availability zone than the pod.

B The pod's container image is missing the volume mount path.

C The StatefulSet replicas count is set to zero.

D The pod label selector does not match the StatefulSet selector.

💡 Hint

Consider cloud storage constraints related to zones or regions.

In cloud environments, PersistentVolumes are often tied to specific zones. If a pod schedules in a different zone than the volume, it cannot attach the volume, causing startup failure.

🔀 Workflow

expert

Order of pod termination in StatefulSet rolling update

During a rolling update of a StatefulSet with 3 replicas, in which order are the pods terminated and updated?

A 3,1,2

B 3,2,1

C 2,3,1

D 1,2,3

💡 Hint

Think about the ordinal index order StatefulSets use for updates.

StatefulSets update pods in reverse ordinal order, starting from the highest index pod (web-2) down to the lowest (web-0), to maintain stable identity and availability.

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