M1 Mac 构建的镜像为何在 K8s 集群里报错 exec format error
很多刚接触容器化部署的新同学可能会遇到这个情况：本地用 Apple Silicon 的 Mac 跑得顺风顺水，结果镜像往生产环境一推，Pod 直接进入
下一篇
开发者正在失去对代码的掌控感吗 →
CrashLoopBackOff 状态。最让人头疼的是，kubectl logs 报错极其简短，只有一行：exec /app/server: exec format error这种情况通常不是权限或代码逻辑问题，而是典型的架构不匹配。我们在本地开发时，Docker 默认会构建适配 arm64 架构的镜像，但如果公司的集群节点是基于 Intel 或 AMD 的 amd64 架构，内核在执行二进制文件时就会因为指令集对不上而罢工。
我建议大家在遇到这类问题时，先通过以下命令对比一下构建镜像与目标节点的架构：
# 检查本地镜像的架构
docker image inspect myimage:tag --format '{{.Architecture}}'检查 K8s 节点的实际架构
kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.architecture}'如果发现一个是 arm64 而另一个是 amd64，那就是问题的根源。为了避免这种“环境假设”与“运行契约”不一致导致的翻车，我们现在在 CI/CD 流程中会通过 buildx 来强制指定平台。如果你只需要构建适配生产环境的镜像，可以直接在构建指令中加入 --platform 参数：
# 显式指定构建 amd64 架构的镜像
docker buildx build --platform linux/amd64 -t registry/myimage:tag --push .对于新手来说，理解“容器化”并不代表环境可以完全无视硬件差异，明确构建时的架构参数，能帮你省掉很多排查时间。
