StatefulSets for stateful applications in Kubernetes - Mini Project: Build & Apply

StatefulSets for stateful applications

📖 Scenario: You are managing a database application that needs stable network IDs and persistent storage. You will create a Kubernetes StatefulSet to ensure each database pod has a unique identity and stable storage.

🎯 Goal: Build a Kubernetes StatefulSet manifest for a simple stateful application with 3 replicas, stable network IDs, and persistent volume claims.

📋 What You'll Learn

Create a StatefulSet manifest with 3 replicas

Use a container image nginx:1.21

Set the serviceName to nginx

Add a volumeClaimTemplates for persistent storage

Print the final StatefulSet manifest YAML

💡 Why This Matters

🌍 Real World

StatefulSets are used to deploy databases, caches, and other applications that need stable network IDs and persistent storage in Kubernetes.

💼 Career

Understanding StatefulSets is essential for DevOps engineers managing stateful applications on Kubernetes clusters.

1

Create the basic StatefulSet structure

Create a YAML manifest for a StatefulSet named nginx with 3 replicas and serviceName set to nginx. Include the apiVersion as apps/v1 and kind as StatefulSet. Do not add containers or volumes yet.

Kubernetes

# Your YAML manifest starts here
# Define apiVersion, kind, metadata with name nginx, spec with replicas 3 and serviceName nginx

Hint

Start by defining the basic StatefulSet fields: apiVersion, kind, metadata.name, and spec.replicas with spec.serviceName.

2

Add the container specification

Inside the spec.template.spec, add a container named nginx using the image nginx:1.21. Do not add volume mounts yet.

Kubernetes

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx
spec:
  replicas: 3
  serviceName: nginx
  template:
    spec:
      # Add containers list here
      # Your code here

Hint

Remember to nest containers under spec.template.spec. Use a list with one container named nginx and image nginx:1.21.

3

Add persistent volume claim template

Add a volumeClaimTemplates section under spec with one claim named nginx-pvc. It should request 1Gi storage with access mode ReadWriteOnce.

Kubernetes

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx
spec:
  replicas: 3
  serviceName: nginx
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
  # Add volumeClaimTemplates here
  # Your code here

Hint

Use volumeClaimTemplates under spec to define persistent storage for each pod. Set accessModes and resources.requests.storage properly.

4

Print the complete StatefulSet manifest

Print the full StatefulSet YAML manifest you created so far.

Kubernetes

# Print the StatefulSet manifest
# Your code here

Hint

Use multiple print statements to output each line of the YAML manifest exactly as written.

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