Lab12 - StatefulSet Application
Lab12 - StatefulSet Application
Lab12 - StatefulSet Application
Introduction
StatefulSet is the workload API object used to manage stateful applications.
Manages the deployment and scaling of a set of Pods, and provides guarantees about the
ordering and uniqueness of these Pods.
Like a Deployment, a StatefulSet manages Pods that are based on an identical container spec.
Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods
are created from the same spec, but are not interchangeable: each has a persistent identifier
that it maintains across any rescheduling.
In this Lab, you will learn below items:
Objectives:
• Create a StatefulSet
• Manage a StatefulSet
• Delete pod in a StatefulSet
• Scale replicas in a StatefulSet
• Update StatefulSet
• Clean up
2. Let us clone the git repository which contains manifests required for this exercise, by
executing the below command.
Output:
# cat -n ~/k8s-statefulset/statefulset.yaml
Output:
6. Using nslookup on the Pods' hostnames, you can examine their in-cluster DNS addresses:
Output:
Notice that the web-1 Pod is not launched until the web-0 Pod is Running (see Pod Phase) and
Ready (see type in Pod Conditions).
Open duplicate terminal to watch
4.4 In one terminal, watch the StatefulSet's Pods:
3.2 Wait for the StatefulSet to restart them, and for both Pods to transition to Running and
Ready:
# kubectl get pod -w -l app=nginx
Output:
3.5 In that new shell, run: to notice a new pod ip has been assigned after deletetion and
recreation of statefulset.
# nslookup web-0.nginx
# nslookup web-1.nginx
Output:
The StatefulSet controller created two Persistent Volume Claims that are bound to two
Persistent Volumes.
As the cluster used in this lab is configured to dynamically provision Persistent Volumes, the
Persistent Volumes were created and bound automatically.
4.1 Write the Pods' hostnames to their index.html files and verify that the NGINX webservers
serve the hostnames:
# for i in 0 1; do kubectl exec "web-$i" -- sh -c 'echo
"$(hostname)" > /usr/share/nginx/html/index.html'; done
# for i in 0 1; do kubectl exec -i -t "web-$i" -- curl
http://localhost/; done
Output:
Note: If you instead see 403 Forbidden responses for the above curl command, you will need to
fix the permissions of the directory mounted by the volume Mounts (due to a bug when using
hostPath volumes), by running:
(for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done)
before retrying the curl command above.
Even though web-0 and web-1 were rescheduled, they continue to serve their hostnames
because the PersistentVolumes associated with their PersistentVolumeClaims are remounted to
their volume Mounts. No matter what node web-0 and web-1 is scheduled on, their
PersistentVolumes will be mounted to the appropriate mount points.
In another terminal window, use kubectl scale to scale the number of replicas to 5:
In another terminal, use kubectl patch to scale the StatefulSet back down to three replicas:
# kubectl patch sts web -p '{"spec":{"replicas":3}}'
Output: