Kube集群RabbitMQ节点随机频繁重启、对等节点不可达问题咨询

故障根本原因 #

• 集群间TLS配置不匹配：日志显示配置了verify_peer参数但未提供CA证书，节点间TLS握手失败，导致对等节点发现全部失败，无法正常组成集群。
• 资源配置不足：配置的内存请求仅为160Mi，远低于RabbitMQ集群节点的最低运行要求，业务流量波动时极易触发内存告警，导致节点进程响应卡顿。
• 探针配置过于严格：5副本集群启动和数据同步耗时较长，现有探针的超时时间、重试阈值设置过短，节点临时繁忙时容易触发探针失败，最终K8s发送SIGTERM信号强制重启节点。
• 未显式配置K8s服务发现规则：Bitnami RabbitMQ Chart默认依赖K8s API实现对等节点发现，缺少显式配置时可能出现跨节点解析异常。

解决方案 #

1. 修复TLS配置问题 #

根据是否需要集群加密二选一配置：

• 无需集群加密的场景：在extraConfiguration中添加参数关闭证书验证：

ssl_options.verify = verify_none

• 需要集群加密的场景：生成包含CA根证书、节点证书和密钥的Secret，在values配置中开启TLS并指定对应Secret，正确配置cacertfile参数路径。

2. 调整资源配额 #

将内存配置上调到合理范围，示例配置如下：

resources:
  limits:
    cpu: 4000m
    memory: 4Gi
  requests:
    cpu: 1000m
    memory: 2Gi

可根据实际业务消息吞吐量适当调整，确保节点运行期间不会频繁触发内存/CPU限流。

3. 优化探针配置 #

放宽探针阈值避免误判，示例配置如下：

readinessProbe:
  exec:
    command:
    - /bin/bash
    - -ec
    - rabbitmq-diagnostics -q check_running && rabbitmq-diagnostics -q check_local_alarms
  failureThreshold: 5
  initialDelaySeconds: 30
  periodSeconds: 30
  successThreshold: 1
  timeoutSeconds: 30

livenessProbe:
  exec:
    command:
    - /bin/bash
    - -ec
    - rabbitmq-diagnostics -q ping
  failureThreshold: 10
  initialDelaySeconds: 300
  periodSeconds: 30
  successThreshold: 1
  timeoutSeconds: 30

4. 补充显式服务发现配置 #

在extraConfiguration中添加K8s对等发现规则，确保节点可以正常解析集群内其他节点地址：

cluster_formation.peer_discovery_backend = rabbit_peer_discovery_k8s
cluster_formation.k8s.host = kubernetes.default.svc.cluster.local
cluster_formation.k8s.address_type = hostname
cluster_formation.k8s.service_name = rabbitmq-headless
cluster_formation.k8s.namespace = jx-production

5. 检查网络策略 #

确认jx-production命名空间下的网络策略没有屏蔽RabbitMQ集群通信端口：4369（epmd服务发现）、25672（集群内部通信），允许Pod之间的这两个端口互访。

内容的提问来源于stack exchange，提问作者Amit