随着时间的推移，我们看到在我们社区的 邮件列表 和 Slack 频道上关于 Kubernetes 的查询数量飙升。
到 2024 年，大多数 Kubernetes 相关问题的答案是：使用 RabbitMQ 核心团队构建的 Kubernetes Operator。它包含了所有最佳实践，是强烈推荐的选项。
本文档介绍了在 Kubernetes 上自行部署 RabbitMQ 的基础知识：需要哪些 Kubernetes 资源，如何确保 RabbitMQ 节点使用持久化存储，如何处理敏感值的配置等等。
所以今天我想谈谈 RabbitMQ 性能的某些方面。有大量的变量影响您可以从 RabbitMQ 服务器获得的整体性能水平，今天我们将尝试调整其中的一些变量，看看会发生什么。
我们在 RabbitMQ 总部面临的一个问题是，虽然我们对消息代理的工作原理了如指掌，但我们并没有太多关于设计使用 RabbitMQ 并需要长期可靠、无人值守运行的应用程序的经验。我们花了很多时间在邮件列表中回答问题，也会在这里那里做一些咨询工作，但在某些情况下，是用户构建的应用程序促使我们真正思考 RabbitMQ 的长期行为。最近，我们被要求深入思考队列的基本性能，这让我们对 Rabbit 的配置有了新的认识。
不时地，在我们的 邮件列表 和其他地方，都会有人提出在 RabbitMQ 中使用不同的后备存储的想法。后备存储负责将消息写入磁盘（消息可能因为多种原因被写入磁盘），并且经常有人建议看看如果 RabbitMQ 的后备存储被替换为其他存储系统会是什么样子。
这样的改变将允许实现目前不可能的功能，例如带外队列浏览或分布式存储，但消息队列（如 RabbitMQ）的数据存储和访问模式与通用数据库之间存在根本性的差异。事实上，RabbitMQ 故意不将消息存储在这样的数据库中。
在过去一年里，AMQP gem 的开发几乎停滞不前，因为它的最初作者 Aman Gupta（@tmm1）非常忙碌。许多 bug 未得到解决，代码变得陈旧过时，也没有添加新功能或文档。
这时，我开始与 RabbitMQ 的人讨论合作的可能性。事实上，最初我联系 VMware 是因为看到 Ezra Zygmuntowicz 在为他的云团队招人，但当我发现 VMware 最近收购了伦敦的 RabbitMQ 项目时，我产生了兴趣。我签署了合同，从 script/console 切换到 Wireshark 和 RabbitMQ Tracer，从 11 月份开始，我一直在愉快地开发 AMQP 和 AMQ-Protocol gems。
RabbitMQ 需要更多、更好的文档。（谁不需要呢？）特别是，我们需要更多、更好的入门材料，向读者介绍各种基本概念，解释它们为什么重要，并激励他们继续阅读并了解更多关于 RabbitMQ 的信息。这是那篇介绍的第一章。欢迎您提出意见，第二章和第三章将很快跟进。（您可能已经知道所有这些了，但令人惊讶的是，很多人并不知道。本介绍是为他们准备的。）