在 Kubernetes 上部署 RabbitMQ（DIY）

概述

本指南提供了在不使用 Operator 或任何流行的 Helm chart 的情况下，在 Kubernetes 上部署 RabbitMQ 的指南。强烈不推荐这种“自己动手”的部署方式！

危险

您几乎肯定应该使用 Cluster Operator（强烈推荐）或其中一个流行的 Helm chart 来在 Kubernetes 上部署 RabbitMQ。如果您这样做，可以完全忽略本指南。

如果您确实不想使用 Cluster Operator 或 Helm chart，但仍强烈建议您在部署 RabbitMQ 时遵循它们所做的事情。您可以使用 Operator 部署一个集群，然后“四处查看”以了解部署的结构、StatefulSet 的配置方式、init 容器的作用等等。

此外，请记住 Cluster Operator 支持 StatefulSet 和 Service 的覆盖配置。因此，您可以在需要时以 Operator 为基础的部署方式进行自定义，而无需重新发明一切。

部署指南

使用 StatefulSet

RabbitMQ 是一个有状态应用程序，对主机名更改很敏感。因此，您必须使用 StatefulSet 来运行它。

此外，由于 RabbitMQ 节点 在启动时解析自身和同级节点的主机名，因此可能需要将 CoreDNS 的 缓存超时时间 从默认的 30 秒降低到 5-10 秒的范围。或者，init 容器应将启动延迟 30 秒。

重要

可能需要将 CoreDNS 的 缓存超时时间 从默认的 30 秒降低到 5-10 秒的范围

使用持久卷

由于 RabbitMQ 是一个有状态应用程序，因此应为其数据文件夹使用持久卷。唯一的例外是，如果您的部署确实是临时的，这在测试管道中很常见。如果您只需要在应用程序测试期间拥有一个临时的 RabbitMQ 实例，则可以不使用持久卷进行部署。这样做可能会轻松丢失数据（例如队列中的消息）！

使用并行 podManagementPolicy

对于 RabbitMQ 集群，推荐的选项是 podManagementPolicy: "Parallel"。

由于 节点如何重新加入集群，在某些 readiness probe 下，将 podManagementPolicy 设置为 OrderedReady 可能会导致部署死锁。

• Kubernetes 将期望第一个节点通过 readiness probe。
• readiness probe 可能需要一个完全启动的节点。
• 节点将在检测到其同级节点上线后完全启动。
• Kubernetes 在第一个节点启动之前不会启动任何其他 pod。
• 因此，部署处于死锁状态。

podManagementPolicy: "Parallel" 避免了这个问题，然后 Kubernetes 同级发现插件会处理 并行集群形成过程中存在的自然竞争条件。

ReadinessProbe

在 5672 端口（AMQP）或 5671 端口（AMQP + TLS）上进行 TCP 检查是大多数情况下的良好 readinessProbe。AMQP 监听器是节点启动过程的最后几个步骤之一，始终启用。如果端口可用，则 RabbitMQ 基本上已经完成了启动过程，可以接受连接。

TCP 检查与 podManagementPolicy: "Parallel" 结合使用效果很好。如果您想使用 OrderedReady，您应该使用一个不需要节点完全启动的 readinessProbe（这违背了 readinessProbe 的初衷）。一个不期望节点完全启动并同步了 schema 表的健康检查是

readinessProbe:
  exec:
    # This is NOT the recommended readinessProbe!
    command: ["rabbitmq-diagnostics", "ping"]

这个基本检查将允许部署继续进行，节点最终能够重新加入彼此，假设它们 兼容。建议使用 Parallel 启动策略结合基于 TCP 的 readinessProbe。

配置

要使用 Kubernetes 进行同级发现，请将 cluster_formation.peer_discovery_backend 设置为 k8s 或 kubernetes 或其模块名 rabbit_peer_discovery_k8s（注意：模块名与插件名略有不同）。

cluster_formation.peer_discovery_backend = k8s

# the backend can also be specified using its module name
# cluster_formation.peer_discovery_backend = rabbit_peer_discovery_k8s

同级发现插件的默认设置在绝大多数情况下都可以正常工作，但如果默认设置不适合您，也有一些 可用设置。

确保 /etc/rabbitmq 被挂载为可写

RabbitMQ 节点可能需要更新 /etc/rabbitmq 下的文件，这是 Linux 上的默认 配置文件位置。这可能包括镜像使用的配置文件生成、已启用插件文件 的更新等。

因此，强烈建议将 /etc/rabbitmq 挂载为可写，并由 RabbitMQ 的有效用户（通常是 rabbitmq）拥有。或者，您可以在 init 容器中将 ConfigMap 卷复制到 /etc。