FrankenPHP在Kubernetes中不能复用传统PHP-FPM探针配置，因其PHP worker懒加载，依赖框架初始化的健康路由（如/api/health）易返回500；而原生/healthz端点由Caddy直接响应、不触发PHP执行，响应快且无副作用，故必须使用该路径并合理设置超时与重试参数。
FrankenPHP 在 Kubernetes 中的探针必须用 HTTP GET，且健康端点不能依赖 PHP 初始化逻辑——否则 readiness 会反复失败，liveness 可能误杀常驻进程。
为什么不能复用传统 PHP-FPM 的探针配置
FrankenPHP 启动后立即监听 HTTP 端口（默认 :8080），但它的 PHP worker 是懒加载或按需启动的。如果你在 readinessProbe.httpGet.path 里指向一个需要框架初始化的路由（比如 /api/health），而该路由又依赖数据库连接或配置加载，就会返回 500 —— 这不是应用崩了，是探针提前撞上了未就绪的 PHP 上下文。
- FrankenPHP 自带的
/healthz端点（由 Caddy 内置提供）只检查 HTTP 服务是否存活，不触发任何 PHP 执行，响应快、无副作用 - 不要用
exec探针去调php --version或类似命令：容器内没有 shell，且 FrankenPHP 二进制不支持这种交互式校验 - TCPSocket 探针虽能通，但无法区分“端口开着”和“PHP worker 已热身”，容易在流量导入后立刻 500
readinessProbe 必须用 /healthz，且 timeoutSeconds 要设小
FrankenPHP 的 /healthz 是硬编码端点，只要 Caddy 主循环活着就返回 200。它不走 PHP 路由栈，也不 require index.php，所以最稳。
- 路径必须写成
path: /healthz，别写成/health或/ping—— 这些不是 FrankenPHP 原生支持的 -
timeoutSeconds: 1就够用：Caddy 响应这个端点通常在毫秒级，设太高反而掩盖真实卡顿 -
initialDelaySeconds至少设为10：FrankenPHP 启动要加载扩展、绑定端口、生成 TLS 证书（如果启用了的话），太快探就容易报 503 - 别把
failureThreshold设成 1：网络偶发丢包或 kubelet 短暂抖动会导致 Pod 被瞬间摘除，3是更安全的底线
livenessProbe 要谨慎，避免重启 worker 进程
FrankenPHP 的 worker 模式靠常驻内存提升性能，但 liveness 如果配得太激进，一次 GC 停顿或慢查询就可能触发重启，导致所有预热状态丢失。
立即学习“PHP免费学习笔记（深入）”；
- 仍然用
/healthz，但periodSeconds建议设为30（比 readiness 的10更宽松） -
failureThreshold必须 ≥3，且timeoutSeconds不要低于2—— 避免因单次 PHP 扩展初始化延迟被误判 - 绝对不要把 liveness 指向业务路径（如
/status），哪怕它返回 200：那个响应背后可能是刚 new 出来的 Laravel 容器，每次调都等于重跑一遍 bootstrap - 如果应用本身有内存泄漏风险，可额外加个
exec探针检查ps aux | grep frankenphp | wc -l，但前提是镜像里装了procps，否则会直接失败
Pod 启动慢时，得靠 startupProbe 拉一把
FrankenPHP 加载大型 PHP 应用（比如含 Composer autoload 和大量扩展的 Laravel）可能耗时 15–25 秒，而 readiness 默认 5 秒就开始探，结果就是 Pod 一直卡在 NotReady 状态。
- 加上
startupProbe，用和 readiness 一样的/healthz配置，但failureThreshold设高点（比如30），periodSeconds设为5，这样最多等 150 秒才放弃 - 一旦 startupProbe 成功，readiness 和 liveness 才开始工作 —— 这是防止“探针比应用还急”的唯一可靠方式
- 注意：Kubernetes v1.16+ 才支持 startupProbe，老集群得升级或改用更大的
initialDelaySeconds
最易被忽略的一点：FrankenPHP 默认监听 127.0.0.1:8080，但 kubelet 的探针是从宿主机网络命名空间发起的，必须显式加 --listen :8080（或在 Caddyfile 里写 bind :8080），否则 readiness 永远收不到响应。
