Asked by Samuel Okafor · 1.2K views · 3 replies
Built and ran the image on my laptop, works. Pushed it, deployed, and the pod restarts forever. The logs are one line:
exec /usr/local/bin/docker-entrypoint.sh: exec format errorNothing changed in the Dockerfile between the version that worked and this one. The cluster is a small k3s node on a VPS.
exec format error is the kernel saying the binary is not for this CPU. It is almost always an architecture mismatch: you built on an Apple Silicon machine, so docker build produced linux/arm64, and your VPS is linux/amd64.
It runs on your laptop because the image matches your laptop. That is the whole trap — the thing that makes it work locally is the thing that breaks it remotely.
Build for the target explicitly:
docker buildx build --platform linux/amd64 -t registry/app:v1 . --pushCheck what you actually pushed before redeploying:
docker buildx imagetools inspect registry/app:v1You want to see linux/amd64 in there. If you build on that machine regularly, put the --platform flag in whatever script does the build — this comes back every single time somebody builds by hand.
That was exactly it — imagetools inspect said arm64. Rebuilt with the platform flag and it came up first try. I would never have got there from the error message.
One more for the list, since it produces the same CrashLoopBackOff with a completely different cause: a fixed tag plus the default pull policy.
Kubernetes defaults imagePullPolicy to IfNotPresent for any tag other than latest. If you re-push :v1 in place and restart, the node happily re-uses its cached :v1 and your new code never runs — while the rollout reports success. Set it explicitly:
imagePullPolicy: AlwaysThen confirm which image the pod is on rather than trusting the rollout:
kubectl get pod -l app=yours -o jsonpath='{.items[*].status.containerStatuses[*].imageID}'