跳至主要内容

在 Kubernetes 上部署 RabbitMQ：涉及哪些内容？

·阅读时间：22分钟
Michael Klishin
Michael Klishin

随着时间的推移，我们发现社区中与 Kubernetes 相关的查询数量在我们的邮件列表邮件列表和Slack频道中激增。

在2024年，大多数与 Kubernetes 相关的问题的答案是：使用由 RabbitMQ 核心团队构建的Kubernetes 运算符。它集成了所有最佳实践，并且是强烈推荐的选择。

本文介绍了在 Kubernetes 上自行部署 RabbitMQ 的基础知识：需要哪些 Kubernetes 资源，如何确保 RabbitMQ 节点使用持久性存储，如何处理敏感值的配置等等。

2024 年更新​

提示

与其自行将 RabbitMQ 部署到 Kubernetes，不如考虑使用由 RabbitMQ 核心团队构建的 Kubernetes 运算符。它集成了所有最佳实践，并且是强烈推荐的选择。

简介​

将 RabbitMQ 等有状态数据服务部署到 Kubernetes 而不使用 Kubernetes 运算符，就像拼拼图一样。

涉及多个部分

在这篇文章中，我们将尝试涵盖关键部分，并提及一些在技术上不需要在 Kubernetes 上运行 RabbitMQ 的步骤，但每个生产系统操作员迟早都会担心这些步骤。

  • 如何使用 Prometheus 和 Grafana 设置集群监控
  • 如何部署 PerfTest 实例来对集群进行基本的函数和负载测试

本文绝不涵盖在将 RabbitMQ 部署到 Kubernetes 时可能相关的每个方面；我们的目标是突出最重要的部分。部署和工作负载特定的决策，例如将哪些资源限制应用于 RabbitMQ 节点 Pod（容器），使用哪种持久性存储，如何处理 TLS 证书/密钥对轮换，日志聚合和升级，都是单独博文的绝佳主题。请告诉我们您希望在后续文章中看到什么！

可执行示例​

本文附带的文件可以在DIY RabbitMQ on Kubernetes 示例存储库中找到。本文使用 Google Kubernetes Engine (GKE) 集群，但 Kubernetes 概念是通用的。

要按照示例操作，

本文假设读者熟悉kubectl 的基本用法，并且该工具已设置以与 GKE 集群配合使用。

RabbitMQ Docker 镜像​

我们建议使用社区 RabbitMQ Docker 镜像。该镜像由Docker 社区维护，并使用最新版本的 RabbitMQ、Erlang 和 OpenSSL 构建。该镜像有一个使用 RabbitMQ 发布候选版本构建的变体，用于早期测试和采用。

现在让我们从在 Kubernetes 上运行的 RabbitMQ 集群的第一个构建块开始：选择要部署到的命名空间。

Kubernetes 命名空间和权限 (RBAC)​

每组 Kubernetes 对象都属于一个Kubernetes 命名空间。RabbitMQ 集群资源也不例外。

我们建议使用专用命名空间来将 RabbitMQ 集群与可能部署在 Kubernetes 集群中的其他服务隔离开来。拥有专用命名空间在逻辑上是有意义的，并且可以轻松地授予集群节点足够的权限。这是一种良好的安全实践。

RabbitMQ 的 Kubernetes 对等发现插件依赖 Kubernetes API 作为数据源。在第一次启动时，每个节点都将尝试使用 Kubernetes API 发现其对等节点并尝试加入它们。完成启动的节点会发出一个Kubernetes 事件，以便更容易地在集群活动（事件）日志中发现此类事件。

该插件需要访问以下 Kubernetes 资源

  • 对 endpoints 资源的 get 访问权限
  • 对 events 资源的 create 访问权限

指定一个角色、角色绑定和服务帐户来配置此访问权限。

在rbac.yaml 示例文件中可以看到一个示例命名空间以及 RBAC 规则。

如果按照示例操作，请使用以下命令创建命名空间和所需的 RBAC 规则。请注意，这将创建一个名为 test-rabbitmq 的命名空间。

kubectl apply -f namespace.yaml
kubectl apply -f rbac.yaml

以下 kubectl 示例将使用 test-rabbitmq 命名空间。为了方便起见，可以将此命名空间设置为默认命名空间

