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.