Guest: Andrew McKinney (LinkedIn)
Company: Qarik Group (Twitter)
Show: TFiR: T3M

Qarik helps companies modernize and move towards a more cloud-native future. In this episode of TFiR: T3M, Swapnil Bhartiya sits down with Andrew McKinney, Principal Engineer at Qarik, to discuss the stateful workloads on Kubernetes

How to define a stateful workload:

  • Any workload that can be shutdown, with the context and history stored to a disk and brought back whenever you need.  A majority of modern applications are stateful.

Emergence of stateful workloads into Kubernetes:

  • Originally Kubernetes developers thought that PetSets was a resource well-suited to workloads but this has now evolved into StatefulSets, which are mature. McKinney goes through the difference between a StatefulSet and a deployment on Kubernetes. 

Should we run stateful workloads on Kubernetes?

  • If there is a managed service available for the workload like an SQL database, Qarik typically recommends leveraging that since companies like GCP and AWS have thousands of engineers making it more available and performant. However, there’s not always a managed service for the use case. 
  • Databases that have not performed well have been a longstanding challenge, something which is carried over when putting it in Kubernetes and is not something that is recommended

Instances where we should not be running stateful workloads

  • With anything that is mission-critical, you should be looking at SQL and a managed service. However, this gets complicated whenever you are running Kubernetes on premise. McKinney talks about what they would recommend to enterprises in these instances. 

Key trends in stateful workloads and databases in the Kubernetes space

  • There are many enterprises built on running cloud-native on Kubernetes. For example, Kafka’s enterprise suite has a Kubernetes operator which handles all the log rotation and scaling, which a Kubernetes API will not do for you. 
  • The operator framework is much more mature so that you can confidently run databases inside a Kubernetes cluster. 

What is the right approach for running stateful workloads in Kubernetes?

  • Running stateful workloads inside of Kubernetes is not fundamentally wrong but you may need to put extra guardrails or additional YAMLs on these workloads. 

How is Qarik helping customers manage stateful workloads?

  • We should not be afraid of running databases in Kubernetes. By not having a stateful workload on Kubernetes, you are mandating that an operator who is already under pressure needs to go and look it up. You may need to look at a separate piece of glass to look at that database or have them on a separate stack.  

This summary was written by Emily Nicholls.

You may also like