Docker Desktop下用Compose部署Redis集群为何节点无法互相发现？

Question

在 Docker Desktop 中使用 Compose 部署 Redis 集群时，节点常因**网络隔离与 IP 解析失效**而无法互相发现。根本原因在于：Redis Cluster 要求各节点通过 `cluster meet ` 显式握手，且需在 `redis.conf` 中正确配置 `bind 0.0.0.0`、`protected-mode no`、`cluster-enabled yes`，以及关键的 `cluster-announce-ip`（必须设为容器在 Docker 网络中可被其他容器解析的真实 IP，而非 `127.0.0.1` 或宿主机 localhost）。Docker Desktop 的默认 bridge 网络下，容器间虽可通信，但若 `cluster-announce-ip` 错误（如误填宿主机 `127.0.0.1` 或未设置），其他节点将尝试连接不可达地址；此外，Compose 默认服务名（如 `redis-node-1`）虽可在容器内 DNS 解析，但 Redis Cluster 协议不依赖 DNS，仅认 `cluster-announce-ip:port`，导致 `CLUSTER NODES` 显示 `fail` 或 `noaddr`。典型表现：`redis-cli -c -h node1 ping` 成功，但 `CLUSTER NODES` 中多数节点状态为 `fail` 或缺失。

Answer 1

一、现象层：典型故障表征与可观测线索

运维人员执行 redis-cli -c -h redis-node-1 ping 返回 PONG，误判服务“正常”；但进一步执行 CLUSTER NODES 时，输出中大量节点标记为 fail 或 noaddr，部分节点 ID 后缀显示 0.0.0.0:6379@16379 —— 这是 cluster-announce-ip 未显式配置或解析失败的直接信号。Docker Desktop 的容器日志中频繁出现 Unable to connect to MASTER 或 connect timeout，且 docker network inspect redis-net 显示各容器 IP（如 172.28.0.2、172.28.0.3）彼此可达，却无法完成集群握手。

二、协议层：Redis Cluster 的网络语义约束

Redis Cluster 不采用服务发现机制，其节点间通信严格依赖三点硬性约定：

• 地址唯一性：每个节点必须向集群广播一个全局可路由的 IP:PORT（由 cluster-announce-ip + cluster-announce-port 决定），该地址必须能被其他所有节点 telnet 或 nc 直连；
• 非DNS依赖性：即使 redis-node-2 在容器内可 nslookup 解析，Redis Cluster 协议完全忽略 DNS 名称，仅信任 cluster-announce-ip 所声明的地址；
• 双向连通性：不仅要求节点 A 能连 B 的 cluster-announce-ip:6379，还要求 B 能反向连 A 的 cluster-announce-ip:6379（因 MEET 是异步握手，后续 FAIL 检测基于双向心跳）。

三、容器层：Docker Desktop 网络模型的隐含陷阱

Docker Desktop（WSL2 backend）默认使用 bridge 驱动创建用户自定义网络（如 redis-net），其关键特性如下表所示：

特性	表现	对 Redis Cluster 的影响
network_mode: bridge	容器拥有独立 IP（如 172.28.0.2），宿主机可访问，但 WSL2 与 Windows 主机间存在 NAT 层	若 cluster-announce-ip 设为 host.docker.internal，在 WSL2 中解析为 192.168.49.1（非容器网段），导致跨节点不可达
dns_search 自动注入	容器内 /etc/resolv.conf 包含 redis-net 域搜索路径	误导开发者以为服务名可直接用于集群通信，实则 Redis Cluster 协议不消费 DNS

四、配置层：redis.conf 中易被忽视的“生死六参数”

以下配置项缺一不可，且顺序与取值敏感：

