同一 tag 两种架构：K8s 多架构镜像的拉取错配、QEMU 模拟拖慢与 exec format error 复盘

作者苏知远

Kubernetes多架构arm64buildx镜像拉取SRE

智能体品牌：Kubernetes · 1.29.3

结论先行：「这个镜像在 arm 节点上跑得好好的，为什么到了 x86 节点就 exec format error / 冷启动慢 6 倍」——根因几乎都不是应用代码，而是 manifest list 的多架构子镜像被拉错了，或者 binfmt 模拟没注册、调度器没认架构。这篇文章从拉取链路上把三处最容易踩的坑拆开，给一份 buildx + 调度 + crictl 的可复现做法。

一、现象与背景：同一 tag，两种节点两种命运

我们的场景很典型：一个 Go + CGO（链接了平台相关的 C 库）的服务，团队里有 3 台 arm64 节点（kubernetes.io/arch=arm64，K8s 1.29.3，containerd 1.7.13）和 12 台 amd64 节点，共用一个 registry.internal/svc:v1.4.2 的 tag。

过去一个季度反复出现三类「灵异」现象：

现象 A：镜像发布后，arm 节点上 2 副本正常，但有 1 个副本被调度到了 amd64 节点，起来就 crash，kubectl describe pod 里 Last State: Exit Code: 255，containerd 日志一行 exec /svc: exec format error。重启几次后它「碰巧」被调度回 arm 节点，又好了——看起来像玄学，其实是调度没认架构。
现象 B：把镜像强拉到 amd64 节点后它居然「能跑」，但冷启动从 arm 上的 3.8s 变成 24.6s（约 6.5 倍），kubectl get pods 里 Running 但 readiness 慢到超时被杀，日志里全是 qemu-aarch64 的 trace。
现象 C：最隐蔽——arm 和 amd64 节点都拉的是同一个 tag v1.4.2，docker manifest inspect 看着也没毛病，但两个节点上 crictl images 的 digest 完全不一样（arm 是 sha256:a3f…c81，amd64 是 sha256:7d2…9e0），有人据此误判「镜像被污染了」。

C 其实是最多人被误导的一条：digest 不同是正常的，因为同一 tag 指向的是一个 manifest list，每个架构有自己的子镜像 digest。真正的问题是 A 和 B：架构没在调度层被显式约束。

二、根因：拉取链路里架构在哪一步被「选」出来

一次 kubectl apply 后，一个 Pod 的镜像要经过这样一条链：

调度器选节点（这一步不关心镜像架构，只认 nodeSelector/亲和/资源）；
kubelet 让 containerd 拉镜像——containerd 读 manifest list，按当前节点的 kubernetes.io/arch 挑子镜像；
节点上若架构匹配，直接跑；若不匹配但注册了 binfmt，就走 QEMU 模拟；若不匹配也没 binfmt，直接 exec format error。

所以三个现象对应三个失败点：

A = 调度层没约束架构。v1.4.2 是单架构 arm64 镜像（只 push 了 arm 子镜像，或干脆是裸 docker build 没走 buildx），却被调度到 amd64 节点，containerd 找不到 amd64 子镜像 → exec format error。
B = 走了 QEMU 模拟。amd64 节点上注册了 qemu-aarch64 binfmt，于是它「能」把 arm64 镜像在 x86 上跑起来，但指令翻译让启动/计算慢 5~10 倍。模拟能跑 ≠ 应该跑。
C = 正常现象被误读。manifest list 下 digest 天然按架构分裂，crictl images 看到的 digest 是「本节点实际拉的那个架构」的。

关键认知：多架构镜像的「架构选择」发生在拉取时（按节点 arch），而不是构建时或调度时。所以「调度到错误架构节点」是唯一真正的 bug 源，binfmt 只是把 bug 从「起不来」软化成「跑得慢」，掩盖了问题。

三、具体做法：buildx 构建 + 调度约束 + 拉取验证

1）构建：用 buildx 产真正的多架构镜像，并记下 manifest list digest

# 一次性准备（buildx 需要 docker 20.10+ / buildx 插件）
docker buildx create --name multiarch --driver docker-container --use

# 构建并推送多架构镜像；--platform 显式列出目标架构
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t registry.internal/svc:v1.4.3 \
  --provenance=false \
  --push .

# 验证：这是 manifest list，且包含两个架构
docker manifest inspect registry.internal/svc:v1.4.3 | grep -E 'architecture|digest'

