<p>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</p>

user3754482
<p>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.).</p>

<p>Let's cite some sources (emphases added):</p>

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

<p><em>Cloud Native DevOps with Kubernetes, p. 13, O'Reilly, 2019.</em></p>

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

<p><em>Kubernetes Best Practices, Chapter 16, O'Reilly, 2019.</em></p>

<p><strong>But...</strong></p>

<p>Support for running stateful applications in Kubernetes is steadily increasing, the main tools being <strong><a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" rel="nofollow noreferrer">StatefulSets</a></strong> and <strong><a href="https://kubernetes.io/docs/concepts/extend-kubernetes/operator/" rel="nofollow noreferrer">Operators</a></strong>:</p>

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

<p><em>Kubernetes Best Practices, Chapter 16, O'Reilly, 2019.</em></p>

<blockquote>
  <p>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 <strong>using Operators that have specific application knowledge built into them as Kubernetes-native APIs may help to elevate these systems into production-based clusters</strong>.</p>
</blockquote>

<p><em>Kubernetes Best Practices, Chapter 16, O'Reilly, 2019.</em></p>

<h2>Conclusion</h2>

<p>As a best practice at the time of this writing, I would say:</p>

<ul>
<li>Avoid managing state inside Kubernetes if you can. Use external services (e.g. cloud services, like <a href="https://aws.amazon.com/dynamodb/" rel="nofollow noreferrer">DynamoDB</a> or <a href="https://www.cloudamqp.com/" rel="nofollow noreferrer">CloudAMQP</a>) for managing state.</li>
<li>If you have to manage state inside the Kubernetes cluster, <a href="https://operatorhub.io/" rel="nofollow noreferrer">check if an Operator exists</a> exists for the type of application that you want to run, and if yes, use it.</li>
</ul>