# set the namespace to be the current (default) one
kubectl config set-context --current --namespace=test-rabbitmq
# verify
kubectl config view --minify | grep namespace:

或者，可以将 --namespace="test-rabbitmq" 附加到下面演示的所有 kubectl 命令。

使用有状态集​

RabbitMQ**需要**使用有状态集将 RabbitMQ 集群部署到 Kubernetes。有状态集确保 RabbitMQ 节点按顺序依次部署。这避免了在部署多节点 RabbitMQ 集群时遇到潜在的对等发现竞争条件。

与使用 Deployment 相比，使用有状态集还有其他同样重要的原因：粘性身份、简单的网络标识符、稳定的持久性存储以及执行有序滚动升级的能力。

有状态集定义文件包含许多详细信息，例如挂载配置、挂载凭据、打开端口等，这些将在以下部分中按主题进行说明。

最终的有状态集文件可以在gke 目录下找到。

为集群和 CLI 工具创建服务​

有状态集定义可以引用一个服务，该服务为有状态集的 Pod 提供其网络标识。在这里，我们指的是v1.StatefulSet.Spec.serviceName 属性。

RabbitMQ 的集群需要此属性，并且如 Kubernetes 文档中所述，必须在创建有状态集之前创建此属性。

RabbitMQ 使用端口 4369 用于节点发现，使用端口 25672 用于节点间通信。由于此服务在内部使用并且不需要公开，因此我们创建了一个无头服务。它可以在示例 headless-service.yaml 文件中找到。

如果按照示例操作，请运行以下命令为节点间和 CLI 工具流量创建无头服务

kubectl apply -f rabbitmq-headless.yaml

现在可以在 test-rabbitmq 命名空间中观察到该服务

kubectl get all
# => NAME                        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
# => service/rabbitmq-headless   ClusterIP   None         <none>        4369/TCP   7s

为节点数据使用持久卷​

为了使 RabbitMQ 节点在 Pod 重启之间保留数据，节点的数据目录必须使用持久化存储。必须将一个持久化卷附加到每个 RabbitMQ Pod。

如果使用瞬时卷作为 RabbitMQ 节点的后端，则在重启的情况下，节点将丢失其身份及其所有本地数据。这包括模式和持久化队列数据。在每次节点重启时同步所有这些数据效率极低。在滚动重启期间发生仲裁丢失的情况下，这也将导致数据丢失。

在我们的statefulset.yaml 示例中，我们创建了一个持久化卷声明来配置持久化卷。

持久化卷挂载在 /var/lib/rabbitmq/mnesia。此路径用于RABBITMQ_MNESIA_BASE 位置：节点所有持久化数据的基目录。

RabbitMQ 文档中提供了RabbitMQ 默认文件路径的描述。

如果需要，可以使用 RABBITMQ_MNESIA_BASE 变量更改节点的数据目录基路径。确保将持久化卷挂载到更新后的路径。

RabbitMQ 节点和 CLI 工具使用一个称为Erlang Cookie的共享密钥来相互认证。Cookie 值是一个最多 255 个字符的字母数字字符字符串。由于节点需要 Cookie 值来形成集群，因此必须在创建 RabbitMQ 集群之前生成该值。

使用社区 Docker 镜像，RabbitMQ 节点将期望 Cookie 位于 /var/lib/rabbitmq/.erlang.cookie。我们建议创建一个密钥并将其作为卷挂载到此路径上的 Pod。

这在statefulset.yaml 示例文件中进行了演示。

密钥预计具有以下键值对

cookie: {value}

要创建 Cookie 密钥，请运行

echo -n "this secret value is JUST AN EXAMPLE. Replace it!" > cookie
kubectl create secret generic erlang-cookie --from-file=./cookie

这将创建一个密钥，该密钥具有一个名为 cookie 的键（取自文件名）以及文件内容作为其值。

管理员凭据​

RabbitMQ 将在第一次启动时使用众所周知的凭据播种一个默认用户。此用户的用户名和密码均为 guest。

默认情况下，此默认用户只能从本地主机连接。可以通过选择加入来解除此限制。这可能对测试有用，但非常不安全。相反，必须使用生成的凭据创建管理员用户。

