Redis发布订阅在K8s中不能直接用ClusterIP Service，因其长连接+服务端主动推送模型与kube-proxy无状态转发不兼容，易导致消息中断；必须使用Headless Service配合StatefulSet、publishNotReadyAddresses和健康探针实现稳定Pod发现。
Redis发布订阅在K8s里为什么不能直接用ClusterIP Service？
因为Redis的PUB/SUB是长连接+服务端主动推送模型，客户端一旦通过SUBSCRIBE建立连接，Redis会持续向该TCP连接写入消息；而Kubernetes默认的ClusterIP Service背后是kube-proxy的iptables/ipvs转发，它不感知应用层连接状态——连接空闲超时、连接被中间设备（如云厂商SLB、NodePort SNAT）中断、或Pod重建后旧连接未清理，都会导致客户端收不到新消息。
常见错误现象：redis-cli SUBSCRIBE channel1能连上、能收到前几条，之后就静默断收；或者K8s滚动更新Redis Pod后，所有订阅客户端卡死。
- 必须使用
Headless Service（即clusterIP: None），让客户端直连Pod IP，绕过kube-proxy的无状态转发 - 若需跨Namespace或外部访问，应通过
ExternalIPs或LoadBalancer类型Service暴露，且确保底层云厂商负载均衡器支持TCP长连接保活（如AWS NLB、阿里云CLB的TCP监听） - 禁用
sessionAffinity: ClientIP——它对PUB/SUB无效，反而可能把多个SUB连接打到同一Pod引发单点压力
如何配置Headless Service并确保Pod可被稳定发现？
关键不是“暴露端口”，而是让客户端能拿到**稳定、可路由的Pod网络地址**。Redis PUB/SUB客户端（比如Python的redis-py）需要显式连接某个Pod的IP+端口，不能依赖Service DNS轮询。
实操要点：
- StatefulSet是必须的：给每个Redis实例固定身份（
redis-0.redis-headless.default.svc.cluster.local），避免Deployment下Pod名随机导致DNS解析失败 - Headless Service定义中必须设置
publishNotReadyAddresses: true，否则Pod启动中（readiness probe未通过）时DNS记录为空，客户端连接会失败 - Pod必须配置
readinessProbe，但探针路径不能是INFO或PING——它们不反映SUB连接能力；推荐用redis-cli --raw -h $(hostname -i) -p 6379 PING，确保TCP可达且Redis进程响应
apiVersion: v1
kind: Service
metadata:
name: redis-headless
spec:
clusterIP: None
publishNotReadyAddresses: true
ports:
- port: 6379
targetPort: 6379
selector:
app: redis云厂商LoadBalancer暴露Redis端口要注意哪些TCP层参数？
当用type: LoadBalancer对外暴露6379端口时，真正决定PUB/SUB是否可靠的是**四层负载均衡器的TCP连接管理策略**，不是K8s配置本身。
典型坑点：
- AWS NLB默认空闲超时是3500秒，但某些客户端（如老版本Jedis）心跳间隔>3600秒 → 连接被NLB静默关闭 → 消息丢失。解决：调小NLB
idle_timeout至60秒，同时客户端启用setSoKeepAlive(true) - 阿里云CLB的TCP监听默认开启“连接空闲释放”，必须手动关闭，否则SUB连接在无消息时段被强制断开
- 禁止在LoadBalancer前加TLS终止（即不要用HTTPS监听转6379）——Redis PUB/SUB协议不走HTTP，加TLS代理会导致协议错乱
客户端连接逻辑怎么适配K8s DNS与故障转移？
不能硬编码单个Pod IP，也不能只靠Service DNS做轮询——PUB/SUB连接必须绑定到一个确定的Redis实例，直到它宕机；而K8s里Pod IP会变，所以客户端要自己实现服务发现+重连。
建议做法：
- 用DNS SRV记录（需配合CoreDNS插件）查
_redis._tcp.redis-headless.default.svc.cluster.local，获取全部Pod A记录和端口，按健康状态选一个建立SUB连接 - 监听
redis-py的ConnectionError和TimeoutError，捕获后重新DNS解析+重连，而不是依赖连接池自动恢复（PUB/SUB连接池不可复用） - 避免在客户端做“多播式SUB”（即同时连多个Redis Pod并SUB同一channel）——Redis不保证跨实例消息顺序，且会重复投递
最易被忽略的一点：Redis自身没有内置集群模式下的PUB/SUB广播机制。Sentinel或Redis Cluster中，SUBSCRIBE只作用于当前连接的节点，其他分片的消息不会自动转发。真要跨分片广播，得靠客户端自己在多个节点上分别SUB，再合并处理——这已经超出K8s部署范畴，属于业务架构取舍了。
