Creating a clustered environment of any kind involves a lot of work to allow consistent deployment and scaling.
The good news is that you can manage containers at scale using StatefulSets in Kubernetes.
StatefulSets are intended for running stateful applications within Kubernetes with dedicated, persistent storage.
In this guide, we’ll cover three best practices to learn from when using Kubernetes StatefulSets.
But first…
What is Kubernetes StatefulSet?
Kubernetes StatefulSet is the workload Application Programming Interface (API) object used for managing stateful applications.
You can use StatefulSets to deploy and scale a set of Pods, which provides guarantees for the Pod’s order and uniqueness.
Similar to a Deployment, a Kubernetes StatefulSet can manage Pods based on an identical container specification.
However, unlike a Deployment, a StatefulSet can maintain sticky identities for each Pod. While the pods are created from the same spec, they’re not interchangeable, which means each Pod has a persistent identifier that it maintains throughout any rescheduling.
If you want to provide persistence for a workload using storage volumes, leverage a StatefulSet as part of the solution.
While individual Pods within a StatefulSet can be prone to errors, the persistent Pod identifier can make it easier to match the existing volumes to the new Pods that replace those that failed.
A typical use case of StatefulSet is when you need to deploy primary or secondary servers, such as a database cluster, where you have to know each server’s hostname to start the cluster.
Another common use case of StatefulSet is when you scale up and down in a specific order, such as when you want to begin with the primary node followed by the secondary node.
It’s best to use StatefulSet when you need:
- Stable and distinct network identities
- Ordered and unique deployment and scaling
- Persistent and steady storage across all your application scheduling and rescheduling
Tried and tested tips when using StatefulSet
Below are a few best practices for using Kubernetes StatefulSet.
1. Use the kubectl apply a command to create a StatefulSet resource
The command utilizes manifest files to create, update, and remove resources within your clusters. It’s a declarative method of object configuration that retains writes that were made to live objects without merging changes back into the object configuration files.
Remember to create a StorageClass when using clusters with Windows Server node pools since the default StorageClass utilizes ext4 as the file system type (which only works for Linux containers).
Also, use NTFS as the file storage type if you use a Compute Engine persistent disk.
Create a StatefulSet manifest using the StorageClass you defined.
For instance, your manifest can create four PersistentVolumeClaim and PersistentVolume pairs representing four Computer Engine persistent disks. Each Pod within the StatefulSet consumes a single persistent disk.
Additionally, include a node selector to your Pod specification to make sure your Pods are scheduled correctly on Windows Server nodes.
Finally, create a StatefulSet resource by running this command:
kubectl apply -f STATEFULSET_FILE
Remember to replace STATEFULSET_FILE with the manifest file name.
2. Know the various methods for updating a StatefulSet
You can update StatefulSets in various ways, with the declarative method kubectl apply to be the most common.
For instance, if you use the Google Kubernetes Engine and want to update the StatefulSet in your preferred editor or directly from your shell, use kubectl edit. You can also opt for the YAML editor on the GKW Workloads menu within the Cloud console.
Also, you can roll out updates to the Pods specification (for a StatefulSet resource), such as its configuration, image, or resource requests and usage.
Apply an updated or new manifest file when updating the StatefulSet using kubectl apply. It’s helpful when making various changes to StatefulSet, such as when you scale or specify new application versions.
Note: Using kubectl apply to update a resource only works when the resource was created using kubectl create – -save-config or kubectl apply.
You can also use StatefulSet’s updateStrategy field, which lets you set up and disable automated rolling updates for resource requests, labels, limits, containers, and annotations for the Pods within a StatefulSet.
Know the various methods for updating your StatefulSet and determine which works best for you.
3. Determine when to use StatefulSets
There are instances when you’re better off using Kubernetes StatefulSets than Deployments.
Some of these situations can include the following.
- Scaling down or deleting a StatefulSet. Your data can remain safe when scaling down or deleting a StatefulSet since doing so won’t delete the volumes associated with the Stateful app.
It’s usually more valuable than automatically purging all related StatefulSet resources.
For example, if the MySQL Pod restarts or gets deleted, you can access the data in the same volume.
- Deploying and scaling a MySQL database. Let’s say you deployed a MySQL database within the K8s cluster and scaled it to three replicas. A frontend app also wants to access your deployed MySQL cluster to read and write data.
The read request is forwarded to three Pods, but the write request only gets forwarded to the primary or first Pod. Then, the data gets synced with the other Pods.
All this is possible when you use StatefulSets.
Kubernetes StatefulSet limitations
While it’s crucial to know the best practices in using a Kubernetes StatefulSet, it’s just as important to understand its limitations, which include the following.
- A given Pod’s storage must be pre-provisioned by an admin or provisioned by PersistentVolume Provisioner (based on the requested storage class).
- StatefulSets don’t offer guarantees for pod termination when StatefulSets are deleted. To achieve gracefully and ordered pods termination when deleting a StatefulSet, you can scale the StatefulSet down to zero before deleting.
- StatefulSets require a Headless Service responsible for the Pods’ network identity. You’ll need to create this service.
- You can get into a broken state that needs manual intervention to fix when you use Rolling Updates via the default Pod Management Policy (OrderedReady).
Leverage Kubernetes StatefulSet the right way
Administrating distributed systems and stateful applications on Kubernetes can be a broad and complex undertaking, but it’s not rocket science.
Start with the basics and follow best practices when using StatefulSets to make managing and running stateful applications in Kubernetes more effective and efficient.