管理员用户凭据应存储在Kubernetes 密钥中，并将其挂载到 RabbitMQ Pod 上。然后可以将 RABBITMQ_DEFAULT_USER 和 RABBITMQ_DEFAULT_PASS 环境变量设置为密钥值。社区 Docker 镜像将使用它们来覆盖默认用户凭据。

参考示例.

密钥预计具有以下键值对

user: {username}
pass: {password}

要创建管理员用户密钥，请使用

# this is merely an example, you are welcome to use a different username
echo -n "administrator" > user
# this is merely an example, you MUST use a different, generated password value!
echo -n "g3N3rAtED-Pa$$w0rd" > pass
kubectl create secret generic rabbitmq-admin --from-file=./user --from-file=./pass

这将创建一个密钥，该密钥具有两个键 user 和 pass（取自文件名）以及文件内容作为其各自的值。

也可以使用 CLI 工具显式创建用户。请参阅RabbitMQ 关于用户管理的文档部分以了解更多信息。

节点配置​

有几种方法可以配置 RabbitMQ 节点。推荐的方法是使用配置文件。

配置文件可以表示为配置映射，并作为卷挂载到 RabbitMQ Pod 上。

要创建具有 RabbitMQ 配置的配置映射，请应用我们的最小 configmap.yaml 示例

kubectl apply -f configmap.yaml

使用初始化容器​

从 Kubernetes 1.9.4 开始，配置映射作为只读卷挂载到 Pod 上。这对 RabbitMQ 社区 Docker 镜像来说是有问题的：镜像可能会在容器启动时尝试更新配置文件。

因此，挂载 RabbitMQ 配置的路径必须是可读写的。如果 Docker 镜像检测到只读文件，您将看到以下警告

touch: cannot touch '/etc/rabbitmq/rabbitmq.conf': Permission denied

WARNING: '/etc/rabbitmq/rabbitmq.conf' is not writable, but environment variables have been provided which request that we write to it
  We have copied it to '/tmp/rabbitmq.conf' so it can be amended to work around the problem, but it is recommended that the read-only
  source file should be modified and the environment variables removed instead.

虽然 Docker 镜像确实解决了此问题，但将配置文件存储在 /tmp 中并不是理想的做法，我们建议改为将挂载路径设为可读写。

与 Kubernetes 社区中的其他一些项目一样，我们使用初始化容器来克服这个问题。

示例

以 rabbitmq 用户身份运行 Pod​

Docker 镜像以 rabbitmq 用户身份（uid 为 999）运行并写入 rabbitmq.conf 文件。因此，rabbitmq.conf 上的文件权限必须允许这样做。可以将Pod 安全上下文添加到 Stateful Set 定义中以实现此目的。在安全上下文中将runAsUser、runAsGroup 和 fsGroup 设置为 999。

请参阅 Stateful Set 定义文件中的安全上下文。

导入定义​

RabbitMQ 节点可以导入从另一个 RabbitMQ 集群导出的定义。这也可以在节点启动时完成。

根据 RabbitMQ 文档，这可以通过以下步骤完成

  1. 从您希望复制的 RabbitMQ 集群导出定义并保存文件
  2. 创建一个配置映射，其中键为文件名，值为文件内容（请参阅 rabbitmq.conf 配置映射示例）
  3. 将配置映射作为卷挂载到 Stateful Set 定义中的 RabbitMQ Pod 上
  4. 使用 load_definitions = /path/to/definitions/file 更新 rabbitmq.conf 配置映射

就绪探针​

Kubernetes 使用称为就绪探针的检查来确定 Pod 是否已准备好为客户端流量提供服务。这实际上是由系统操作员定义的专门的健康检查。

当使用有序 Pod 部署策略时（这是 RabbitMQ 集群的推荐选项），探针会控制 Kubernetes 控制器何时将当前部署的 Pod 视为已准备好并继续部署下一个 Pod。如果没有正确选择此检查，则可能会导致滚动集群节点重启死锁。

属于集群的 RabbitMQ 节点将在启动时尝试与其对等节点同步模式。如果在可配置的时间窗口（默认为五分钟）内没有对等节点上线，则节点将放弃并自愿停止。在同步完成之前，节点不会将其标记为已完全启动。

