Kubernetes StatefulSets — How to Troubleshoot and Best Practices

Are you planning to deploy a database in the Kubernetes cluster? If so, there is lot to consider and should have proper strategy, why so? As Database is very critical for any business. We aware Kubernetes is a container orchestration tool that uses many controllers to run applications as containers (Pods). In that, One of these controllers is called StatefulSet, which is used to run stateful applications. This is one we need to deploy our database on Kubernetes.

Deploying stateful applications in the Kubernetes cluster can be a complex task. This is because the stateful application expects primary-replica architecture and a fixed Pod name. How to do in Kubernetes? Well, The StatefulSets controller in Kubernetes addresses this problem while deploying the stateful application in the Kubernetes cluster.

In this article, you will learn more about what StatefulSets in the Kubernetes cluster are and when to use them, as well as how to deploy the stateful application using the StatefulSets controller in a step-by-step example.

What Are Stateful Applications?

Stateful applications are applications that store data and keep tracking it. All databases, such as MySQL, Oracle, and PostgreSQL, are examples of stateful applications. Stateless applications, on the other hand, do not keep the data ex: Nginx. For each request, the stateless application will receive new data and process it.

In a modern web application, the stateless application connects with stateful applications to serve the user’s request. A Node.js application is a stateless application that receives new data on each request from the user. This application is then connected with a stateful application, such as a any database(Ex: MySQL, PostgeSQL, etc), to process the data. Database stores data and keeps updating the data based on the user’s request.

Lets see in details with some example about statefulsets in the Kubernetes cluster — How to create, How to troubleshoot and best practices.

What is Kubernetes Statefulsets

A StatefulSet is a set of pods with a unique, persistent hostname and ID. StatefulSets are designed to run stateful applications in Kubernetes with dedicated persistent storage. When pods run as part of a StatefulSet, Kubernetes keeps state data in the persistent storage volumes of the StatefulSet, even if the pods shut down.

StatefulSets are commonly used to run replicated databases with a unique persistent ID for each pod. Even if the pod is rescheduled to another machine, or moved to an entirely different data center, its identity is preserved. Persistent IDs allow you to associate specific storage volumes with pods throughout their lifecycle.

A new feature in Kubernetes 1.14 that is beneficial to StatefulSets is local persistent volumes. A local persistent volume is a local disk attached directly to a single Kubernetes node, which acts as a persistent storage resource for Kubernetes nodes. This means that you can attach and detach the same disk to multiple machines without needing remote services.

You can check our more articles on Kubernetes troubleshooting.

StatefulSet vs. DaemonSet vs. Deployment

StatefulSets, DaemonSets, and Deployments are different ways to deploy pods in Kubernetes. All three of these are defined via YAML configuration. When you apply this configuration in your cluster, an object is created, which is then managed by the relevant Kubernetes controller.

The key differences between these three objects can be described as follows:

• StatefulSets run one or more pods with a persistent ID and persistent volumes, which is suitable for running stateful applications.
• DaemonSets run one or more pods across the entire cluster or a certain set of nodes. This can be used to run administrative workloads such as logging and monitoring components.
• Deployments run one or more pods, allowing you to define how many replicas of the pods need to run, on which types of nodes, and which deployment strategy should be used (for example, a Rolling deployment which replaces pods with a new version one by one, to prevent downtime).

When to Use StatefulSets

There are several reasons to consider using StatefulSets. Here are two examples:

1. Assume you deployed a MySQL database in the Kubernetes cluster and scaled this to three replicas, and a frontend application wants to access the MySQL cluster to read and write data. The read request will be forwarded to three Pods. However, the write request will only be forwarded to the first (primary) Pod, and the data will be synced with the other Pods. You can achieve this by using StatefulSets.
2. Deleting or scaling down a StatefulSet will not delete the volumes associated with the stateful application. This gives you your data safety. If you delete the MySQL Pod or if the MySQL Pod restarts, you can have access to the data in the same volume.
3. A Redis pod that has access to a volume, but you want it to maintain access to the same volume even if it is redeployed or restarted.
4. A Cassandra cluster and have each node maintain access to its data.
5. A webapp that needs to communicate with its replicas using known predefined network identifiers.

Creating StatefulSets

Let’s create a statefulset file and deploy it using kubectl apply. After you create a StatefulSet, it continuously monitors the cluster and makes sure that the specified number of pods are running and available.

When a StatefulSet detects a pod that failed or was evicted from its node, it automatically deploys a new node with the same unique ID, connected to the same persistent storage, and with the same configuration as the original pod (for example, resource requests and limits). This ensures that clients who were previously served by the failed pod can resume their transactions.

Continue reading it on https://foxutech.com/kubernetes-statefulsets-how-to-troubleshoot-and-best-practices/