- Shipped
- 19 Agosti 2026, 07:36 UTC
- Author
- Kamo
- Commit
- edcc22f
The 013faf1 deploy failed on `exceeded its progress deadline` while the rollout itself was fine — the pod came up healthy about 90s in, and prod has been serving that build since. Three separate things made a working rollout report as a failure. progressDeadlineSeconds was 60. containerd rejected the image layer four times with a digest mismatch — expecting fec4855e and receiving 1355bed4, then 9e55904e, a DIFFERENT wrong digest each attempt, which is corruption in transit rather than a bad blob in the registry (a bad blob fails identically every time). It backed off, re-pulled, and landed a clean ~100 MB copy in 3.0s on the fourth try. 60s cannot absorb that. Raised to Kubernetes' own default of 600. The deploy also pulled twice per push. `apply -f k8s/deployment.yaml` set the image to the :latest placeholder and the very next step set it to the commit SHA, so there were two image changes, two rollouts and two ~100 MB pulls — over a link that intermittently corrupts large transfers, double the exposure for no benefit. The apply step now substitutes $IMAGE, so `set image` is idempotent and one rollout happens. Applying manifests still precedes rollout status, so the new deadline governs the deploy that introduces it. And there was no probe of any kind, which quietly voided the `maxUnavailable: 0` promise above it: with nothing to test, the new pod counted as available the moment the container process started — seconds before Next was listening — so every deploy had a window where the only pod behind the Service could not serve. Readiness now polls /en, which is prerendered and needs no backend. Added CPU and memory requests too (the pod idles at 16m/66Mi); no limits, because a limit here would be a guess that converts a traffic spike into an OOMKill. The transfer corruption itself is not fixed here and is not a marketing problem — it is the k1m1 registry link, previously localised to eno49 and thought resolved on 2026-08-08. This only stops it from failing deploys that actually succeed.