前置条件
使用 Helm Chart 安装 AutoMQ 之前,需要满足如下条件:-
准备 Kubernetes 环境 :提前准备一个可用的 Kubernetes 集群,并满足如下条件:
- 预留 AutoMQ 计算资源 :AutoMQ 每个 Pod 推荐分配 4Core16GB 资源,并建议独占 Node 部署以获取稳定的网络吞吐性能。
- 存储插件: 如果您的 Kubernetes 由云厂商提供,推荐安装云厂商提供的存储插件用于管理 EBS 卷资源。
- 准备对象存储 Bucket。 AutoMQ 每个集群需要 2 个独立的对象存储 Bucket,一个是 Ops Bucket 用于存储系统日志和 Metrics 数据,一个是 Data Bucket 存储消息数据。请参考对象存储产品的文档创建。
- 安装 Helm Chart 工具: 推荐安装大于等于 3.6 版本。可参考文档操作。
获取 AutoMQ Software Chart
当前稳定 Chart 版本请参考数据面集群历史版本。 AutoMQ Software Chart 镜像通过 Azure Container Registry (East US) 镜像仓库进行发布和公开。您可以通过如下命令进行拉取测试。安装 AutoMQ
AutoMQ Software 提供两种 WAL 存储类型,分别是 EBSWAL 和 S3WAL,两种存储引擎对比如下,建议根据需求选择。详细原理请参考技术架构。- EBSWAL 模式: WAL 存储使用高速 EBS 卷,提供 <10 毫秒的发送 RT 性能,目前仅支持 AWS、GCP、Azure 等公共云环境,使用时需要通过 StorageClass,为 AutoMQ 的 Pod 分配 EBS 卷。
- S3WAL 模式: 部署相对简单,WAL 存储直接写对象存储,提供百毫秒级的发送 RT 性能,支持所有公共云环境以及私有数据中心(提供兼容 S3 的对象存储即可),部署相对简单,无需分配 EBS 卷。
Step1:创建 Credentials,并进行授权
AutoMQ 集群需要访问对象存储和存储卷等外部服务,因此在安装前需要为 AutoMQ 创建 Credentials 并完成授权。- AWS
- Azure
- OCI
AWS 公共云环境部署 AutoMQ 且使用 AWS S3 存储,则需要前往 IAM 产品创建授权策略,AutoMQ 访问 AWS S3 需要被授予以下操作权限:如果您使用 EBSWAL 模式部署,则需要额外授权如下策略:用户创建 IAM 授权策略后,可以通过以下两种方式创建 Credentials。
- 使用 IAM 子账号静态 AccessKey: 此模式下需要将授权策略附加给 IAM 子账号,并通过 IAM 子账号的静态 AccessKeyId 和 AccessKeySecret 作为 Credentials 访问 AutoMQ。
- 使用 IAM Role 动态凭证 : 此模式下需要创建 IAM Role,需要将授权策略附加给 Role。然后在 EKS 上通过 Pod 扮演 EC2 Role 的动态 Credentials 访问 AutoMQ。
Step2:创建 Storage Class
安装 AutoMQ 之前需要在 Kubernetes 集群申明 Storage Class,用于后续分配存储卷。存储卷有以下用途:- 存储 AutoMQ Controller 元数据: AutoMQ 集群中用于元数据管理的 Controller Pod 需要挂载存储卷存储 KRaft 元数据。
- EBSWAL 模式存储 WAL 数据(可选) :如果期望部署 EBSWAL 模式,每个 Broker Pod 也需要挂载数据卷用于写入 WAL 数据。
- AWS
- Azure
- GCP
- OCI
Step3:初始化配置文件
AutoMQ Software Chart 的配置信息包含多个部分,支持用户通过 values.yaml 文件进行自定义覆盖。 首先,需要创建一个空文件automq-values.yaml 。您可以复制下方给出的示例配置进行编辑替换。
修改公共参数
global.cloudProvider.name 该参数约定了部署的云环境,请根据云厂商名称枚举值填写,如果是私有数据中心,也需要按照枚举值填充。
global.cloudProvider.credentials
该参数约定了 AutoMQ 集群访问云资源时使用的公共 Credentials 参数。当前示例以 AccessKey 类型的静态 Credentials 为例,如果期望使用 IAM Role 方式请参照高阶参数文档描述修改。
- AWS
- Azure
- Google Cloud
- OCI
- 阿里云
根据实际情况填充前置条件中创建的 Ops Bucket 和 Data Bucket。
修改存储类等参数
controller.persistence.metadata.storageClass 根据实际情况,将该参数替换成步骤 2 中创建的 Storage Class 名称,用于设置 AutoMQ Controller Pod 存储元数据。修改集群拓扑和资源 Request 参数
根据实际为 AutoMQ 分配的 Node 资源,调整集群拓扑和资源 Request 参数。需要修改的参数如下: broker.replicas AutoMQ Software Chart 默认会启动三个 Controller Pod,Controller Pod 同时也可以提供数据读写能力,如果用户期望额外水平扩展更多的 Broker,则可以设置 broker.replicas 参数。- 默认值:0,代表三节点集群,不需要额外的 Broker。
- 设置范围:>= 0,按需配置。
- controller.resources.requests.cpu
- controller.resources.requests.memory
- controller.resources.limits.cpu
- controller.resources.limits.memory
- controller.env.[KAFKA_HEAP_OPTS]
- broker.resources.requests.cpu
- broker.resources.requests.memory
- broker.resources.limits.cpu
- broker.resources.limits.memory
- broker.env.[KAFKA_HEAP_OPTS]
多 AZ 部署
如果 Kubernetes 集群的节点分布在多个 Availability Zone,可以启用 Chart 的跨 AZ Pod 分布约束。节点需要带有topology.kubernetes.io/zone 标签,并为每个 AZ 预留足够的计算资源。
global.zoneSpreadConstraints 后,Chart 会按 topology.kubernetes.io/zone 将 Controller 和 Broker Pod 均匀分布。若使用独立 Broker,请将 broker.replicas 设置为适合 AZ 数量的副本数。automq.zonerouter.channels 用于 AWS 或 GCP 环境的跨 AZ 流量优化;Consumer 还可以通过 client.rack,或通过 automq.zone.cidr.blocks 配置服务端 CIDR 到 AZ 的映射。
如果需要从集群外访问,并希望 LoadBalancer 覆盖多个 AZ,可以在 Service annotation 中配置多个子网,例如 AWS 的 service.beta.kubernetes.io/aws-load-balancer-subnets。可运行示例请参考 AWS Software 多 AZ Demo。
设置 LoadBalancer 注解,开启 Kubernetes 集群外访问
如果需要从 Kubernetes 集群外部访问 AutoMQ,您需要启用externalAccess。为了配置一个内网 LoadBalancer,您需要修改 values.yaml 中 externalAccess.controller.service.loadBalancerAnnotations 部分,并根据您的云厂商添加以下注解:
- AWS
- Azure
- GCP
- OCI
为创建一个内部网络负载均衡器 (NLB),请添加以下注解:
Step4: 安装 Chart 并访问集群
安装集群
根据实际部署需求调整好 values.yaml 配置文件后,即可安装 AutoMQ。通过 Headless service 在 Kubernetes 集群内访问 AutoMQ
- 查找Headless service
- 使用Kafka客户端进行连接和测试
--bootstrap-server 进行收发消息,可使用以下命令:
通过 LoadBalancer 在 Kubernetes 集群外访问 AutoMQ
- 查找 External Address
- 使用Kafka客户端进行连接和测试
9092 被用作client的访问
其他高阶配置
上述部署文档演示了 AutoMQ 使用 S3WAL 模式部署的简单示例,在实际生产场景中用户可以选择 EBSWAL、添加 Auto-Scaler 支持等高阶配置。完整的配置文件参考 Helm Chart Values 文档▸。设置 WAL 类型
上述安装步骤中使用 S3WAL 作为示例,AutoMQ 同时支持 EBSWAL 和S3WAL两种部署方式。- S3WAL 模式
- EBSWAL 模式
S3WAL 模式下,无需挂载 WAL 数据卷,配置相对简单,首先配置 global.config.s3.wal.path 参数。然后关闭 controller.persistence.wal.enabled 和 broker.persistence.wal.enabled 。
设置 Credentials
AutoMQ 同时支持使用静态的 AccessKey 或者动态 IAM Role 访问外部资源。生产环境中为防止静态的 AccessKey 配置泄露,更加推荐使用云厂商提供的 IAM Role 动态 Credentials。- IAM Role Credentials
- AccessKey Credentials
使用 IAM Role Credentials 则需要在 Step1 中将授权策略附加给 Role。然后参考下方示例修改 Credentials 配置。其中 credentials 的格式填写格式参考如下表格**:**
设置细粒度调度策略
在 Kubernetes 中,AutoMQ 的细粒度调度策略是通过 nodeAffinities 和 tolerations 实现的。建议用户根据其节点类型自定义标签匹配规则:Tolerations
建议在 Kubernetes 节点组中添加一个污点,键为:“dedicated”,运算符为:“Equal”,值为:“automq”,效果为:“NoSchedule”。并在 global.tolerations 中配置相应的容忍规则,以调度 Pod:Node Affinities
覆盖控制器/代理配置中的默认值以匹配节点标签(例如,node-type: automq-worker):设置弹性伸缩
Controller 数量
集群默认部署 3 个 Controller Pod,用户可自定义 Controller 副本数量。注意:集群部署完成后,暂不支持调整 Controller 的 Replicas,以免出现预期外的风险。
Broker 数量
当global.autoscaling.enabled=false 时,broker.replicas 控制纯 Broker 数量,默认为 0。启用 autoscaling 后,由运行时 autoscaler 管理该数量。
Auto-scaling 配置
AutoMQ 内置 autoscaler 由 active Controller 根据 CPU 和 network 利用率决策,调整纯 Broker StatefulSet 的副本数,不使用 Kubernetes HPA。当现有节点容量不足时,需要客户的节点 autoscaler 补充 Kubernetes 节点。开启 Chart 接入
在values.yaml 中设置以下配置并部署 Chart:
apps/statefulsets/scale 权限,并让 Helm 交出 Broker 副本数管理权。保留 Chart 生成的 Role/RoleBinding 和 ServiceAccount API 访问能力,避免其他控制器持续覆盖同一个副本数。
Chart 开关不会自动启用运行时 autoscaler。新集群的
automq.autoscaling.enabled 默认为 false,策略和平台配置为空。开启 Chart autoscaling 后,broker.replicas 不再被渲染,新建 StatefulSet 可能先默认只有 1 个 Broker。下述运行时策略启用后会将纯 Broker 补足至少 3 个,无需首次手动 scale。配置运行时策略
在 Helm release 所在 namespace 中查询纯 Broker StatefulSet:autoscaling.properties,把 <kubernetes-namespace> 和 <broker-statefulset-name> 替换为实际部署值。StatefulSet 名称由 Chart 根据 Helm release 和命名覆盖配置生成;填写 Broker StatefulSet,不要填写 Controller StatefulSet。
minCount、maxCount 和 targetRatio 后重新提交文件。active Controller 采用 CPU/network 中容量需求较大的建议。可选行为参数有默认值,包括 30 分钟缩容稳定窗口和 10 分钟缩容冷却时间。
提交或更新策略
使用与服务端版本匹配的 AutoMQ Software 发行包 CLI。准备admin.properties,填写集群的认证、TLS 配置,使用有权修改 broker-default 配置的账号。将 <bootstrap-server> 替换为可访问的 Kafka bootstrap 地址,包含端口。
查看配置和容量
/data/logs/server.log 中查看 AutoScaling decision 决策日志。如果节点池无法提供满足调度约束的容量,新增 Broker Pod 可能持续 Pending。
停用 autoscaler
先关闭运行时 autoscaler:global.autoscaling.enabled 设为 false、broker.replicas 设为期望值,并执行 Helm upgrade。
身份识别配置
AutoMQ 支持覆盖协议监听并启用安全认证,默认情况下会暴露以下端口:- 客户端访问服务端:9092(PLAINTEXT)。
- Controller 间内部通信:9093(PLAINTEXT)。
- Broker 间内部通信:9094(PLAINTEXT)。
(可选)结合 external-dns 自动写入 Route 53 记录
如果希望在 AWS 中自动把 NLB Hostname 绑定到私有域名,可按以下步骤启用 external-dns:- 在集群中安装 external-dns,启动参数需包含
--source=service --provider=aws --policy=upsert-only --registry=txt,并通过 IRSA 或其它方式为其 ServiceAccount 提供route53:ListHostedZones、route53:ListResourceRecordSets、route53:ChangeResourceRecordSets权限。 listeners.client[].advertisedHostnames.baseDomain必须与 Route 53 Hosted Zone 完全一致(例如automq.private),listeners.client[].advertisedHostnames.externalDns.privateZoneId以及externalAccess.controller.externalDns.privateZoneId也需指向同一个 Hosted Zone ID。- 在
values.yaml中确认/追加如下配置,由监听器声明要发布的 FQDN,controller Service 负责暴露 NLB 并被 external-dns 监听:
status.loadBalancer.ingress 后,external-dns 会在该 Hosted Zone 内创建/更新 automq-bootstrap.automq.private。若要保留手动维护 DNS 的流程,只需把 externalAccess.controller.externalDns.enabled 设为 false 并手动创建记录。
配置 Prometheus RemoteWrite 指标集成
AutoMQ Server 支持通过 Prometheus RemoteWrite 协议将集群的指标数据直接推送到用户自定义的 Prometheus 实例中。这种方式无需在 Kubernetes 集群中额外部署 Prometheus 采集组件,简化了监控架构。 在values.yaml 的 global.config 中配置 s3.telemetry.metrics.exporter.uri 参数即可启用该功能。根据 Prometheus 端点的鉴权方式,选择对应的配置格式:
- 无鉴权
- Basic Auth
- Bearer Token
- AWS SigV4
不需要认证的 Prometheus 端点:
配置 Prometheus Pull 指标采集
AutoMQ 也支持 Pull 模式,由采集器从每个 Pod 的 Prometheus 端点拉取指标。如果使用基于 annotations 发现 Pod 的采集器,在values.yaml 中应用以下配置。
如果 global.config 中已有 s3.telemetry.metrics.exporter.uri,将其值替换为下方的 prometheus:// URI。从 Remote Write 切换到 Pull 时,该配置会替换原有的 rw:// URI。只保留一条 s3.telemetry.metrics.exporter.uri 配置,同时保留其他配置项和已有的 Pod annotations。
http://<pod-ip>:9090/metrics。annotations 用于让采集器发现 controller 和 broker Pod 上的指标端点。采集器的 Kubernetes 服务发现和 relabeling 规则需要读取这些 annotation 键;仅添加 annotations 不会启动监听服务或采集指标。
如果需要使用其他指标端口,例如 9404,将 exporter URI 中的 port=9090 和两处 prometheus.io/automq-port 都改为 9404。同时更新部署中对应的容器或 Service 端口声明,以及 NetworkPolicy。仅修改 Helm 端口声明或 annotation 不会改变实际监听端口。指标端口必须避开所有 Kafka listener 端口,包括客户端、controller 和 inter-broker 的监听端口。
如果 Kubernetes NetworkPolicy 限制了 AutoMQ Pod 的 ingress,需要允许指标采集器访问 controller 和 broker Pod 的指标 TCP 端口(本例为 9090)。如果采集器也受 egress 限制,还需放行对应的出口流量。根据实际部署的 Pod 标签和命名空间限定采集器与 AutoMQ Pod 的匹配范围。添加抓取 annotations 不会自动放行网络访问。
通过 Helm upgrade 应用更新后的 values。在采集器所在网络中,分别验证 controller 和 broker Pod 的 /metrics 端点能否返回 Prometheus 格式的指标:
<pod-ip> 替换为 controller 或 broker Pod 的 IP;如果修改了端口,也需要相应调整命令。可以使用 Grafana Alloy 从该端点抓取指标,并转发到兼容 Prometheus 的后端。
与监控系统集成时,可参考对应文档:
安全与访问控制
AutoMQ 支持多种安全配置来保护传输中的数据和控制客户端访问。本节介绍两种通过 Helm Chart 部署时的主要客户端认证安全模型:SASL_SSL 和 SSL (双向 TLS)。
这两条路径是相互独立的,请选择符合您组织安全策略的路径。
tls.keystorePassword 和 tls.truststorePassword 仅在使用 JKS/PKCS12 keystore 时需要。在默认的 PEM 模式下,Chart 会直接挂载 kafka.crt/kafka.key(或 tls.crt/tls.key)并供 Kafka 使用,这两个参数可以留空;如果你的私钥本身带有口令,可通过 tls.keyPassword 或相关 Secret 进行配置。路径一:配置 SASL_SSL 认证
这是一种常见的安全模型,客户端使用“用户名+密码”进行认证,并且通信信道由 TLS 加密。步骤一:为 SASL_SSL 配置 values.yaml
您需要定义一个 SASL_SSL 监听器,启用 ACL,并配置 SASL 用户及其密码。服务端会向客户端提供 TLS 证书,但客户端无需提供自己的证书来进行认证。
values.yaml 配置示例:
步骤二:部署后的 ACL 管理
部署集群后,您必须使用超级用户 (_automq) 为普通用户(如 my-user)授予权限。
- 配置管理员客户端 (
superuser.properties): 此文件允许您通过_automq的身份认证来运行管理工具。
客户端需要信任服务端的证书
ssl.truststore.certificates=/path/to/your/ca.crt步骤三:客户端配置
一个普通的应用客户端 (my-user) 将使用以下配置来连接、生产和消费消息。
使用 PEM 信任库的示例:
路径二:配置 SSL (mTLS) 认证
在此模型中,客户端通过提供一个受集群信任的 TLS 证书来进行身份验证,这被称为双向 TLS (mTLS)。步骤一:准备证书
您将需要一个证书体系:- 服务端证书: 用于 AutoMQ Broker。
- 管理员客户端证书: 一个具有特定通用名称(例如
CN=automq-admin)的证书,供被指定为超级用户的管理员使用。 - 应用客户端证书: 每个客户端应用都应有其唯一的证书(例如
CN=my-app)。
步骤二:为 mTLS 配置 values.yaml
您需要定义一个 SSL 监听器,要求客户端进行身份验证,并将管理员证书的 Principal 设置为超级用户。
values.yaml 配置示例:
步骤三:部署后的 ACL 管理
部署后,使用管理员证书为普通的应用 Principal 授予权限。-
配置管理员客户端 (
admin.properties): 此文件使用管理员证书 (CN=automq-admin) 进行身份验证。 使用 PEM 文件 (推荐):使用 JKS 文件:使用 JKS 文件: -
授予权限:
使用
kafka-acls.sh为应用 PrincipalUser:CN=my-app授予权限。
步骤四:客户端配置
一个普通的应用客户端将使用其自己唯一的证书 (CN=my-app) 进行连接。
使用 PEM 文件 (推荐):