使用go-redis NewClusterClient连接K8s RedisCluster遇解析错误

核心原因 #

出现Dial tcp: look ?: no such host错误，本质是go-redis自动发现集群节点时，拿到了格式无效的节点地址。当你用NewClusterClient或多节点的NewUniversalClient时，库会先连接你指定的节点，然后发送CLUSTER NODES命令获取整个集群的节点列表，若列表中存在主机名/IP为空、端口缺失或格式错误的节点，就会被解析成?:这种无效地址，进而触发解析失败。

排查步骤 #

1. 检查集群节点的实际地址
   用redis-cli连接任意一个集群节点，执行命令：

   CLUSTER NODES
   

   查看返回结果里的每个节点地址（每行的第二个字段），确认是否存在空值、格式错误（比如只有端口没有IP，或者IP为空）的情况。

2. 确认Redis Operator的advertise配置
   多数Redis Operator部署集群时，需要配置节点的advertise address（对外暴露的地址）。如果这个配置缺失或错误（比如设置成了localhost、空值，或者K8s Pod内部的临时地址但客户端无法解析），Redis节点会把错误的地址汇报给客户端，导致go-redis拿到无效地址。

解决方案 #

1. 修复Redis集群的节点advertise地址
   调整Redis Operator的部署配置，确保每个节点的advertise地址设置为客户端可访问的IP或域名（比如你在Addrs里指定的那些节点IP）。不同Operator的配置字段不同，比如常见的redisCluster.spec.cluster.advertiseAddresses或类似字段，具体参考你使用的Operator文档。

2. 临时规避：关闭go-redis的自动节点发现（不推荐生产用）
   如果你需要临时验证，可以在ClusterOptions里添加DisableRedirects: true，同时手动指定所有集群节点的地址：

   rdb := redis.NewClusterClient(&redis.ClusterOptions{
       Addrs: []string{"10.216.11.150:6379", "10.216.15.178:6379", "10.216.12.115:6379", /* 所有主从节点地址 */},
       TLSConfig: &tls.Config{
           InsecureSkipVerify: true,
       },
       DisableRedirects: true,
   })
   

   注意：这种方式会绕过集群的自动路由，仅适合临时测试，生产环境必须修复节点的advertise地址。

3. 检查TLS配置兼容性
   如果你启用了TLS，确认Redis集群的所有节点都配置了正确的TLS监听，且advertise地址是TLS可访问的。部分情况下，节点汇报的是非TLS地址，但客户端用TLS连接，也可能导致地址解析异常。

内容的提问来源于stack exchange，提问作者Barrow Kwan