|
| 1 | +--- |
| 2 | +docs/9-kubernetes-container-orchestration/9.2.1-stateful-sets.md: |
| 3 | + category: Container Orchestration |
| 4 | + estReadingMinutes: 10 |
| 5 | + exercises: |
| 6 | + - |
| 7 | + name: Stateful Sets |
| 8 | + description: Create a simple StatefulSet in Kubernetes, understand the lifecycle of StatefulSets. |
| 9 | + estMinutes: 120 |
| 10 | + technologies: |
| 11 | + - Kubernetes |
| 12 | + - StatefulSets |
| 13 | +--- |
| 14 | + |
| 15 | +# 9.2.1 Stateful Sets |
| 16 | + |
| 17 | +StatefulSets are a type of workload controller in Kubernetes specifically designed to manage stateful applications—applications that require persistent storage and stable identities for their Pods. Unlike Deployments, where Pods are interchangeable and ephemeral, StatefulSets provide “sticky” identities and guarantees that each Pod maintains a unique, stable network identity and persistent storage across rescheduling, scaling, and updates. |
| 18 | + |
| 19 | +This stickiness is crucial for stateful workloads such as databases, message queues, and distributed systems, where each instance must maintain its state consistently and be reachable by other Pods in a predictable manner. |
| 20 | + |
| 21 | +For more information, see the [Kubernetes documentation](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/). |
| 22 | + |
| 23 | +## Exercise 1 - Stateful Sets |
| 24 | + |
| 25 | +1. Destroy and recreate a new cluster. |
| 26 | +`unset KUBECONFIG; k3d cluster delete <cluster-name>; k3d cluster create <cluster-name>`. |
| 27 | + |
| 28 | +2. Copy the contents of `examples/ch9/volumes/random-num-pod.yaml` into a new file called `examples/ch9/statefulsets/random-num-statefulset.yaml` and modify it to use a `StatefulSet` resource instead of a `Pod` resource. Set the number of replicas to 3. |
| 29 | + |
| 30 | +> To prevent the container from dying and restarting, add a sleep command to the container: |
| 31 | + `args: ["shuf -i 0-100 -n 1 >> /opt/number.out; sleep 10000"]`. |
| 32 | +
|
| 33 | +?> [VolumeClaimTemplates](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#volume-claim-templates) give each statefulset replica an automatically managed, per-pod persistent volume that sticks to the Pod’s ordinal, avoids manual PVC creation, and prevents unsafe volume sharing. |
| 34 | + |
| 35 | +3. Apply the `StatefulSet` to the cluster. |
| 36 | + |
| 37 | +4. Exec into each pod and view the contents of `/opt/number.out` or use the command: |
| 38 | +```shell |
| 39 | +kubectl get pods -l app=<statefulset-label> -o name | xargs -I {} sh -c 'echo {}; kubectl exec {} -- cat /opt/number.out' |
| 40 | +``` |
| 41 | + |
| 42 | +5. Delete one of the pods from the `StatefulSet`, run the command again and observe the output. |
| 43 | + |
| 44 | +## Exercise 2 - More Stateful Sets |
| 45 | + |
| 46 | +Navigate to `examples/ch9/statefulsets/counterapp/`, there is a Dockerfile and a directory `src` which contains a simple web application that displays a counter and the name of the pod it's running on. |
| 47 | + |
| 48 | +1. Destroy and recreate a new cluster. |
| 49 | +`unset KUBECONFIG; k3d cluster delete <cluster-name>; k3d cluster create <cluster-name>`. |
| 50 | + |
| 51 | +2. Create a `StatefulSet` for the counterapp. |
| 52 | + |
| 53 | +3. Create a `Service` for the `StatefulSet`. |
| 54 | + |
| 55 | +?> `StatefulSets` are a bit unique and require a `Headless Service` to function properly. This is because `StatefulSets` require stable network identities for their pods, and a `Headless Service` provides this by not load balancing traffic across pods, but instead routing traffic to specific pods based on their stable network identity. For more information: [https://kubernetes.io/docs/concepts/services-networking/service/#headless-services](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services) |
| 56 | + |
| 57 | +4. Apply both the `StatefulSet` and `Service` to the cluster. |
| 58 | + |
| 59 | +5. Port forward each pod, delete one of the pods and observe each instance of the counter app in your browser. |
| 60 | + |
| 61 | +?> Notice that deleting the pod may take a while to actually terminate. Take note on why you think this is the case. |
| 62 | + |
| 63 | +6. Clean up the cluster by deleting the `StatefulSet`, `Service`, and any dangling PV/PVCs. |
| 64 | + |
| 65 | +7. Create an analogous `Deployment` with 3 replicas and a dynamically provisioned `PersistentVolumeClaim`. |
| 66 | + |
| 67 | + a. Apply the `Deployment` and `PVC` to the cluster. |
| 68 | + |
| 69 | + b. Port forward to each pod and observe the counter app in your browser. What happens to the counter value across different pods? |
| 70 | + |
| 71 | + c. Delete one of the pods and observe: |
| 72 | + - How quickly does the pod terminate compared to the StatefulSet? |
| 73 | + - What is the new pod's name? |
| 74 | + - What happened to the counter value? |
| 75 | + |
| 76 | + d. Scale the Deployment to 5 replicas, then back down to 2. Which pods were removed? How does this compare to StatefulSet scaling behavior? |
| 77 | + |
| 78 | +8. Based on your observations, research how you might achieve per-replica persistent storage using only Deployments. What trade-offs or additional complexity would be required? |
| 79 | + |
| 80 | +?> Consider the differences in pod naming, storage behavior, scaling order, and data continuity. Why might these differences matter for stateful applications? |
| 81 | + |
| 82 | +## Deliverables |
| 83 | + |
| 84 | +- Look into other workload controllers (Deployments, ReplicaSets, DaemonSets, etc.), what are the differences between them? Why might you use one over the other? |
| 85 | +- What are some downsides to using `StatefulSets`? |
0 commit comments