RabbitMQ Pod网络异常导致节点无法通信

Question

在Kubernetes环境中，RabbitMQ集群常因Pod网络异常导致节点间无法通信，典型表现为`net_ticktime`超时、`epmd`注册失败或`rabbitmqctl cluster_status`显示部分节点为`{disc,down}`。常见根因包括：CNI插件配置错误（如Calico NetworkPolicy误拦截Erlang分布式端口4369/5672/25672）、Pod跨节点通信时iptables规则丢失、CoreDNS解析异常导致节点主机名无法反向解析（Erlang依赖FQDN通信）、或Service Mesh（如Istio）sidecar劫持流量却未放行Erlang内部通信端口。此外，若使用HostNetwork或自定义hostAliases但未同步更新所有Pod的`/etc/hosts`，也会引发节点发现失败。此类问题通常无明显日志报错，仅表现为集群分裂、队列同步停滞或镜像队列无法选举leader。需结合`tcpdump`抓包、`nslookup`验证DNS、`erl -name test@ -setcookie … -remsh`手动连通性测试进行综合诊断。

Answer 1

```html

一、现象层：典型故障表征与可观测性缺口

• net_ticktime 超时（默认60秒）：Erlang VM持续报告 net_kernel: tick failure ，节点被强制标记为 down；
• epmd 注册失败：Pod内执行 epmd -names 返回空或仅本地节点，表明4369端口未被正确监听/可达；
• rabbitmqctl cluster_status 显示 {disc,down} 或 {ram,down}，且 running_nodes 缺失跨节点条目；
• 无ERROR级日志：RabbitMQ日志中罕见堆栈，仅见WARN如 Could not contact node [e-mail]；
• 镜像队列停滞：Policy 配置生效但 Sync 状态卡在 unsynced，leader选举不触发。

二、协议层：Erlang分布式通信的隐式约束

RabbitMQ集群本质是Erlang分布式系统，其通信依赖三大刚性机制：

组件	端口	用途	关键约束
epmd	4369/TCP	Erlang节点名注册与发现	必须FQDN可解析+双向连通，不可被iptables/NP拦截
Node Distribution	25672/TCP（动态范围）	节点间RPC、消息同步、Mnesia复制	需启用 kernel.inet_dist_listen_min/max 固定端口段
AMQP	5672/TCP	客户端连接（非集群内部通信）	Sidecar（如Istio）默认劫持，但集群通信绕过此端口

三、网络层：K8s网络平面交叉验证路径

1. DNS验证：在任意RabbitMQ Pod中执行 nslookup rabbitmq-0.rabbitmq-headless.default.svc.cluster.local 及反向解析 nslookup <pod-ip>；
2. 端口连通性：使用 nc -vz rabbitmq-1.rabbitmq-headless.default.svc.cluster.local 4369 测试各节点间4369/25672；
3. iptables检查：进入node节点，运行 iptables -t filter -L KUBE-FIREWALL -n 确认无DROP规则误伤Erlang端口；
4. Calico NetworkPolicy：检查是否定义了 port: 4369 的 egress 规则，或存在 applyOnForward: true 导致跨节点流量被阻断。

四、架构层：Service Mesh与HostNetwork冲突模式

当启用Istio时，需显式豁免Erlang通信流量。以下为Envoy配置核心片段：

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: rabbitmq-sidecar
spec:
  workloadSelector:
    labels:
      app: rabbitmq
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY
  egress:
  - port:
      number: 4369
      protocol: TCP
      name: epmd
    hosts: ["*"]
  - port:
      number: 25672
      protocol: TCP
      name: dist
    hosts: ["*"]

五、诊断层：三位一体验证流程图

graph TD A[集群异常：{disc,down}] --> B{DNS是否正常？} B -- 否 --> C[修正CoreDNS /etc/hosts / headless Service] B -- 是 --> D{4369端口互通？} D -- 否 --> E[检查CNI NP / iptables / hostNetwork冲突] D -- 是 --> F{25672端口互通？} F -- 否 --> G[确认inet_dist_listen_min/max + Sidecar豁免] F -- 是 --> H[手动Erlang remsh测试：
erl -name [e-mail] -setcookie ABC -remsh rabbit@rabbitmq-1] H --> I[成功：集群逻辑恢复
失败：深入抓包分析]

六、根治层：生产就绪配置清单

• Headless Service必须启用 publishNotReadyAddresses: true，确保Pod IP在启动早期即注册DNS；
• RabbitMQ StatefulSet中强制设置 hostname 与 subdomain 匹配FQDN格式（如 rabbitmq-0.rabbitmq-headless）；
• 通过 initContainer 自动注入 /etc/hosts 条目，规避hostAliases同步延迟；
• 在RabbitMQ配置中显式声明：
  cluster_formation.k8s.host = kubernetes.default.svc.cluster.local
cluster_formation.k8s.address_type = hostname；
• 启用 net_ticktime = 120（谨慎！仅用于临时缓解，非替代网络修复）。

```