您好！针对您遇到的集群升级后Cloud-Config Pod存活探针超时的问题，我整理了几个实用的排查方向和建议，希望能帮您定位问题：

• 排查Pod内部及集群网络连通性
  首先确认应用本身是否正常：通过kubectl exec <您的pod名称> -- curl localhost:8080/actuator/health直接在Pod内部访问健康检查接口，如果能正常返回，说明应用本身没问题，问题大概率出在集群网络层面。可以再尝试在同一节点的其他Pod中访问该Pod的IP:8080/actuator/health，或者在节点主机上用curl <pod-ip>:8080/actuator/health测试，排查是不是CNI插件在升级后出现兼容性问题、iptables规则被覆盖，或者节点的网络策略限制了探针请求。

• 分析137错误的根源
  curl返回137通常意味着进程被SIGKILL终止，虽然您提到资源远未达阈值，但还是建议：

  • 用kubectl describe pod <您的pod名称>查看Pod事件日志，有没有进程被终止的相关记录；
  • 登录节点执行dmesg命令，检查是否有系统层面的OOM killer或者其他进程（比如节点监控组件）误杀了Pod内的应用进程。

• 核对探针配置与应用实际监听情况
  您提到deployment里的探针配置写的是http-get http://:8888/actuator/health，但实际livenessProbe配置的是8080端口，这里存在配置不一致的情况，建议确认：

  • 应用实际监听的端口：通过kubectl exec <您的pod名称> -- netstat -tulpn查看Pod内的端口监听状态，确保应用确实在8080端口提供服务；
  • 探针请求的实际响应：可以在Pod内开启应用的请求日志，查看存活探针的请求到达时，应用是否有异常处理逻辑导致超时。

• 验证K8s版本升级带来的行为变更
  K8s 1.24版本有不少重要变更，比如移除dockershim（DigitalOcean集群一般用containerd，需确认容器运行时版本与K8s的兼容性），另外存活探针的行为也可能有细微调整：

  • 可以临时调整探针参数，比如把timeoutSeconds从5秒改为10秒，failureThreshold调高到6，看看是否能缓解超时问题，验证是不是探针的容忍度不足；
  • 检查集群中kubelet的日志，查看探针执行时的具体错误信息，比如是否有请求被拦截或者超时的详细记录。

• 排查应用健康检查的隐性依赖
  虽然您已经禁用了actuator健康检查的所有组件，但有些隐性依赖可能没被完全排除，比如应用的线程池是否已满、文件句柄是否耗尽？可以在Pod内用kubectl exec <您的pod名称> -- ps aux查看应用进程的状态，或者用lsof -p <进程ID>检查文件句柄使用情况。

备注：内容来源于stack exchange，提问作者fipse