因此，如果就绪探针假设节点已完全启动并正在运行，则使用此类探针进行 RabbitMQ 节点 Pod 的滚动重启将导致死锁：探针将永远不会成功，并且永远不会继续部署下一个 Pod，而该 Pod 必须上线才能使原始 Pod 被部署视为已准备好。

因此，建议对就绪探针使用非常基本的 RabbitMQ 健康检查

rabbitmq-diagnostics ping

虽然此检查并不彻底，但它允许所有 Pod 在一定时间段内启动并重新加入集群，即使 Pod 按顺序一个接一个地重启也是如此。

RabbitMQ 集群指南的专门部分对此进行了介绍：重启和健康检查（就绪探针）。

Stateful Set 定义文件中的就绪探针部分演示了如何配置就绪探针。

存活性探针​

与上面描述的就绪探针类似，Kubernetes 允许使用称为存活性探针的不同健康检查来检查 Pod 的健康状况。该检查确定是否必须重启 Pod。

与所有健康检查一样，没有一种适用于所有部署的单一解决方案。健康检查可能会产生误报，这意味着合理的健康、正常运行的节点将毫无理由地重启甚至销毁和重新创建，从而降低系统可用性。

此外，RabbitMQ 节点重启不一定能解决问题。例如，重启由于可用磁盘空间不足而处于告警状态的节点将无济于事。

所有这一切都表明，必须明智地选择存活性探针，并考虑到误报和“可通过重启恢复”。存活性探针还必须使用节点本地健康检查而不是集群范围的健康检查。

RabbitMQ CLI 工具提供了一些预定义的健康检查，这些检查在彻底程度、侵入性以及在不同场景（例如系统负载下）中产生误报的可能性方面有所不同。这些检查是可以组合的，并且可以组合使用。正确的存活性探针选择是特定于系统的决定。如有疑问，请从更简单、侵入性更小、彻底性更低的选项开始，例如

rabbitmq-diagnostics -q ping

以下检查可以作为合理的存活性探针候选者

rabbitmq-diagnostics -q check_port_connectivity
rabbitmq-diagnostics -q check_local_alarms

但是请注意，对于被“暂停少数派”分区处理程序策略暂停的节点，它们将失败。

Stateful Set 定义文件中的存活性探针部分演示了如何配置存活性探针。

插件​

RabbitMQ 支持插件。某些插件在 Kubernetes 上运行 RabbitMQ 时至关重要，例如 Kubernetes 特定的对等发现实现。

在 Kubernetes 上部署 RabbitMQ 需要 rabbitmq_peer_discovery_k8s 插件。通常还会启用 rabbitmq_management 插件 以获得基于浏览器的管理 UI 和 HTTP API，以及 rabbitmq_prometheus 用于监控。

可以通过 不同的方式 启用插件。我们建议将插件文件 enabled_plugins 挂载到节点配置目录 /etc/rabbitmq。可以使用 ConfigMap 来表示 enabled_plugins 文件的值。然后，可以将其作为 Volume 挂载到 StatefulSet 定义中的每个 RabbitMQ 容器上。

在我们 configmap.yaml 示例 文件中，我们演示了如何填充 enabled_plugins 文件并将其挂载到 /etc/rabbitmq 目录下。

端口​

StatefulSet 的最后一个考虑因素是在 RabbitMQ Pod 上打开的端口。RabbitMQ 支持的协议都是基于 TCP 的，需要在 RabbitMQ 节点上打开 协议端口。根据节点上启用的插件，所需端口列表可能会有所不同。

上面提到的 enabled_plugins 示例文件启用了几个插件：rabbitmq_peer_discovery_k8s（必需）、rabbitmq_management 和 rabbitmq_prometheus。因此，服务必须 打开几个端口，这些端口与核心服务器和启用的插件相关。

  • 5672：AMQP 0-9-1 和 AMQP 1.0 客户端使用。
  • 15672：管理 UI 和 HTTP API。
  • 15692：Prometheus 采集端点。

部署 StatefulSet​

这些是 StatefulSet 文件中的关键组件。请查看 该文件，如果按照示例操作，请部署 StatefulSet。

