bitnamicharts/rabbitmq-cluster-operatorRabbitMQ Cluster Kubernetes Operator可自动化在Kubernetes上运行的RabbitMQ集群的配置、管理和运维操作。
RabbitMQ Cluster Operator 概述
商标声明:本软件列表由Bitnami打包。产品中提及的 respective 商标归各自公司所有,使用这些商标并不意味着任何关联或背书。
consolehelm 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:
consolehelm 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后集群中部署的对象:
text+--------------+ +-----+ | | | | Service | RabbitMQ +<------------+ PVC | <-------------------+ | | | | StatefulSet | +-----+ | | +-----------+--+ ^ +------------+ | | | +----------------+ Configmaps | | Secrets | +------------+
其生命周期通过Helm管理,在RabbitMQ容器级别,自动执行持久化管理、基于环境变量的配置和插件初始化。StatefulSet不需要任何具有特殊RBAC权限的ServiceAccount,因此该解决方案更适合权限受限的Kubernetes环境。
bitnami/rabbitmq-operator chart使用Kubernetes Deployment部署RabbitMQ Operator。下图显示执行helm install后部署的RabbitMQ Operator:
text+--------------------+ | | +---------------+ | RabbitMQ Operator | | | | | | RBAC | | Deployment | | Privileges | +-------+------------+ +-------+-------+ ^ | | +-----------------+ | +---+ Service Account +<----+ +-----------------+
Operator将通过以下对象扩展Kubernetes API:RabbitmqCluster。此后,用户可部署此类对象,已部署的Operator将负责部署运行RabbitMQ实例所需的所有StatefulSet、ConfigMap和Service。其生命周期通过kubectl管理RabbitmqCluster对象。下图显示使用kubectl部署RabbitmqCluster对象后部署的对象:
text+--------------------+ | | +---------------+ | 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,否则将失败并显示以下错误:
textno matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
安装Bitnami Kube Prometheus helm chart以获取必要的CRD和Prometheus Operator。
强烈建议在生产环境中使用不可变标签。这可确保如果同一标签使用不同镜像更新,部署不会自动更改。
如果主容器有新版本、重大变更或严重漏洞,Bitnami将发布新Chart以更新其容器。
如需添加额外环境变量(用于高级操作,如自定义初始化脚本),可使用extraEnvVars属性。
yamlrabbitmq-cluster-operator: extraEnvVars: - name: LOG_LEVEL value: error
或者,可使用包含环境变量的ConfigMap或Secret。为此,使用extraEnvVarsCM或extraEnvVarsSecret值。
如需在rabbitmq-cluster-operator所在的同一Pod中添加额外容器(如额外指标或日志导出器),可使用sidecars参数定义。
yamlsidecars: - name: your-image-name image: your-image imagePullPolicy: Always ports: - name: portname containerPort: 1234
如果这些边车容器导出额外端口,可使用service.extraPorts参数(如可用)添加额外端口定义,如下例所示:
yamlservice: extraPorts: - name: extraPort port: *** targetPort: ***
注意:此Helm Chart已包含Prometheus导出器的边车容器(如适用)。可在部署时添加
--enable-metrics=true参数激活这些容器。因此,sidecars参数仅应用于添加额外边车容器。
如需在同一Pod中添加额外初始化容器,可使用initContainers参数定义。示例如下:
yamlinitContainers: - 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:
yamlextraDeploy: - 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和参数列表请参见[***]
manifest unknown 错误
TLS 证书验证失败
DNS 解析超时
410 错误:版本过低
402 错误:流量耗尽
身份认证失败错误
429 限流错误
凭证保存错误
来自真实用户的反馈,见证轩辕镜像的优质服务