Kubernetes has a huge amount of capabilities and deployment choices for operating containers. In this blog post, we’ll discuss what a StatefulSet is, what it can be used for, and how to update them. In another blog post from the Lab series, we will go over how to create a StatefulSet.
What is a StatefulSet in Kubernetes?
Scaling in Kubernetes is accomplished by controlling a group of Pods. An additional resource is required at the workload level in order for this to occur consistently. One common workload resource is a Deployment that will handle ReplicaSets. Although this is effective for stateless apps, it is ineffective for scenarios where data must remain persistent during any application scaling.
StatefulSets is for use with stateful applications in a Kubernetes cluster. It manages the deployment and scaling of a set of Pods, and provides guarantees about the ordering and uniqueness of these Pods.
Like Deployment, a StatefulSet maintains Pods that are based on the identical container specification. A StatefulSet keeps a sticky identity for each of its Pods, unlike a Deployment. Despite being made from the identical specifications, these pods are not interchangeable since they each have a persistent identifier that they keep up through any schedule changes.
When to use StatefulSet?
The majority of the time when using Kubernetes, you don't care how your pods are scheduled, but occasionally, you do care that they are deployed in the correct sequence, have a persistent storage volume, or have a distinct, stable network identifier across restarts and reschedules. StatefulSets can assist you in achieving your goal in these circumstances.
You can utilize a StatefulSet as part of the solution if you want to leverage storage volumes to provide persistence for your workload. Despite the fact that individual Pods in a StatefulSet are prone to failure, the persistent Pod identifiers make it simpler to match existing volumes to the new Pods that replace any that have failed.
Pod Identity
StatefulSet Pods have a unique identity that is comprised of an ordinal, a stable network identity, and stable storage. No matter which node it is (re)scheduled on, the identity remains attached to the Pod.
1. Ordinal Index
For a StatefulSet with N replicas, when Pods are being deployed, it will be given an integer ordinal, ranging from 0 up to N-1, that is unique across the Set. When Pods are being deleted, they are terminated in reverse order, from {N-1..0}. Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready. Before a Pod is terminated, all of its successors must be completely shutdown.
2. Stable Network ID
Each Pod in a StatefulSet derives its hostname from the name of the StatefulSet and the ordinal of the Pod. The pattern for the constructed hostname is $(StatefulSet name)-$(ordinal).
3. Stable Storage
Each Pod receives one PersistentVolumeClaim for each VolumeClaimTemplate entry defined in a StatefulSet. The default StorageClass will be used if no StorageClass is specified. When a Pod is (re)scheduled onto a node, the PersistentVolumes associated with its PersistentVolume Claims are mounted by volumeMounts. It is important to note that when the Pods or StatefulSet are deleted, the PersistentVolumes associated with the Pods' PersistentVolume Claims are not deleted. This must be done manually.
4. Pod Name Label
When the StatefulSet Controller creates a Pod, it adds a label with the name of the Pod, statefulset.kubernetes.io/pod-name. This label lets you associate a Service with a specific Pod in the StatefulSet.
How to update a Kubernetes StatefulSet?
A StatefulSet's .spec.updateStrategy field allows you to configure and disable automated rolling updates for containers, labels, resource request/limits, and annotations for the Pods in a StatefulSet. There are two update strategies:
1. OnDelete
When a StatefulSet's .spec.updateStrategy.type is set to OnDelete, the StatefulSet controller will not automatically update the Pods in a StatefulSet. Users must manually delete Pods to cause the controller to create new Pods that reflect modifications made to a StatefulSet's .spec.template.
2. RollingUpdate
The RollingUpdate update strategy implements automated, rolling update for the Pods in a StatefulSet. This is the default update strategy.
If you need a persistent volume or network ID for a pod, StatefulSets are extremely useful. They are simple to create and maintain, and they are an excellent feature of Kubernetes.
That concludes this post.
Thank you for reading!
*** Explore | Share | Grow ***
Comments