A liveness probe that killed PHP during OPcache
The Docker healthcheck became liveness. First request compiled LaraBoom. Kubelet sent SIGKILL. The replica never Ready.
The app moved from Compose on one VPS to Kubernetes. The Dockerfile healthcheck curled /. That check became liveness. Period 10s, timeout 1s, failureThreshold 3. php-fpm bound in two seconds. The first real request compiled the LaraBoom host into OPcache and took eight.
Kubelet killed the pod. The next pod did the same. nginx in the mesh returned 502. Deploy looked healthy in CI because the image built. The Service had no Ready endpoints.
The problem was a Docker healthcheck copied into liveness during OPcache warmup. Visitors hit 502 in a crash loop. I needed startupProbe on /up, liveness after warmup, and readiness on nginx, not on a route that boots Eloquent.
startupProbe, then live
startupProbe hits /up every five seconds, failureThreshold 24. Liveness starts after that. Readiness sits on nginx, not on a route that boots Eloquent. Rolling update keeps one Ready php pod. SIGTERM still drains workers the same way Compose did.
What stayed on Compose
This site still runs Compose. The cluster was another host. Copying healthcheck into liveness is the cheapest way to make Kubernetes look worse than Docker. The probe file is not a port check. It is a statement about OPcache and FPM.
What I took from this
Process listening is not request ready. Eight seconds of compile looks like a crash if liveness is one second.
startupProbe owns warmup. Liveness after that. Readiness on the proxy, not on Eloquent boot.
CI green on image build is not a Ready Service. Endpoints are the check I care about.