Kubernetes部署中Docker组件启动失败（exec format error）解决方案

你遇到的standard_init_linux.go:211: exec user process caused "exec format error"，核心触发原因就是容器镜像的CPU架构和集群节点架构完全不匹配：

• 你当前部署用的docker.io/steinko/gradle-ci-cd镜像为Linux/arm64架构构建，仅能在支持ARM指令集的CPU节点上运行
• 集群配置的e2-standard-2节点属于x86_64（AMD64）架构，两者指令集不兼容，容器运行时根本无法解析执行镜像内的二进制程序，因此启动直接报错，你关于架构不匹配的判断完全准确。

路径1：适配现有x86节点，调整镜像架构 #

这是兼容性最强、改动最小的方案，不需要调整现有集群的节点配置：

• 重新构建匹配x86_64架构的镜像版本，替换原有仅支持arm64的镜像推送到镜像仓库，原有Deployment的镜像地址无需修改，拉取到对应架构的镜像后即可正常启动
• 如果需要兼顾多集群、多架构部署场景，可以直接构建同时包含linux/amd64、linux/arm64的多架构镜像清单，K8s会根据节点的实际CPU架构自动拉取匹配的镜像层，不需要为不同架构的集群维护多套独立的镜像地址

路径2：调整集群节点配置，更换ARM架构机型匹配现有镜像 #

如果希望直接使用现有arm64镜像，可以修改Pulumi的集群部署配置，将工作节点更换为GCP提供的ARM架构机型：

• 在你现有的集群配置代码中，把nodeConfig下的machineType参数从e2-standard-2替换为同计算规格的ARM机型t2a-standard-2
• 提前核对所选区域的ARM机型可用范围，同步调整集群自动缩放的节点支持规则，避免自动扩缩容时继续调度出x86架构的e2节点
• 如果配置了独立的业务工作节点池，需要同步修改节点池的机型配置——仅修改集群主节点的机型参数，不会影响实际承载业务负载的工作节点架构，容易出现配置遗漏

完成配置修改后，可以登录目标节点执行uname -m验证实际CPU架构：x86架构节点会返回x86_64，ARM架构节点会返回aarch64，确认架构完全匹配后再重新部署应用，避免因为配置遗漏再次触发架构不兼容的报错。

内容的提问来源于stack exchange，提问作者stein korsveien