Exec探针的适用边界

Exec 探针的适用边界往往被低估。许多团队习惯性地为所有容器配置 httpGet 探针，却在遇到安全策略收紧或应用监听地址特殊时陷入被动。从 Kubernetes v1.34 开始，Pod Security Standards 的 Restricted 策略新增了对 httpGet.host 的限制，这恰好提供了一个重新审视探针选型的契机。Exec 探针的真正价值，体现在那些 httpGet 无法干净覆盖的场景中。

当容器内的应用只监听回环地址（127.0.0.1）时，httpGet 探针若不指定 host 字段，kubelet 会使用 Pod IP 发起探测，结果必然失败。此时如果因安全策略不能设置 host: 127.0.0.1，Exec 探针就成了最直接的替代方案。它在容器内部执行命令，自然可以访问本地回环接口，无需暴露应用到 Pod IP 层面。另一个典型的适用场景是健康检查逻辑复杂，无法通过单一 HTTP 状态码和路径表达——比如需要同时验证数据库连接池状态、缓存是否在线、以及本地文件系统是否可写。将这些判断封装为一个脚本，通过 Exec 探针执行，远比设计多层 httpGet 端点更灵活。

但 Exec 探针并非万能。它的代价是每次探测都会在容器内启动一个进程，对于高密度 Pod 集群，这种开销会叠加。如果镜像中没有 curl、wget 或自定义健康检查脚本，就需要额外构建镜像层。此外，Exec 探针的退出码判断逻辑较为简单：0 表示成功，非 0 表示失败。如果你的应用健康检查需要区分“暂时不可用”（应触发就绪探针失败）和“彻底崩溃”（应触发存活探针失败），Exec 探针无法直接表达这种差异，需要脚本内部做额外处理并通过不同退出码区分。

更合理的做法是建立一套选择标准：当健康检查逻辑简单且应用监听 0.0.0.0 或 Pod IP 时，优先使用不带 host 字段的 httpGet 探针；当应用只绑定回环地址、检查逻辑复杂、或需要绕过 SSRF 风险路径时，转向 Exec 探针；对于端口连通性验证且无需关心 HTTP 路径的场景，tcpSocket 探针的资源消耗更低。生命周期回调的选型逻辑类似——preStop 若需调用本地管理端点优雅下线，改用 Exec 回调比在 httpGet 中硬编码 host 更安全，也更容易通过策略审计。

最终判断 Exec 探针是否适用的边界，取决于三个因素：容器内工具的可用性、探测频率带来的资源开销，以及健康检查逻辑的复杂程度。在这条边界内，Exec 探针是安全策略合规与功能完备性之间的可靠桥梁，而不是退而求其次的妥协方案。