Although Kubernetes is currently the most popular container orchestration platform for cloud-native applications, running stateful applications is not straightforward. There are significant challenges running stateful applications (such as database and storage systems) on Kubernetes clusters.

Note: One of the reasons why Kubernetes is so popular is its ability to handle (and scale) stateless applications.

But there is also a demand for orchestrating stateful applications on Kubernetes. Therefore, before discussing the challenges of (and solutions to) running stateful applications on Kubernetes, let’s consider the difference between stateful and stateless architectures.

Stateful vs. Stateless Architectures

In information technology, the word state refers to the condition of a system, component, or application at a specific point in time. The article titled Stateful vs Stateless Architectures – Explained for Beginners describes state as follows:

“State represents the data that is stored and used to keep track of the current state of an application.”

As you browse through the site’s pages, the items in your cart remain the same even though the web page’s details change. To the uninitiated, it looks as though the shopping cart details follow the user’s journey through the eCommerce site. Technically speaking, this eCommerce app is stateful because it “remembers” the items in the shopping cart until you either check out the cart and finalize the transaction or close the site.

On the other hand, a stateless application is one where any user data is not stored while the application is in use.

Let’s turn our eCommerce application on its head and assume that after selecting an item from a particular web page and adding it to your shopping cart, you must finalize the purchase before navigating to another web page; otherwise, the item will disappear from the shopping cart. Ergo, to buy ten items from the same eCommerce site, you must complete ten separate transactions to buy everything you intend to purchase.

Kubernetes, Stateful, and Stateless

Let’s now imagine we have two eCommerce applications, one stateless and the other stateful, and they are both containerized and orchestrated using Kubernetes.

Orchestrating a Stateless Application on Kubernetes

Because each web page is developed as a separate microservice packaged inside its own container, the stateless eCommerce app is easy to configure.

As a result, it does not matter how many users navigate to the same web page simultaneously; Kubernetes will scale the application up, increasing the number of containers to meet the demand without needing to transfer data between each microservice.

Orchestrating a Stateful Application on Kubernetes

However, juxtapositionally, the stateful eCommerce application mandates the transfer of data between each containerized microservice. As Ben Hirschberg notes:

 “Running stateful applications, such as databases and storage systems, on Kubernetes clusters is debatable.”
Why?

As described above, stateful applications need a different functionality when compared to stateless applications, creating complexities and their resultant challenges. Despite these complexities and challenges, stateful apps are increasingly being run on Kubernetes.

The Challenges of (& Solutions to) Running Stateful Applications on Kubernetes

In a survey of more than 500 executives and technology leaders conducted by quoted in the Data on Kubernetes 2022 Report, 90% believe Kubernetes is ready to handle stateful workloads.

Moreover, 70% of these respondents are already running stateful workloads in production. But it is not enough. Clearly, the challenges of running stateful applications must be solved.

Fortunately, Kubernetes is being used increasingly to run stateful applications, helping to solve these challenges. In addition, Kubernetes' high adoption rate is leading to the development of widely accepted best practice solutions.

However, these problems are still significant, as seen below:

1. Data Persistence

Stateful applications require persistent storage for data. Managing this storage, as well as capacity and access to this storage, is one of the biggest challenges. Kubernetes’ containers are typically ephemeral, making it difficult to ensure data persistence across container restarts or rescheduling.

The good news is that this challenge is resolved mainly by the Kubernetes Persistent Volume (PV) and Persistent Volume Claim (PVC) by enabling access to persistent storage. PVs are abstract storage resources, and PVCs are requests for storage by pods.

2. Network Identity and Service Discovery

Stateful applications often rely on stable (or static) network identities and service discovery mechanisms. These can be complex in Kubernetes because pods and services have dynamic IPs and host names.

Fortunately, this challenge is solved by implementing Kubernetes Headless Services and StatefulSets. Headless Services provide static DNS names for each pod, and StatefulSets ensures ordered and predictable pod names.

3. Ordered and Predictable Scaling

Under normal circumstances, scaling stateful applications is challenging as it requires maintaining the correct order and synchronization of instances for data consistency.

The solution to this challenge is to use StatefulSets to manage the stateful app’s deployment and scaling while maintaining a stable identity for each pod, ensuring pods are scaled in a predictable and ordered manner.

Passing Data Between Containerized Stateful Apps on Kubernetes

Note: While passing data between containers is also a challenge of running stateful applications on Kubernetes, it also warrants its own sub-discussion, providing additional clarity and ease of understanding.

As highlighted in the stateful eCommerce app use case described above, passing data between containerized stateful apps is both mandatory and complex. Not only is it vital to scale the requisite number of containers up and down in an ordered manner as user demands increases and decreases, but it is also equally important to pass the necessary data between these containers.

Fortunately, it is possible to pass data between containers within a Kubernetes cluster using different mechanisms and patterns. The choice of method depends on your specific use case and requirements, with the following being the most commonly used strategies:

Shared Volumes

Two mechanisms exist in this subcategory: EmptyDir or Persistent Volumes:

1. EmptyDir Volumes 

Using EmptyDir volumes is a good idea when passing data between containers within the same pod and doesn’t need data persistence beyond the pod’s lifecycle. 

2. Persistent Volumes

This method has been described above. Therefore, any additional commentary is out of the scope of this discussion. Suffice to say, for data sharing across pods or nodes, create a PVC that attaches to a specific PV, mount both containers on this PV, and the mounted containers can exchange data. 

Kubernetes Services

The following services are the most useful when passing data between containers:

1. Headless Services

When you need to share data between stateful application instances running in separate pods, you can use headless services. Each pod will have a stable DNS name, allowing pods to locate and communicate with each other.

2. ClusterIP Services

You can configure ClusterIP services, providing a stable internal IP address that pods can use to communicate with each other. However, this method is mainly used when services communicate with each other rather than passing data directly between containers.

Sidecar Containers

Deploy a sidecar container within the same pod as your primary container. The sidecar is responsible for data transformation or synchronization, passing data between the sidecar and primary container using shared volumes or local network communication.

API or Message Broker

Implement an API or message broker like Kafka or RabbitMQ to allow containers to communicate asynchronously. One data can send data to the message broker, which the other container can consume when needed.

Final Thoughts

Orchestrating containerized stateful applications on Kubernetes is possible with careful planning, using Kubernetes resources like persistent volumes, StatefulSets, sidecar containers, and headless services to pass data between containers.

Finally, by leveraging these solutions and best practices, organizations can effectively run stateful applications on Kubernetes while addressing the challenges associated with data persistence, networking, scaling, and data management. All it takes is careful planning to design your Kubernetes deployment to meet the requirements of your stateful application workloads.