Kubernetes中Keystone就绪探针连接失败求助排查

首先看你的场景：初始就绪探针报连接拒绝，但后来Pod状态变为Ready: True，同时日志显示Keystone服务已经在正常处理请求（比如POST /v3/auth/tokens返回201状态码），这说明服务最终启动成功了，初始报错大概率是服务启动延迟导致探针检测过早。

1. 就绪探针缺少初始延迟配置 #

你的就绪探针配置没有设置初始等待时间：

readinessProbe:
  tcpSocket:
    port: 5000

默认情况下，探针会在容器启动后立即开始检测（initialDelaySeconds=0），但Keystone作为OpenStack身份服务，启动时需要完成数据库初始化、配置加载等操作，这些步骤都需要时间，此时5000端口还未开始监听，自然会触发连接拒绝的报错。

修复方案：给就绪探针添加初始延迟，同时优化检测参数，让检测逻辑更贴合服务启动节奏：

readinessProbe:
  tcpSocket:
    port: 5000
  initialDelaySeconds: 30  # 等待30秒再开始第一次检测
  timeoutSeconds: 5        # 超时时间设为5秒
  periodSeconds: 10        # 每10秒检测一次
  failureThreshold: 3      # 连续失败3次才标记未就绪

2. 验证Service与Pod的连通性 #

你测试telnet 10.96.162.65 5000无响应，可以按以下步骤排查：

• 先在Pod内部确认5000端口是否正常监听：

  kubectl exec -n heat <你的keystone-pod名称> -- netstat -tulpn | grep 5000
  

  如果端口未监听，可能是Keystone的绑定配置问题——你设置了IPADDR为Pod IP，要确认Keystone是否绑定了这个IP而非仅localhost（不过探针用的是容器IP，若服务绑定了Pod IP，理论上探针应该能访问）。
• 在集群内的临时Pod中测试Service连通性（避免宿主机网络的影响）：

  kubectl run -n heat temp-busybox --image=busybox --rm -it -- telnet keystone-api 5000
  

  用Service名称访问，能直接验证Service的selector匹配、端口转发是否正常（你的Service selectorapp: keystone和Pod标签是匹配的，但实际测试更能确认问题）。

3. 日志中Heat服务警告的说明 #

日志里的Could not find service: heat警告，是因为你的环境中存在重复查询Heat服务的逻辑，虽然你手动创建了Heat服务，但这属于业务逻辑层面的日志，和就绪探针的连接问题无关，无需处理。

总结 #

最核心的问题就是就绪探针没有设置初始延迟，导致容器刚启动时就触发未就绪检测；等服务完全启动后，探针检测成功，Pod就会变为Ready状态。添加initialDelaySeconds参数就能解决初始的报错问题。

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