RabbitMQ 4.1：新的 Kubernetes 对等发现机制
RabbitMQ 4.1 包含一个为 Kubernetes 完全重新设计的对等发现插件。升级到 4.1 时不需要进行任何配置更改，因此，如果您愿意，可以就此停止阅读。如果您对细节感兴趣，请继续阅读。这篇博文将解释对等发现子系统的一般概念以及 rabbitmq_peer_discovery_k8s 的具体更改。
什么是对等发现？
假设您想建立一个 3 节点 RabbitMQ 集群——您启动 3 个 RabbitMQ 实例，然后呢？您可以使用 rabbitmqctl join_cluster 命令手动让其中两个加入第三个，这样，您就拥有了一个 3 节点集群。
然而，大多数用户更希望这个过程自动化。这就是对等发现的用武之地。RabbitMQ 提供了几种适用于不同情况的对等发现插件。其中最简单的一种叫做 经典对等发现，它允许您只需在配置文件中放入节点的名称，这样 RabbitMQ 在启动时就会自动与它们形成集群。
人们普遍误以为对等发现是在节点每次启动时执行的。事实并非如此，它只在节点首次启动时（当其数据文件夹为空时）执行。
但是，根据您部署 RabbitMQ 的方式，节点名称可能无法预先知道。即使知道了，您也需要为每个集群使用不同的配置文件，这在您想要快速启动新集群用于测试环境等场景时可能会很不方便。
在这种情况下，您可以使用其他对等发现插件，这些插件允许节点向某些外部系统（如 Consul 或 etcd）注册，并查询这些系统以获取已注册节点的列表。这样您就不需要预先知道节点名称——节点会互相自动发现。
RabbitMQ 4.1 之前的 Kubernetes 对等发现
在 RabbitMQ 4.1 之前，rabbitmq_peer_discovery_k8s 通过查询 Kubernetes API 服务器来获取服务后面的端点列表（Kubernetes 会自动将给定 StatefulSet 的 Pod 注册为端点）来执行对等发现。然而，这种方法存在一些问题：
- 有些用户报告说，集群形成偶尔会失败，并且 Pod 会形成多个独立的集群；我们从未收到足够的数据来诊断这个问题，并且它从未在我们自己的测试中发生（我们尝试了数千次……）
- 它需要查询 Kubernetes API 的权限；这不算什么大问题，但它是多余的，而且一些注重安全的用***询问我们为什么需要它
- 这是一个迂回地询问我们已经知道答案的问题……
RabbitMQ 4.1 中的 Kubernetes 对等发现
在 Kubernetes 中部署 RabbitMQ 时，您应该始终使用 StatefulSet。属于 StatefulSet 的所有 Pod 都具有一致的命名方式：StatefulSet 的名称，后跟一个连字符和一个 序数索引。序数索引的起始值是可配置的，但几乎总是 0，所以我们就假设它是 0。有鉴于此，在 Kubernetes 中部署的 3 节点集群将始终拥有后缀为 -0、-1 和 -2 的节点。无需查询 Kubernetes API 来了解这一点！
新的插件不执行任何 Kubernetes API 查询。它只是假设存在一个后缀为 -0 的 Pod，并将其视为“种子”节点。所有其他节点将通过加入 -0 节点来加入集群。如果 -0 节点未启动，其他节点将永远等待它启动（没有 -0 节点，它们将永远无法形成集群）。请记住，对等发现仅在节点首次启动时发生，因此“永远等待节点 -0”仅适用于您首次部署给定集群时。
高级配置
对于绝大多数用户来说，这次升级应该是完全透明的。首先，由于对等发现仅在节点首次启动时执行，因此如果您升级现有集群，对等发现的更改将不会影响您。
其次，新插件接受但忽略旧插件的所有配置选项。您将在日志中看到一些关于使用已弃用选项的警告，但您可以安全地忽略它们。
如果默认配置不适用于您，可以使用以下两个设置：
-
如果您使用的序数起始值不是
0（说真的，为什么要这样做？！），您应该通过设置cluster_formation.k8s.ordinal_start = N来配置插件，其中N是序数起始值。设置后，所有节点将尝试加入-N节点，而不是-0节点。 -
此外，您可以设置
cluster_formation.k8s.seed_node = rabbit@seed-node-hostname来指定种子节点。我们预计这个设置永远不会被需要，但如果您真的需要它，它就在那里。
如果我正在使用 Cluster Operator？
Cluster Operator 是部署 RabbitMQ 到 Kubernetes 的推荐方式，所以如果您正在使用它——太棒了。您应该能够继续使用它而无需任何更改。您将在日志中看到上述警告，因为 Cluster Operator 允许部署不同版本的 RabbitMQ，而不仅仅是 4.1。因此，目前，它将继续在配置文件中设置旧版本的 rabbitmq_peer_discovery_k8s 所需的值。这种配置适用于 4.1 和旧版本。在未来的某个时候，Cluster Operator 将停止支持早于 4.1 的 RabbitMQ 版本，我们将从 Cluster Operator 声明的 ConfigMap 中删除这些设置。