Redis Pub/Sub在Kubernetes中不能用ClusterIP Service，因其随机负载均衡会导致客户端连接不同Pod，而Pub/Sub消息仅在发布节点的本地订阅者间投递，造成消息丢失；必须使用Headless Service配合StatefulSet固定域名实现确定性连接。
Redis 发布订阅（Pub/Sub）本身不依赖集群拓扑，但要在 Kubernetes 中稳定运行，关键不是“让 Pub/Sub 工作”，而是确保所有订阅者能可靠连接到同一个 Redis 实例（或同一组实例），且连接地址不因 Pod 重建而失效。直接用 Service 做负载均衡反而会破坏 Pub/Sub 语义——因为不同客户端可能被调度到不同后端，导致消息丢失或重复消费。
为什么不能用普通 ClusterIP Service 做 Redis Pub/Sub 的服务发现
Pub/Sub 是基于 TCP 长连接的单向通道，Redis 不在服务端做消息广播或路由；它只把收到的 PUBLISH 消息原样推给所有当前连接到**该节点**的 SUBSCRIBE 客户端。如果前端挂一个 ClusterIP Service，kube-proxy 的随机转发会让客户端连到任意一个 Pod，而你无法控制哪些客户端落在哪个实例上。结果就是：同一频道的消息只在部分客户端可见。
- 客户端 A 连到
redis-0并SUBSCRIBE ch1 - 客户端 B 连到
redis-1并SUBSCRIBE ch1 - 客户端 C 向
redis-2发送PUBLISH ch1 hello→ 只有redis-2上的订阅者能收到
除非你强制所有客户端都连同一个 Pod（比如固定用 redis-0.redis-headless.default.svc.cluster.local:6379），否则 Pub/Sub 在多副本下天然不可靠。
Headless Service + 显式 DNS 名称是唯一可控方案
必须放弃“自动负载均衡”思路，改用 Headless Service 提供稳定的 DNS 记录，再由客户端显式选择目标实例。StatefulSet 的每个 Pod 都有固定域名：redis-cluster-0.redis-headless.default.svc.cluster.local，这个地址不会随 Pod 重建改变（只要 StatefulSet 名、Service 名、namespace 不变）。
- Headless Service 的
clusterIP: None是硬性要求，否则 DNS 返回的是 ClusterIP，又回到随机转发问题 - 确保
serviceName字段在 StatefulSet 中与 Headless Service 名称一致，否则 DNS 解析失败 - 客户端代码里不要写死 IP，必须用完整 FQDN，例如
redis://redis-cluster-0.redis-headless.default.svc.cluster.local:6379
示例 Headless Service 配置：
apiVersion: v1
kind: Service
metadata:
name: redis-headless
spec:
clusterIP: None
ports:
- port: 6379
targetPort: 6379
selector:
app: redis-cluster如何让多个客户端“约定”连同一个实例
没有银弹，只有业务层配合。常见做法有三种，按可靠性从高到低排列：
-
固定主节点模式：只用
redis-cluster-0作为 Pub/Sub 中心，其他节点仅用于数据分片或备份；客户端全部连它。适合轻量级通知场景 -
一致性哈希选节点：对频道名做哈希（如
hash(ch1) % 3），映射到redis-cluster-0/1/2，保证同频道总连同一台。需客户端实现，但扩展性好 - 外部协调服务：用 etcd 或 ConfigMap 记录当前“活跃 Pub/Sub 节点”，客户端启动时读取并连接。运维成本高，一般没必要
注意：redis-cli --cluster check 或 CLUSTER NODES 对 Pub/Sub 无意义——这些命令只管数据分片，不管消息投递路径。
密码和 TLS 会额外增加 DNS 解析失败风险
如果启用了 requirepass 或 TLS，DNS 解析失败时错误表现很隐晦：客户端可能卡在 CONNECT 阶段，日志只显示 Connection refused 或 timeout，而不是明确的 DNS 错误。务必验证两点：
- Pod 内执行
nslookup redis-cluster-0.redis-headless.default.svc.cluster.local能返回对应 Pod IP - Pod 内执行
redis-cli -h redis-cluster-0.redis-headless.default.svc.cluster.local -p 6379 ping能通且返回PONG
最容易被忽略的是：Kubernetes 的 CoreDNS 默认不缓存 NXDOMAIN 响应，如果 Service 名写错（比如 redis-headlss 拼错），客户端重试时可能反复触发完整 DNS 查询链路，表现为间歇性连接失败。
