RabbitMQ 4.1：新的 Kubernetes 对等发现机制
RabbitMQ 4.1 包含一个为 Kubernetes 完全重新设计的对等发现插件。升级到 4.1 时不需要进行任何配置更改，因此，如果您愿意，可以就此停止阅读。如果您对细节感兴趣，请继续阅读。这篇博文将解释对等发现子系统的一般概念以及 rabbitmq_peer_discovery_k8s 的具体更改。
什么是对等节点发现？
假设你想拥有一个 3 节点的 RabbitMQ 集群——你启动了 3 个 RabbitMQ 实例，然后呢？你可以手动使用 rabbitmqctl join_cluster 命令告诉其中两个实例加入第三个实例，瞧，你就得到了一个 3 节点集群。
然而，大多数用户更希望这个过程是自动化的。这就是对等节点发现（peer discovery）的作用。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 对等节点发现
在将 RabbitMQ 部署到 Kubernetes 时，你应该始终使用 StatefulSet。属于同一个 StatefulSet 的所有 Pod 都以 StatefulSet 的名称命名，后跟连字符和序数索引。序数索引的起始值是可配置的，但几乎总是 0，所以我们就假设它是 0。鉴于此，部署到 Kubernetes 的 3 节点集群其节点的后缀将始终为 -0、-1 和 -2。完全没必要为了知道这一点而去查询 Kubernetes API！
新的插件不会执行任何 Kubernetes API 查询。它只是预设后缀为 -0 的 Pod 会存在，并将其视为“种子（seed）”节点。所有其他节点将通过加入 -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）怎么办？
集群操作员是向 Kubernetes 部署 RabbitMQ 的推荐方式，所以如果你正在使用它——很好。你应该可以继续使用它而无需任何更改。你会在日志中看到前述的警告，因为集群操作员允许部署不同的 RabbitMQ 版本，而不仅仅是 4.1。因此，目前它将继续在配置文件中设置旧版 rabbitmq_peer_discovery_k8s 所需的值。这种配置对于 4.1 和旧版本都有效。在未来的某个时候，集群操作员将停止支持 4.1 之前的 RabbitMQ 版本，届时我们将从集群操作员声明的 ConfigMap 中移除这些设置。