kubectl apply -f statefulset.yaml

这将开始启动 RabbitMQ 集群。要观察进度...

watch kubectl get all
# => NAME             READY   STATUS    RESTARTS   AGE
# => pod/rabbitmq-0   0/1     Pending   0          8s
# =>
# => NAME                        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
# => service/rabbitmq-headless   ClusterIP   None         <none>        4369/TCP   61m
# =>
# => NAME                        READY   AGE
# => statefulset.apps/rabbitmq   0/1     8s

为客户端连接创建服务​

如果上述所有步骤都成功，则应该在 Kubernetes 上部署了功能正常的 RabbitMQ 集群！? 但是，在 Kubernetes 上拥有 RabbitMQ 集群只有在客户端可以 连接 到它时才有用。

是时候创建一个服务，使集群可供 客户端连接 使用了。

服务的类型取决于您的用例。Kubernetes API 参考 对可用的服务类型进行了很好的概述。

在 client-service.yaml 示例文件 中，我们使用了 LoadBalancer 服务。这为我们提供了一个可以用来访问 RabbitMQ 集群的外部 IP。

例如，这应该可以访问 RabbitMQ 管理 UI，方法是访问 {external-ip}:15672 并登录。客户端应用程序可以连接到诸如 {external-ip}:5672（AMQP 0-9-1、AMQP 1.0）或 {external-ip}:1883（MQTT）之类的端点。请参阅 入门指南，了解如何使用 RabbitMQ。

如果按照示例操作，请运行

kubectl apply -f client-service.yaml

以创建类型为 LoadBalancer 且具有外部 IP 地址的服务。要找出外部 IP 地址是什么，请使用 kubectl get svc。

kubectl get svc
# => NAME                        TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                                          AGE
# => service/rabbitmq-client     LoadBalancer   10.59.244.70   34.105.135.216   15672:30902/TCP,15692:30605/TCP,5672:31210/TCP   2m19s

资源使用和限制​

容器资源管理 是一个值得单独撰写文章的主题。容量规划 建议完全特定于工作负载、环境和系统。最佳值通常通过对系统进行广泛的 监控、试验和错误来找到。但是，在选择限制和资源分配设置时，请考虑一些 RabbitMQ 特定的因素。

使用最新的主要 Erlang 版本​

RabbitMQ 运行在 Erlang 运行时上。最近的 Erlang/OTP 版本引入了一些对在 Kubernetes 上运行 RabbitMQ 的用户非常重要的改进。

在撰写本文时，RabbitMQ 的 Docker 社区镜像附带 Erlang 23。强烈建议自定义 Docker 镜像的用户也配置 Erlang 23。

CPU 资源使用​

RabbitMQ 旨在用于涉及 多个队列 且节点同时为多个客户端提供服务的工作负载。节点通常会使用所有 允许的 CPU 内核，无需任何显式配置。随着内核数量的增加，可能需要进行一些调整以减少 CPU 上下文切换。

可以通过 运行时线程活动指标 监控 CPU 时间的消耗情况，这些指标也可通过 RabbitMQ Prometheus 插件 公开。

如果 RabbitMQ Pod 徘徊在它们的 CPU 资源配额附近，并在具有大量相对空闲客户端的环境中遇到限制，则可以通过 少量配置 降低负载。

内存限制​

RabbitMQ 使用 运行时内存高水位线 的概念。默认情况下，节点将使用检测到的（可用）内存的 40% 作为水位线。当超过水位线时，整个集群中的发布者将被阻止，并启动更积极的分页到磁盘。水位线值乍一看似乎是 Kubernetes 上的内存配额，但存在重要区别：RabbitMQ 资源警报假设节点通常可以从这种状态恢复。例如，大量积压的消息最终将被消费。

Kubernetes 内存限制由 OOM killer 强制执行：不期望恢复。这意味着 RabbitMQ 节点的内存高水位线**必须低于**对节点容器施加的内存限制。Kubernetes 部署应使用 建议范围 中的相对水位线值。

内存使用细目数据 应该用于确定节点上消耗最多内存的内容。

磁盘使用​

我们强烈建议 RabbitMQ 容器可用的磁盘空间 过度配置。用完磁盘空间的节点并不总是能够从这样的事件中恢复。此类节点必须停用并替换。

