I oftentimes hear folks stating that Kubernetes is great for stateless applications but when it comes to stateful applications, questions like: 'Can it be done?' or even 'Should it be done?' come up frequently. In this post, I'd like to offer a slightly more differentiated point of view and provide you with some resources that might help you dealing with stateful applications.

When you see or hear the term 'stateful application' you might be thinking: right, I know, a database! Before we get to this, allow me to step back a bit and introduce two orthogonal concepts:

  • State is a temporal property of a process. Stateless means that a process does not keep track of past interactions, essentially one can say it's a purely functional behavior. Stateful, on the other hand, means that the process has a record of previous interactions and can respond, based on it. Where the state is kept, that is, in main memory or persisted on disk, is a different question.
  • Storage, meaning a persistent way to keep data around, nowadays typically on a hard disk drive or an SSD. In case a process operates purely on data in main memory, there's no disk I/O. If disk I/O is carried out, it might be read-only or in a read-write manner.

Putting these two concepts together, we arrive at something like the following:

Now let's have a closer look at the examples in above figure:

  • Stateful applications with read-write disk access (quadrant A) such as a service carrying out a financial transaction backed by an RDBMS.
  • Stateless applications with read-write disk access (quadrant B), for example, an idempotent file upload service.
  • Stateless applications with read-only disk access such as a web server that (on start-up) reads the static content it serves from an external storage, for example from S3.
  • Stateless applications without disk access (quadrant C), such as a converter services for geo coordinates.
  • Stateful applications without disk access (quadrant D), like a shopping basket service in an eCommerce site.

One has a certain degree of freedom where to place an app, for example, in the case of the shopping basket the requirements could be such that you need to make sure the items in the basket are available across sessions and a pure in-memory solution is hence not allowed.

Another aspect to consider when designing stateful applications revolves around the primary location of the data. For example, if the initial state is kept external, as was the case with the web server, a volume backed by the filesystem of a node is sufficient. If, however, the app itself is the authoritative data source, for example, a Wordpress blog using MySQL, you might want to make sure that the data survives node failures and hence prefer a persistent volume backed by NFS or EBS.

Last but not least, since Kubernetes 1.5, you have a dedicated controller for stateful applications at your disposal: StatefulSet. Strictly speaking, this feature was already around longer but up to 1.4 this Kubernetes object was called PetSet.

A StatefulSet, as the name suggests, exists to help you setting up and operating stateful applications and distributed systems such as distributed filesystems or datastores. They work in conjunction with persistent volumes and provide for stable and unique network identifiers (FQDNs) as well as ordered deployments, scaling and deletion of the pods they're supervising.

Should you wish to learn more about StatefulSets, persistent data and stateful applications I'd encourage you to check out the following resources:

With that, I hope this post served you as a motivation for and introduction into the topic of state and storage with Kubernetes, and you can now appreciate a little bit better if and how Kubernetes can be used for stateful applications.

Categories

OpenShift Container Platform, How-tos, Products, OpenShift Dedicated, OpenShift Online

< Back to the blog