Kubernetes 探针同时写 httpGet 和 exec 被拒绝：选择一个 handler

在同一个 livenessProbe 或 readinessProbe 里同时配置 httpGet 和 exec，提交时出现 Forbidden: may not specify more than 1 handler type。这属于探针配置验证失败，应用尚未因此获得一套“两个检查都执行”的探针。

一个探针只能选择一种检查 handler。需要 HTTP 状态和自定义检查共同决定结果时，应把判断组合到一个健康接口或一个 exec 检查中；如果两项分别衡量能否接流量和是否需要重启，可以按用途配置不同类型的探针。

同一个探针只能选择一项检查

错误配置示例是把下面两个键同时放在同一个探针下：

livenessProbe:
  httpGet:
    path: /ping
    port: 9099
  exec:
    command: ["/opt/app/verify-correctness.sh"]

不能靠延长超时、重复 apply 或把两个键调换顺序修复。应在管理该工作负载的配置中删除不采用的 handler，并保存旧配置以便恢复。使用 Helm 或 Operator 时，要修改它们实际生成模板的入口，避免手工修补后再次被覆盖。

两项必须同时成功，统一返回检查结果

能修改应用时，可以让健康接口汇总需要的检查，仅在所有必要条件满足时返回成功状态。此时保留一个 httpGet。接口应快速、无写入副作用，不能把临时的外部依赖中断直接等同于应用必须重启。

暂时不能修改接口，也可以使用一个 exec 检查脚本。下面仅是组合方式示例，假设镜像已经提供 /bin/sh、curl 和该校验脚本，端口与路径符合应用实际配置：

readinessProbe:
  exec:
    command:
      - /bin/sh
      - -c
      - >-
        curl --silent --show-error --fail --max-time 2
        http://127.0.0.1:9099/ping >/dev/null || exit 1;
        exec /opt/app/verify-correctness.sh
  timeoutSeconds: 5

curl 的连接错误或被 --fail 判为失败的 HTTP 响应使检查返回失败，只有它成功后才执行第二项，最后使用校验脚本的退出状态。这里采用 curl 的成功判定；若应用要求严格的某个状态码，应在脚本中明确比较，而非假定所有正常返回都符合业务要求。示例没有要求跟随重定向。

exec 不会自动解释 shell 运算符，因此示例显式调用 /bin/sh。镜像缺少 shell、curl 或脚本时，这个替代方案不能直接使用；应调整镜像构建或采用已有的健康接口。两项总耗时要小于探针的整体超时，第二项也必须有可控的执行时间，不能因 curl 有超时就认为整个脚本不会阻塞。

存活和就绪分开，是不同的故障处理

readiness 失败会让 Pod 不再作为正常就绪后端接收流量，容器仍可继续运行。liveness 连续失败达到阈值则触发容器重启。这两者不能只是为了绕开多 handler 限制而随意互换。

例如外部数据库短时不可达，但重启应用不能修复数据库，可以据业务设计影响就绪状态；用于 liveness 的条件则应能判断应用自身是否需要重启。启动较慢还要单独考虑启动探针及阈值，不能把启动等待压缩为持续的重启循环。

修改探针会改变 Pod 模板并触发相应更新，先评估副本和可用性，保留能恢复的部署配置。验收先确认提交不再报 handler 验证错误，再检查正常状态、各项失败状态是否得到预期退出码，以及就绪变化和重启行为是否符合所选探针的用途。配置被接受，只证明结构正确，不能证明业务检查已经有效。