本站支持搜索的镜像仓库:Docker Hub、gcr.io、ghcr.io、quay.io、k8s.gcr.io、registry.gcr.io、elastic.co、mcr.microsoft.com
RabbitMQ Cluster Kubernetes Operator可自动化在Kubernetes上运行的RabbitMQ集群的配置、管理和运维操作。
RabbitMQ Cluster Operator 概述
商标声明:本软件列表由Bitnami打包。产品中提及的 respective 商标归各自公司所有,使用这些商标并不意味着任何关联或背书。
helm install my-release oci://registry-1.docker.io/bitnamicharts/rabbitmq-cluster-operator
希望在生产环境中使用RabbitMQ Cluster Operator?请尝试VMware Tanzu Application Catalog,即Bitnami目录的商业版本。
自2025年8月28日起,Bitnami将升级其公共目录,在新的Bitnami Secure Images计划下提供精选的强化、安全聚焦镜像集。作为此次过渡的一部分:
这些变更旨在通过推广软件供应链完整性和最新部署的最佳实践,提升所有Bitnami用户的安全态势。更多详情,请访问Bitnami Secure Images公告。
Bitnami Helm Chart经过精心设计、积极维护,是在Kubernetes集群上部署容器的最快、最简单方式,可直接用于生产工作负载。
本Chart使用Helm包管理器在Kubernetes集群中引导部署RabbitMQ Cluster Operator。
要使用发布名称my-release安装Chart:
helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/rabbitmq-cluster-operator
注意:需将占位符
REGISTRY_NAME和REPOSITORY_NAME替换为Helm Chart仓库和存储库的引用。例如,对于Bitnami,需使用REGISTRY_NAME=registry-1.docker.io和REPOSITORY_NAME=bitnamicharts。
该命令将RabbitMQ Cluster Kubernetes Operator部署到Kubernetes集群的默认配置中。参数部分列出了安装过程中可配置的参数。
提示:使用
helm list列出所有发布
在Bitnami目录中,我们提供bitnami/rabbitmq和bitnami/rabbitmq-operator两种Chart。每种解决方案适用于不同需求和场景。
bitnami/rabbitmq chart使用Kubernetes StatefulSet对象(以及Service、PVC、ConfigMap等)部署单个RabbitMQ实例。下图显示执行helm install后集群中部署的对象:
+--------------+ +-----+ | | | | Service | RabbitMQ +<------------+ PVC | <-------------------+ | | | | StatefulSet | +-----+ | | +-----------+--+ ^ +------------+ | | | +----------------+ Configmaps | | Secrets | +------------+
其生命周期通过Helm管理,在RabbitMQ容器级别,自动执行持久化管理、基于环境变量的配置和插件初始化。StatefulSet不需要任何具有特殊RBAC权限的ServiceAccount,因此该解决方案更适合权限受限的Kubernetes环境。
bitnami/rabbitmq-operator chart使用Kubernetes Deployment部署RabbitMQ Operator。下图显示执行helm install后部署的RabbitMQ Operator:
+--------------------+ | | +---------------+ | RabbitMQ Operator | | | | | | RBAC | | Deployment | | Privileges | +-------+------------+ +-------+-------+ ^ | | +-----------------+ | +---+ Service Account +<----+ +-----------------+
Operator将通过以下对象扩展Kubernetes API:RabbitmqCluster。此后,用户可部署此类对象,已部署的Operator将负责部署运行RabbitMQ实例所需的所有StatefulSet、ConfigMap和Service。其生命周期通过kubectl管理RabbitmqCluster对象。下图显示使用kubectl部署RabbitmqCluster对象后部署的对象:
+--------------------+ | | +---------------+ | RabbitMQ Operator | | | | | | RBAC | | Deployment | | Privileges | +-------+------------+ +-------+-------+ | ^ | | | +-----------------+ | | +---+ Service Account +<----+ | +-----------------+ | | | | | ------------------------------------------------------------------------- | | | | | +--------------+ +-----+ | | | | | | | | |--->| Service | RabbitMQ +<------------+ PVC | | | <-------------------+ | | | | | | StatefulSet | +-----+ | | | | | | +-----------+--+ | | ^ +------------+ | | | | | | | +----------------+ Configmaps | | | | Secrets | | | +------------+ | | | | | -------------------------------------------------------------------------
与bitnami/rabbitmq chart相比,该解决方案可更轻松地部署多个RabbitMQ实例。由于Operator自动部署RabbitMQ实例,RabbitMQ Operator Pod需要具有创建和销毁多个Kubernetes对象权限的ServiceAccount。这在具有严格基于角色访问策略的Kubernetes集群中可能存在问题。
Bitnami Chart允许为Chart部署中的所有容器设置资源请求和限制,这些配置位于resources值中(参见参数表)。为生产工作负载设置请求至关重要,且应根据具体用例调整。
为简化此过程,Chart包含resourcesPreset值,可根据不同预设自动设置resources部分。有关这些预设的详细信息,请参见bitnami/common chart。但在生产工作负载中,不建议使用resourcesPreset,因为它可能无法完全适应您的具体需求。有关容器资源管理的更多信息,请参见Kubernetes官方文档。
要在Kubernetes上备份和恢复Helm Chart部署,需使用Velero(Kubernetes备份/恢复工具)备份源部署的持久卷,并将其附加到新部署。有关使用Velero的说明,请参见本指南。
通过将clusterOperator和msgTopologyOperator部分下的*.metrics.enabled设置为true,可将本Chart与Prometheus集成。这将在容器中公开RabbitMQ Cluster Operator和RabbitMQ Messaging Topology Operator的原生Prometheus端口,并创建可在*.metrics.service(位于clusterOperator和msgTopologyOperator部分下)中配置的不同metrics服务。这些服务还将包含必要的注解,以便被Prometheus自动抓取。
要使集成正常工作,需安装Prometheus或Prometheus Operator。安装Bitnami Prometheus helm chart或Bitnami Kube Prometheus helm chart,可轻松在集群中部署可用的Prometheus。
Chart可部署ServiceMonitor对象以与Prometheus Operator集成。为此,需将clusterOperator和msgTopologyOperator部分下的*.metrics.serviceMonitor.enabled设置为true。确保集群中已安装Prometheus Operator CustomResourceDefinitions,否则将失败并显示以下错误:
no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
安装Bitnami Kube Prometheus helm chart以获取必要的CRD和Prometheus Operator。
强烈建议在生产环境中使用不可变标签。这可确保如果同一标签使用不同镜像更新,部署不会自动更改。
如果主容器有新版本、重大变更或严重漏洞,Bitnami将发布新Chart以更新其容器。
如需添加额外环境变量(用于高级操作,如自定义初始化脚本),可使用extraEnvVars属性。
rabbitmq-cluster-operator: extraEnvVars: - name: LOG_LEVEL value: error
或者,可使用包含环境变量的ConfigMap或Secret。为此,使用extraEnvVarsCM或extraEnvVarsSecret值。
如需在rabbitmq-cluster-operator所在的同一Pod中添加额外容器(如额外指标或日志导出器),可使用sidecars参数定义。
sidecars: - name: your-image-name image: your-image imagePullPolicy: Always ports: - name: portname containerPort: 1234
如果这些边车容器导出额外端口,可使用service.extraPorts参数(如可用)添加额外端口定义,如下例所示:
service: extraPorts: - name: extraPort port: 11311 targetPort: 11311
注意:此Helm Chart已包含Prometheus导出器的边车容器(如适用)。可在部署时添加
--enable-metrics=true参数激活这些容器。因此,sidecars参数仅应用于添加额外边车容器。
如需在同一Pod中添加额外初始化容器,可使用initContainers参数定义。示例如下:
initContainers: - name: your-image-name image: your-image imagePullPolicy: Always ports: - name: portname containerPort: 1234
了解更多关于边车容器和初始化容器的信息。
本Chart允许使用affinity参数设置自定义亲和性。有关Pod亲和性的更多信息,请参见Kubernetes文档。
作为替代方案,可使用bitnami/common chart中提供的Pod亲和性、Pod反亲和性和节点亲和性预设配置。为此,设置podAffinityPreset、podAntiAffinityPreset或nodeAffinityPreset参数。
如需部署额外对象(如自定义RabbitmqCluster对象),Chart允许使用extraDeploy参数添加其他对象的完整规范。
例如,要部署自定义RabbitmqCluster定义,可使用以下值安装RabbitMQ Cluster Operator:
extraDeploy: - apiVersion: rabbitmq.com/v1beta1 kind: RabbitmqCluster metadata: name: rabbitmq-custom-configuration spec: replicas: 1 rabbitmq: additionalConfig: | log.console.level = debug
| 名称 | 描述 | 值 |
|---|---|---|
global.imageRegistry | 全局Docker镜像仓库 | "" |
global.imagePullSecrets | 全局Docker仓库密钥名称数组 | [] |
global.defaultStorageClass | 持久卷的全局默认StorageClass | "" |
global.storageClass | 已弃用:使用global.defaultStorageClass代替 | "" |
global.security.allowInsecureImages | 允许跳过镜像验证 | false |
global.compatibility.openshift.adaptSecurityContext | 调整部署的securityContext部分以兼容Openshift restricted-v2 SCC:移除runAsUser、runAsGroup和fsGroup,让平台使用允许的默认ID。可能值:auto(如检测到运行的集群为Openshift则应用)、force(始终执行调整)、disabled(不执行调整) | auto |
| 名称 | 描述 | 值 |
|---|---|---|
kubeVersion | 覆盖Kubernetes版本 | "" |
nameOverride | 部分覆盖common.names.fullname的字符串 | "" |
fullnameOverride | 完全覆盖common.names.fullname的字符串 | "" |
commonLabels | 添加到所有部署对象的标签 | {} |
commonAnnotations | 添加到所有部署对象的注解 | {} |
clusterDomain | Kubernetes集群域名 | cluster.local |
extraDeploy | 随发布一起部署的额外对象数组 | [] |
diagnosticMode.enabled | 启用诊断模式(所有探针将被禁用) | false |
注意:本Chart的README因超出DockerHub 25000字符限制已被截断。完整README和参数列表请参见[***]
免费版仅支持 Docker Hub 加速,不承诺可用性和速度;专业版支持更多镜像源,保证可用性和稳定速度,提供优先客服响应。
免费版仅支持 docker.io;专业版支持 docker.io、gcr.io、ghcr.io、registry.k8s.io、nvcr.io、quay.io、mcr.microsoft.com、docker.elastic.co 等。
当返回 402 Payment Required 错误时,表示流量已耗尽,需要充值流量包以恢复服务。
通常由 Docker 版本过低导致,需要升级到 20.x 或更高版本以支持 V2 协议。
先检查 Docker 版本,版本过低则升级;版本正常则验证镜像信息是否正确。
使用 docker tag 命令为镜像打上新标签,去掉域名前缀,使镜像名称更简洁。
探索更多轩辕镜像的使用方法,找到最适合您系统的配置方式
通过 Docker 登录方式配置轩辕镜像加速服务,包含7个详细步骤
在 Linux 系统上配置轩辕镜像源,支持主流发行版
在 Docker Desktop 中配置轩辕镜像加速,适用于桌面系统
在 Docker Compose 中使用轩辕镜像加速,支持容器编排
在 k8s 中配置 containerd 使用轩辕镜像加速
在宝塔面板中配置轩辕镜像加速,提升服务器管理效率
在 Synology 群晖NAS系统中配置轩辕镜像加速
在飞牛fnOS系统中配置轩辕镜像加速
在极空间NAS中配置轩辕镜像加速
在爱快ikuai系统中配置轩辕镜像加速
在绿联NAS系统中配置轩辕镜像加速
在威联通NAS系统中配置轩辕镜像加速
在 Podman 中配置轩辕镜像加速,支持多系统
配置轩辕镜像加速9大主流镜像仓库,包含详细配置步骤
无需登录即可使用轩辕镜像加速服务,更加便捷高效
需要其他帮助?请查看我们的 常见问题 或 官方QQ群: 13763429