最后，考虑用于节点间通信的哪种链路和 Kubernetes 网络选项。网络链路拥塞可能是系统吞吐量的重大限制因素，并影响其可用性。

以下是一个计算工作负载所需带宽量的非常简单的公式（以位为单位）

# peak message rate * bits per message * 110% to account for metadata and protocol framing
PeakMessageRate * AverageMessagePayloadSizeInBytes * 8 * 1.1

因此，平均消息大小为 3 kiB 且预期峰值消息速率为每秒 20K 条消息的工作负载最多可以消耗

3 kiB * 20000/second * 8 * 1.1 = 528 megabits/second

带宽。

RabbitMQ 团队维护了一个用于节点间通信链路指标的 Grafana 仪表盘。

使用 rabbitmq-perf-test 运行集群的功能和负载测试​

RabbitMQ 带有一个负载模拟工具 PerfTest，它可以从集群外部执行，也可以使用 perf-test 公共 docker 镜像 部署到 Kubernetes。以下是如何在 Kubernetes 集群中部署该镜像的示例

kubectl run perf-test --image=pivotalrabbitmq/perf-test -- --uri amqp://{username}:{password}@{service}

这里 {username} 和 {password} 是用户凭据，例如在 rabbitmq-admin Secret 中设置的那些。{serivce} 是要连接到的主机名。我们使用客户端服务的名称，该服务在部署时将解析为主机名。

上述 kubectl run 命令将启动一个 PerfTest Pod，可以在

kubectl get pods

中观察到。对于功能正常的 RabbitMQ 集群，运行 kubectl logs -f {perf-test-pod-name}（其中 {perf-test-pod-name} 是由 kubectl get pods 报告的 Pod 名称）将生成类似于以下内容的输出

id: test-110102-976, time: 263.100s, sent: 21098 msg/s, received: 21425 msg/s, min/median/75th/95th/99th consumer latency: 1481452/1600817/1636996/1674410/1682972 ?s
id: test-110102-976, time: 264.100s, sent: 17314 msg/s, received: 17856 msg/s, min/median/75th/95th/99th consumer latency: 1509657/1600942/1636253/1695525/1718537 ?s
id: test-110102-976, time: 265.100s, sent: 18597 msg/s, received: 17707 msg/s, min/median/75th/95th/99th consumer latency: 1573151/1716519/1756060/1813985/1846490 ?s

要了解有关 PerfTest、其设置、功能和输出的更多信息，请参阅 PerfTest 文档指南。

PerfTest 不应永久运行。要拆除 perf-test Pod，请使用

kubectl delete pod perf-test

监控集群​

监控 是任何生产部署中至关重要的部分。

RabbitMQ 带有 内置的 Prometheus 支持。要启用它，请启用 rabbitmq_prometheus 插件。这可以通过将 rabbitmq_promethus 添加到 enabled_plugins ConfigMap 中来完成，如上所述。

Prometheus 采集端口 15972 必须在 Pod 和客户端服务上都打开。

节点和集群指标可以使用 Grafana 可视化。

备选方案：RabbitMQ 的 Kubernetes 集群操作符​

正如这篇文章所展示的，在 Kubernetes 上托管 RabbitMQ 等有状态数据服务涉及相当多的部分。这看起来可能是一项艰巨的任务。本文展示了这种 DIY 部署的几种替代方案。

VMware 的 RabbitMQ 团队已经开源了一个用于 RabbitMQ 的 Kubernetes 运算符模式 实现。截至 2020 年 8 月，这是一个处于积极开发中的年轻项目。虽然它目前有一些限制，但我们建议您选择它，而不是本文展示的手动 DIY 设置。

请参阅 RabbitMQ 集群 Kubernetes 运算符 以了解更多信息。该项目在 GitHub 上的 rabbitmq/cluster-operator 中公开开发。请尝试一下，并告诉我们结果如何。除了 GitHub 之外，向运算符背后的团队提供反馈的两个绝佳场所是 RabbitMQ 邮件列表 和 RabbitMQ 社区 Slack 中的 #kubernetes 频道。

© 2024 RabbitMQ. All rights reserved.