StatefulSets for stateful applications in Kubernetes - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a StatefulSet with the correct API version.

Kubernetes

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

Drag options to blanks, or click blank then click option'

Av1

Bv1beta1

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'v1' directly without 'apps/' prefix

Using 'core/v1' which is for Pods and Services

The correct API version for StatefulSet is apps/v1.

2fill in blank

medium

Complete the code to specify the volumeClaimTemplates section for persistent storage.

Kubernetes

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

Drag options to blanks, or click blank then click option'

Apersistent

Bstorage

Cvolume

Ddata

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'storage' which is a resource request, not a name

Using 'persistent' which is not a typical volume claim name

The name under volumeClaimTemplates is typically called data to represent the persistent volume claim for the pod.

3fill in blank

hard

Fix the error in the selector section to correctly match the pod labels.

Kubernetes

selector:
  matchLabels:
    app: [1]

Drag options to blanks, or click blank then click option'

Anginx

Bnginx-app

Capp

Dweb

Attempts:

3 left

💡 Hint

Common Mistakes

Using a different label value than the pod template

Using the key instead of the value

The selector must match the label used in the pod template. Here, the pod label is app: nginx, so the selector should match nginx.

4fill in blank

hard

Fill both blanks to complete the container volume mount and volume claim reference.

Kubernetes

containers:
- name: nginx
  image: nginx:1.15.4
  volumeMounts:
  - name: [1]
    mountPath: [2]

Drag options to blanks, or click blank then click option'

Adata

B/usr/share/nginx/html

C/var/lib/data

Dstorage

Attempts:

3 left

💡 Hint

Common Mistakes

Mismatching volumeMount name and volumeClaimTemplates name

Using an incorrect mountPath for nginx

The volumeMount name must match the volumeClaimTemplates name, which is 'data'. The mountPath is the directory inside the container where the volume is mounted, commonly /usr/share/nginx/html for nginx.

5fill in blank

hard

Fill all three blanks to complete the StatefulSet spec with replicas, serviceName, and pod label.

Kubernetes

spec:
  replicas: [1]
  serviceName: "[2]"
  template:
    metadata:
      labels:
        app: [3]

Drag options to blanks, or click blank then click option'

Aweb

B3

Cnginx

Dfrontend

Attempts:

3 left

💡 Hint

Common Mistakes

Using a string for replicas instead of a number

Mismatching serviceName and pod labels

The number of replicas is 3 for three pods. The serviceName is 'nginx' to match the headless service. The pod label 'app' is set to 'nginx' to match the selector.

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