Redis哨兵部署模式下的IP地址映射_在云环境中配置sentinel announce-ip确保通信

哨兵启动后找不到主从节点的根本原因

问题的核心原因，通常是哨兵自动广播的 announce-ip 配置不当。该配置默认使用内网地址（例如 172.18.0.3），在 Docker、云主机或 NAT 网络环境中，此地址对外部不可达。因此，必须手动将 sentinel announce-ip 和 announce-port 配置为外部可访问的 IP 地址和端口，并同步检查 bind 设置、防火墙及安全组规则。

哨兵为何无法发现主节点或从节点？

根本原因在于：在容器、云环境或 NAT 网络中，哨兵自动发现的 sentinel announce-ip 通常是内网地址。其他哨兵或客户端尝试使用该地址进行连接时，将无法建立通信。这并非配置错误，而是 Redis 哨兵默认使用本机 bind 接口的 IP 进行“自我介绍”，该 IP 在云环境中对外部网络而言不可达。

必须显式配置 sentinel announce-ip 与 sentinel announce-port

关键点在于：若部署环境涉及 Docker、Kubernetes、云服务商的 VPC，或任何包含 NAT、安全组的网络，则必须手动指定一个对外可访问的地址。否则，哨兵之间交换的节点地址信息将全部错误，导致故障转移失败，客户端也无法获取正确的主节点信息。

• sentinel announce-ip：此处应填写客户端及其他哨兵能够直接通过 TCP 连接的 IP 地址。例如公网弹性 IP、负载均衡器背后的私有网络 VIP，或在 Kubernetes 中配合 Headless Service 使用的 ClusterIP。
• sentinel announce-port：此端口需与哨兵实际监听的端口保持一致（默认为 26379）。若进行了端口映射（例如在 Docker 中使用 -p 26380:26379），则此处应填写映射后的端口 26380。
• 配置方式：这两项配置必须写入哨兵的配置文件中，或在启动前通过 redis-sentinel /path/to/sentinel.conf 命令设置。需注意，运行时使用 CONFIG SET 命令无法修改这些配置。

常见错误场景与验证方法

即使配置了 announce-ip，仍可能因以下原因导致配置“失效”：

• 绑定地址限制：若配置文件中设置了 bind 127.0.0.1，但未开放对外网接口的监听，哨兵进程将无法接收其他节点的消息。解决方案是添加 bind 0.0.0.0 或指定具体的网卡 IP。
• 网络策略未放行：需检查云平台安全组或服务器防火墙是否放行了 sentinel announce-port。注意，此处是哨兵端口，而非 Redis 服务端口。TCP 握手失败往往源于此。
• 如何验证：执行 SENTINEL MASTER mymaster 命令，检查返回结果中的 ip 字段是否为预期的对外地址。随后，使用 telnet <该ip> 手动测试连通性，这是最直接的验证方式。
• Docker 网络误区：在 Docker 环境中，误将 localhost 或 127.0.0.1 作为 announce-ip。需注意容器间网络隔离，彼此无法访问对方的 localhost。

不同环境下的典型配置示例

以下是一个三节点哨兵的配置示例（假设主节点 mymaster 运行于 10.0.1.10:6379）：

port 26379
dir "/tmp"
sentinel monitor mymaster 10.0.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
sentinel announce-ip 47.98.123.45   # ← 此处填写公网 IP 或负载均衡后的真实服务 IP
sentinel announce-port 26379
bind 0.0.0.0
protected-mode no

若在 Kubernetes 中，采用 Headless Service 配合 StatefulSet 部署，可将 announce-ip 设置为 Pod 的 DNS 名称（例如 sentinel-0.sentinel-headless.default.svc.cluster.local）。但此方式的前提是客户端及所有哨兵均支持 DNS 解析，并对解析超时具备足够的容忍度。实际上，更稳妥的方案是配合 hostNetwork: true，或使用 NodePort 服务并注入 status.hostIP。

归根结底，真正的难点并非多写几行配置，而是在配置修改后，是否实际执行 telnet 命令验证连通性。这一步验证是避免后续所有问题的关键。