--provenance=false 是为了避免 buildx 默认塞进 attestation，让 K8s 老版本 containerd 拉取时不报 unknown media type。构建耗时参考：单架构约 42s，双平台约 81s（约 1.9x，可接受）。

2）调度：把架构写进 nodeSelector，让「错误架构节点」在调度层就选不中

spec:
  nodeSelector:
    kubernetes.io/arch: arm64        # 只跑在 arm 节点
    # 或用更细的拓扑：
    # topology.kubernetes.io/region: cn-hangzhou
  containers:
  - name: svc
    image: registry.internal/svc:v1.4.3
    imagePullPolicy: IfNotPresent

如果镜像是真多架构（amd64+arm64 都有），反而不要写死 arch，让它跟着节点走，靠 containerd 按节点 arch 自动选子镜像——这才是多架构镜像的正确用法。写死 arch 只适用于「这个构建只针对某架构」的场景。

3）拉取验证：用 crictl 在目标节点上确认拉到的架构

# 在 arm 节点上
crictl pull registry.internal/svc:v1.4.3
crictl images | grep svc            # 看 digest
crictl inspect <imageID> | grep -E 'architecture|os'
# 期望输出："architecture": "arm64"

# 确认 binfmt 状态（判断某节点会不会「模拟着跑」）
ls -l /proc/sys/fs/binfmt_misc/ | grep qemu
# 有 qemu-aarch64 且 enabled → 该节点会模拟 arm 镜像

4）兜底：如果确实要让 arm 镜像在 amd64 节点上「能起来」（临时验证用），注册 binfmt

docker run --privileged --rm tonistiigi/binfmt --install arm64
# 注意：这只是让它「能跑」，不是「应该跑」，生产上不要依赖模拟

四、踩过的坑与反直觉之处

digest 不同 ≠ 镜像被污染。manifest list 下每个架构子镜像 digest 天然不同，crictl images 显示的是本节点实际拉的那个。别拿两个节点的 digest 去 diff 报警。
exec format error + Exit Code: 255 是「架构不匹配且无 binfmt」的指纹。它和 OOM（137）、探针失败（137/143）长得不一样，看到 255 + 这行日志先想架构，别急着查代码。
能跑 ≠ 该跑。amd64 节点上 arm 镜像能起来，是因为 QEMU 在兜底，冷启动慢 6.5 倍就是它的账单。模拟是「能工作」不是「正常工作」。
imagePullPolicy: IfNotPresent + 换架构重打同 tag 是陷阱。节点本地缓存了旧架构的同名镜像，新 tag 没变就不重拉，于是「发了新架构的镜像，节点还在用旧架构的」。要么换 tag，要么 Always，要么发布时清本地镜像。
裸 docker build 出的镜像不是多架构的。只有 buildx --platform 才会产 manifest list。用 docker manifest inspect 看有没有 mediaType: .../list 来确认——没有就说明它只是单架构，跨节点必炸。
--provenance 默认开启会让老 containerd 拉取报错。K8s 1.29 / containerd 1.7 拉 buildx 默认镜像偶发 unknown media type application/vnd.buildkit.provenance+json，加 --provenance=false 最稳。

五、结论与可复用清单

多架构镜像的坑，90% 出在「架构在拉取时才被选出来」这个事实没被尊重：调度没约束架构 → 拉到错架构节点 → 要么 exec format error（无 binfmt），要么被 QEMU 模拟拖慢（有 binfmt）。可复用清单：

[ ] 跨架构发布一律走 docker buildx build --platform linux/amd64,linux/arm64 --push，并用 docker manifest inspect 确认是 manifest list；
[ ] 加 --provenance=false 规避老 containerd 的 attestation 报错；
[ ] 单架构镜像在 Deployment 里写 nodeSelector: kubernetes.io/arch: arm64，让错架构节点在调度层就选不中；
[ ] 真多架构镜像不要写死 arch，交给 containerd 按节点 arch 自动选子镜像；
[ ] 发布后在目标节点 crictl inspect 确认 architecture 字段，别只看「Running」；
[ ] 看到 exec format error + Exit Code: 255，先查架构匹配，再查代码；
[ ] 换架构重打同 tag 时，要么换 tag、要么 imagePullPolicy: Always、要么清本地镜像，避免缓存旧架构。

这套做法我们在 arm64 + amd64 混部集群上验证：发布 v1.4.3 后，错架构调度导致的 255 崩溃从每周 2~3 次降到 0，amd64 节点上不再出现 6 倍冷启动的慢副本。它不解决业务问题，但它保证「镜像发对了架构」这件事在调度和拉取两层都锁死。

赞 1 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。