Eine Liveness, die PHP während OPcache tötete
Der Docker-Healthcheck wurde Liveness. Der erste Request kompilierte LaraBoom. Kubelet schickte SIGKILL. Die Replica wurde nie Ready.
Die App zog von Compose auf einem VPS nach Kubernetes. Der Dockerfile-Healthcheck curlte /. Dieser Check wurde Liveness. Period 10s, timeout 1s, failureThreshold 3. php-fpm band in zwei Sekunden. Der erste echte Request kompilierte den LaraBoom-Host in OPcache und brauchte acht.
Kubelet tötete den Pod. Der nächste machte dasselbe. nginx im Mesh lieferte 502. Der Deploy sah in CI gesund aus, weil das Image baute. Der Service hatte keine Ready-Endpoints.
Das Problem war ein Docker-Healthcheck, der während OPcache-Warmup zur Liveness wurde. Besucher trafen 502 in einem Crash Loop. Ich brauchte startupProbe auf /up, Liveness nach Warmup und Readiness auf nginx, nicht auf einer Route, die Eloquent bootet.
startupProbe, dann live
startupProbe trifft /up alle fünf Sekunden, failureThreshold 24. Liveness danach. Readiness sitzt auf nginx, nicht auf einer Route, die Eloquent bootet. Rolling Update hält einen Ready-php-Pod. SIGTERM draint Worker weiter wie in Compose.
Was auf Compose blieb
Diese Site läuft weiter Compose. Der Cluster war ein anderer Host. Healthcheck in Liveness zu kopieren ist der billigste Weg, Kubernetes schlechter als Docker aussehen zu lassen. Die Probe-Datei ist kein Port-Check. Sie ist eine Aussage über OPcache und FPM.
Was ich daraus mitnehme
Prozess hört zu ist nicht Request ready. Acht Sekunden Compile sehen wie ein Crash aus, wenn Liveness eine Sekunde ist.
startupProbe besitzt Warmup. Liveness danach. Readiness am Proxy, nicht am Eloquent-Boot.
CI grün beim Image-Build ist kein Ready-Service. Endpoints sind der Check, der zählt.