OpenFaaS 函数Pod健康检查报超时错误但手动访问可正常响应

该问题的核心原因可分为以下4类，按出现概率从高到低排序：

• 缺省探针阈值不匹配实际场景：OpenFaaS 官方自定义 HTTP 健康检查的默认超时时间为1s，你仅配置了初始延迟参数，未调整超时阈值，只要 Quarkus 应用的健康接口响应耗时超过1s就会触发超时；部分版本的 OpenFaaS 探针默认失败阈值仅为1次，偶发的慢响应就会标记 Pod 不健康。
• 访问链路差异：手动访问健康接口一般是通过集群网关、Ingress 或直接在低负载节点执行请求，而 Kubelet 探针是从节点本地直接访问 Pod 网络命名空间，若存在 Pod 网络策略未放通 Kubelet 所在节点网段、节点高负载导致探针请求调度延迟、应用线程池满导致探针请求排队的情况，就会出现手动访问正常但探针超时的现象。
• 健康接口逻辑不合理：若 /health 接口绑定了数据库、配置中心等下游依赖的健康检查，下游依赖偶发慢响应就会拖慢接口返回速度，手动测试时刚好赶上下游响应快就会返回正常。
• 转发规则异常：你使用的自定义 quarkus-java-with-fonts 运行模板如果修改了 of-watchdog 的默认转发规则，可能出现 /health 请求未被正常转发到后端 Quarkus 服务的问题，导致请求卡住超时。

1. 执行 kubectl describe pod <故障Pod名称>，查看实际生成的 Liveness、Readiness 探针配置，确认 timeoutSeconds、failureThreshold 参数是否为默认的1s、1次。
2. 登录到故障 Pod 所在的集群节点，执行 curl -m 1 http://<PodIP>:8080/health 模拟 Kubelet 探针请求，验证是否能在1s内正常返回。
3. 查看应用运行日志，确认探针请求到达时是否存在线程阻塞、下游依赖调用超时的报错记录。
4. 检查集群网络策略、限流规则，确认是否限制了 Kubelet 所在节点网段对 Pod 8080端口的访问。

1. 补充健康检查阈值配置，在函数的 annotations 中新增以下参数，可根据实际接口响应时间调整冗余量：

com.openfaas.health.http.timeout: "5s"
com.openfaas.health.http.period: "10s"
com.openfaas.health.http.failureThreshold: "3"

如果应用初始化耗时较长，可同步将 com.openfaas.health.http.initialDelay 调整到60s。
2. 拆分健康检查逻辑：存活探针仅检查应用进程是否正常运行，不需要关联下游依赖，避免下游故障导致应用被误杀；就绪探针才加入下游依赖可用性检查逻辑。
3. 优化 Quarkus 应用启动参数，关闭不必要的启动时初始化逻辑，降低健康接口的响应耗时。
4. 检查自定义运行模板的 of-watchdog 配置，确认 /health 路径请求可正常转发到后端 Quarkus 服务，若存在转发BUG可升级 of-watchdog 到稳定版。
5. 排查节点负载情况，若存在节点资源超卖、CPU节流的问题，可调整节点资源预留配置，或迁移函数 Pod 到低负载节点。

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