Kubernetes存活探针遇connection reset by peer未重启Pod问题咨询

这是Kubernetes存活探针的预期行为吗？ #

不是。按照Kubernetes的设计逻辑，HTTP类型的存活探针会将以下场景判定为失败：

• 无法建立TCP连接（比如connection reset by peer、连接被拒绝这类情况）
• 探针请求超时
• 返回非2xx/3xx范围内的HTTP状态码

当连续失败次数达到failureThreshold设定的值时，kubelet必须触发Pod重启。你遇到的故障Pod持续5小时未重启的情况不符合预期，可能的诱因包括：

• 虽然当前配置的periodSeconds=30+failureThreshold=5只需150秒就该触发重启，但如果kubelet未正确计数探针失败次数（比如日志中存在探针执行异常），会导致重启逻辑不触发，建议检查Pod所在节点的kubelet日志排查问题。
• 你的探针timeoutSeconds=30与periodSeconds=30配置完全相同，可能导致连接重置信号还未被kubelet识别为超时或失败，下一次探针就已开始，干扰失败计数逻辑。

如何调整配置让集群重启不接受连接的Pod？ #

可以通过以下几种方式优化配置，确保连接异常的Pod被及时重启：

1. 优化HTTP探针参数 #

缩短检查间隔并调整超时时间，让失败判定更灵敏：

livenessProbe:
  failureThreshold: 3
  httpGet:
    path: /q/health/live
    port: http
    scheme: HTTP
  periodSeconds: 10  # 缩短检查间隔至10秒，更快发现异常
  successThreshold: 1
  timeoutSeconds: 5   # 超时时间短于检查间隔，避免逻辑重叠
  initialDelaySeconds: 30

2. 改用TCP Socket探针 #

如果核心需求是验证Pod是否能正常接受连接，tcpSocket探针比HTTP探针更直接，它会直接检测端口连通性，connection reset by peer这类连接异常会被立即判定为失败：

livenessProbe:
  failureThreshold: 3
  tcpSocket:
    port: http
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 5
  initialDelaySeconds: 30

3. 排查kubelet运行状态 #

登录Pod所在的节点，查看kubelet日志（通常路径为/var/log/kubelet.log），确认探针执行过程中是否存在报错，比如节点网络策略阻止了探针请求、kubelet权限不足无法发起探针等，这些问题都可能导致重启逻辑失效。

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