是否可在Kubernetes中实现带内容校验的custom health check？

原生Kubernetes的HTTP类型健康探针（httpGet）仅会对返回的HTTP状态码做校验，默认2xx、3xx类响应即判定健康，无法直接识别响应体内容。要实现「HTTP返回内容包含指定特征字符串则判定健康检查失败」的需求，可通过以下三种落地路径实现：

路径1：Exec探针结合容器内命令校验 #

借助Exec探针的命令退出码判定逻辑实现判断——K8s探针规则中，执行命令的退出码为0即代表健康检查通过，非0值即判定检查失败。在命令里封装HTTP请求发起、响应内容匹配的完整逻辑即可满足需求。
具体配置示例：

livenessProbe:
  exec:
    command:
    - sh
    - -c
    # 替换为实际要请求的健康接口地址、要匹配的失败特征字符串
    - resp_content=$(curl -s --max-time 2 http://127.0.0.1:8080/health); if echo "$resp_content" | grep -q "SERVICE_UNAVAILABLE"; then exit 1; fi
  initialDelaySeconds: 10
  periodSeconds: 15
  timeoutSeconds: 3

使用注意：

• 该方案要求业务容器镜像内提前预装curl、grep这类基础命令行工具，精简的无shell Distroless镜像无法使用该方式
• 可根据需求灵活调整匹配规则，比如替换为更复杂的正则匹配、排除正常内容的判断逻辑

路径2：Sidecar 代理中转实现内容校验 #

如果业务容器是无命令行工具的精简镜像，可在同一Pod内部署一个轻量代理容器，由代理承接所有K8s探针的健康检查请求：

• 代理收到探针请求后，转发请求到业务容器的真实健康接口
• 代理获取业务返回的响应内容后，校验是否包含指定的失败特征字符串：如果匹配到特征，直接向探针返回503类非成功状态码；如果未匹配到，直接透传业务返回的正常2xx响应
  这种模式下，K8s探针依然可以使用原生的httpGet类型，只需要把请求目标指向sidecar的代理端口即可，无需改动探针配置逻辑。

路径3：应用层原生改造健康接口 #

从长期运维的稳定性角度，最可靠的方案是在业务应用的健康检查接口代码中直接内置判断逻辑：

• 应用在生成健康接口的响应前，先完成自身状态的全量校验，如果检测到对应故障场景（即原先需要匹配的特征字符串对应的异常状态），直接向调用方返回5xx类的非成功HTTP状态码
• 该方案没有额外的组件依赖、无跨网络跳转的开销，判断逻辑完全在应用内部完成，不会出现误判，探针直接使用原生httpGet配置即可正常工作

落地注意事项 #

• 特征字符串的匹配规则要选择高辨识度的内容，避免和健康接口正常返回的内容重合，防止出现健康状态误判
• 配置探针参数时要设置合理的超时阈值，避免命令执行、代理转发的耗时超出探针超时时间导致误报
• 不要将内容校验逻辑绑定到通用业务接口上，所有健康判断逻辑要收敛在专门的健康检查接口中，避免干扰正常业务流量的处理

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