Is it a good idea to run a cluster of message queues inside Kubernetes?

11/24/2019

I don't believe that it is a good idea to host a cluster of message queues that persist messages inside Kubernetes. I don't think hosting any cluster inside kubernetes nor any stateful system inside Kubernetes is a good idea. Kubernetes is designed for stateless restful services, to scale in and out, etc. First of all, am I right? If I am right, then I just need some good valid points to convince some of my colleagues. Thanks

-- user3754482
kubernetes

1 Answer

11/25/2019

Kubernetes was primarily designed for stateless applications, and managing state in Kubernetes introduces additional complexities that you have to manage (persistence, backups, recovery, replication, high availability, etc.).

Let's cite some sources (emphases added):

While it’s perfectly possible to run stateful workloads like databases in Kubernetes with enterprise-grade reliability, it requires a large investment of time and engineering that it may not make sense for your company to make [...] It’s usually more cost-effective to use managed services instead.

Cloud Native DevOps with Kubernetes, p. 13, O'Reilly, 2019.

The decision to use Statefulsets should be taken judiciously because usually stateful applications require much deeper management that the orchestrator cannot really manage well yet.

Kubernetes Best Practices, Chapter 16, O'Reilly, 2019.

But...

Support for running stateful applications in Kubernetes is steadily increasing, the main tools being StatefulSets and Operators:

Stateful applications require much more due diligence, but the reality of running them in clusters has been accelerated by the introduction of StatefulSets and Operators.

Kubernetes Best Practices, Chapter 16, O'Reilly, 2019.

Managing stateful applications such as database systems in Kubernetes is still a complex distributed system and needs to be carefully orchestrated using the native Kubernetes primitives of pods, ReplicaSets, Deployments, and StatefulSets, but using Operators that have specific application knowledge built into them as Kubernetes-native APIs may help to elevate these systems into production-based clusters.

Kubernetes Best Practices, Chapter 16, O'Reilly, 2019.

Conclusion

As a best practice at the time of this writing, I would say:

  • Avoid managing state inside Kubernetes if you can. Use external services (e.g. cloud services, like DynamoDB or CloudAMQP) for managing state.
  • If you have to manage state inside the Kubernetes cluster, check if an Operator exists exists for the type of application that you want to run, and if yes, use it.
-- weibeld
Source: StackOverflow