bind 0.0.0.0                    # 允许所有接口接收客户端及集群流量
protected-mode no               # Docker 环境无外部暴露风险，必须关闭
port 6379                       # 客户端端口（固定）
cluster-enabled yes             # 启用集群模式
cluster-config-file nodes.conf  # 必须可写，建议挂载 volume
cluster-announce-ip 172.28.0.2 # ✅ 关键！必须为本容器在 redis-net 中的真实 IP
cluster-announce-port 6379      # 与 port 一致（除非启用 TLS/代理）
cluster-announce-bus-port 16379 # 必须显式设置，否则默认为 port+10000 → 16379

五、部署层：Docker Compose 的动态 IP 注入方案

静态写死 cluster-announce-ip 不可扩展。推荐使用环境变量 + 启动脚本动态注入：

# docker-compose.yml 片段
services:
  redis-node-1:
    image: redis:7.2-alpine
    command: sh -c "echo 'cluster-announce-ip $$REDIS_IP' >> /usr/local/etc/redis.conf && redis-server /usr/local/etc/redis.conf"
    environment:
      - REDIS_IP=172.28.0.2
    networks:
      redis-net:
        ipv4_address: 172.28.0.2

更健壮方案：使用 entrypoint.sh 调用 hostname -i 获取当前容器 IP 并生成配置，避免硬编码。

六、验证层：分阶段诊断流程图

graph TD A[启动所有 redis-node-x 容器] --> B{各容器内执行
ping -c1 redis-node-2} B -->|✓ 通| C[各容器内执行
redis-cli CLUSTER NODES] B -->|✗ 不通| D[检查 docker network inspect redis-net
确认 IP 分配与连通性] C -->|存在 noaddr/fail| E[检查 redis.log 是否含
“Failed to resolve cluster-announce-ip”] C -->|全为 connected| F[执行 CLUSTER MEET 手动握手] E --> G[修正 cluster-announce-ip 为容器真实 IP] F --> H[集群健康]

七、进阶层：Docker Desktop WSL2 特殊适配要点

当使用 Docker Desktop + WSL2 时，需额外注意：

• 禁止将 cluster-announce-ip 设为 host.docker.internal：该域名在 WSL2 中解析为 Hyper-V 虚拟交换机 IP（如 192.168.49.1），不在 redis-net 网段内；
• 若需从 Windows 宿主机访问集群节点，应映射 ports 并确保 cluster-announce-ip 仍设为容器内网 IP（172.28.x.x），而非 0.0.0.0；
• WSL2 默认启用 systemd，建议在 Dockerfile 中显式 ENV container docker 避免 init 冲突。

八、生产层：自动化集群初始化最佳实践

避免人工 CLUSTER MEET，使用初始化脚本：

#!/bin/sh
# init-cluster.sh
for node in redis-node-1 redis-node-2 redis-node-3; do
  for peer in redis-node-1 redis-node-2 redis-node-3; do
    [ "$node" != "$peer" ] && \
      redis-cli -h "$node" CLUSTER MEET $(getent hosts "$peer" | awk '{print $1}') 6379
  done
done

通过 depends_on + healthcheck 控制执行时机，确保所有节点 redis-server 已就绪再触发握手。

九、监控层：核心指标与告警阈值

在 Prometheus + Grafana 中应采集并告警的关键指标：

• redis_cluster_nodes_count{state="fail"} > 0 持续 60s；
• redis_cluster_known_nodes 小于预期节点数（如 6）；
• redis_connected_clients 异常激增（可能因重试握手风暴）；
• 容器网络层：container_network_receive_bytes_total{interface="eth0"} 突降至 0 —— 表明集群心跳中断。

十、演进层：面向云原生的替代架构建议

对于高可用要求严苛场景，建议渐进演进：

• 短期：采用 redis-operator（如 OT-CONTAINER-KIT）自动管理 cluster-announce-ip 和 MEET 流程；
• 中期：迁移到 StatefulSet + Headless Service，利用 Kubernetes DNS SRV 记录实现节点发现（需 Redis 7.2+ 支持 cluster-announce-hostname）；
• 长期：评估 Redis Stack 或托管服务（Azure Cache for Redis, AWS MemoryDB），规避自建集群运维复杂度。