StatefulSets
1. StatefulSets
Although PersistentVolumes provide durable storage for a Pod, they can also be used for other controllers like Deployments and StatefulSets. A Deployment is a Pod template, typically used for stateless applications, that runs and maintains a set of identical Pods, commonly known as replicas. These replicas need to attach and reattach to PersistentVolumes dynamically, which might cause a deadlock. StatefulSets help resolve this problem. This means that whenever an application needs to maintain state in PersistentVolumes, it should be managed with a StatefulSet. Useful for stateful applications, StatefulSets run and maintain a set of Pods. A StatefulSet object defines a desired state, and its controller achieves it. This allows StatefulSets to maintain a persistent identity for each Pod. Each Pod in a StatefulSet has an ordinal index with a relevant Pod name, a stable hostname, and stably identified persistent storage that is linked to the ordinal index. An ordinal index is a unique sequential number that is assigned to each Pod in the StatefulSet. This number defines the Pod’s position in the set’s sequence of Pods. Deployment, scaling, and updates are ordered by using the ordinal index of the Pods within a StatefulSet. For example, if a StatefulSet named ‘demo’ launches 3 replicas, it will launch Pods named demo-0, demo-1, and demo-2 sequentially. This means that all of its predecessors must be running and ready before an action is taken on a newer Pod. For example, if demo-0 is not running and ready, demo-1 will not be launched. If demo-0 fails after demo-1 is Running and Ready, but before the creation of demo-2, demo-2 will not be launched until demo-0 is relaunched and becomes Running and Ready. Scaling and rolling updates happen in reverse order, which means demo-2 would be changed before demo-1. To launch Pods in parallel without waiting for the Pods to maintain Running and Ready state, ensure that the PodManagementPolicy is Parallel. As mentioned, StatefulSets are useful for stateful applications. With stable storage, StatefulSets use a unique PersistentVolumeClaim for each Pod. In order for each Pod to maintain its own individual state, it must have reliable long-term storage to which no other Pod writes. These PersistentVolumeClaims use ReadWriteOnce access mode for applications. When it comes to controlling networking, StatefulSets require a service. For example, if load-balancing and a single service IP are not needed, a headless service can be created by specifying “None” for the cluster IP in the Service definition. To ensure a specific service gets used for a StatefulSet, add that service to the serviceName field. A label selector is required for the Service, and this must match the template’s labels defined in the template section of the StatefulSet definition. The container details must also be defined, including the image, containerPort for the Service, and Volume mounts. And most importantly, VolumeClaimTemplates must be specified under the template section. The VolumeClaimTemplate must be named, and the spec needs to be the same as the PersistentVolumeClaim that is required by the Pods in this StatefulSet.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.