一、确认是否是健康检查导致的问题 #

这应该是最常见的诱因，毕竟你之前运行正常，近期才出现错误，大概率是健康检查配置出了问题，咱们一步步验证：

• 查看Pod的健康检查配置：执行 kubectl describe pod <你的Redis Pod名称>，找到Liveness Probe（存活探针）和Readiness Probe（就绪探针）部分。如果配置的是httpGet类型的探针（比如向Redis的6379端口发送HTTP请求），那百分百是它的问题——Redis只识别RESP协议，HTTP的POST/Host头会被它判定为跨协议攻击。
• 临时验证修改：把探针改成Redis原生命令，比如切换为exec类型，执行redis-cli ping，然后观察Pod日志。如果错误消失了，就实锤是健康检查的锅。
• 对比时间戳：看错误日志出现的间隔，和健康检查的执行频率（K8s默认存活探针每10秒执行一次）是否一致。如果频率完全匹配，也能佐证是健康检查导致的。

二、定位请求（或攻击）来源 #

如果排除了健康检查，那就需要追踪异常请求的来源：

• 从日志提取客户端IP：Redis的这条错误日志里会包含发起请求的客户端IP和端口，比如类似from 10.244.1.5:34567的内容，先把这个IP记下来。
• 在K8s集群内定位IP归属：
  • 执行kubectl get pods -o wide查看所有Pod的IP，找到匹配的Pod——可能是某个新部署的服务、监控工具，或者你的应用Pod出现了异常。
  • 如果是节点IP，登录对应的节点，用tcpdump抓包分析：tcpdump -i any host <Redis Pod的IP> and port 6379，这样能直接看到请求的内容，如果是HTTP格式的POST/Host头，一眼就能看出来。
• 查看Redis的客户端连接：
  • 用redis-cli CLIENT LIST命令列出所有当前连接的客户端，找到对应IP的条目，查看cmd字段看它执行了什么命令。
  • 临时开启慢查询日志（在redis.conf里设置slowlog-log-slower-than 0），这样能捕获所有执行的命令，方便排查异常请求。
• 排查近期变更：既然之前运行正常，想想最近有没有做过变更——比如新部署了监控工具（比如Prometheus的Exporter配置错了，用HTTP请求Redis）、更新了应用代码、修改了集群配置，这些都可能导致异常请求。

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