Docker 镜像构建通常被当作单机任务处理，构建上下文、依赖下载和镜像层压缩都在同一台机器上完成。当镜像体积膨胀、依赖增多，或者需要同时产出多架构镜像时，单机构建的瓶颈会迅速暴露出来。分布式构建不是简单地把 Dockerfile 复制到几台机器上执行，而是通过统一的构建调度器把任务分发到多个 BuildKit 节点，并让这些节点共享缓存和镜像输出。
一、为什么单机构建需要走向分布式
单机构建 Docker 镜像时，最直接的瓶颈来自计算资源。构建过程需要解析 Dockerfile、下载基础镜像、安装依赖、编译代码、压缩镜像层，每一步都会占用 CPU 和内存。尤其在多阶段构建中，即使前面阶段产生的中间层不会进入最终镜像，构建过程仍然要真实执行。一台 8 核 16GB 的构建机，遇到 Node.js 前端依赖安装或 Java 项目依赖解析时，很容易出现内存不足或构建时间超过十分钟。
第二个瓶颈是任务排队。CI 流水线通常同时触发多个服务的构建任务，如果只有一台构建机，这些任务只能串行执行。一个服务依赖下载慢，后面所有服务都在等待。分布式构建可以按服务拆分任务，让多个节点同时构建不同镜像，避免无意义的排队。
多架构镜像的需求也让单机构建更吃力。在没有分布式构建时，要为 amd64 和 arm64 分别构建，要么借助 QEMU 模拟运行，速度较慢，要么手动在不同架构机器上构建再拼合 manifest。分布式构建方案天然适合多架构场景，每个节点负责自己架构的构建过程，最后由调度器合并镜像清单。
二、使用 Docker Buildx 与远程 BuildKit 节点实现分布式构建
Docker Buildx 是 Docker CLI 的一个插件，背后驱动的是 BuildKit 引擎。默认情况下，Buildx 使用本地单节点运行，但可以通过 docker buildx create 创建包含多个节点的 builder 实例。这些节点可以是本地 Docker daemon、远程 SSH 主机，也可以是 Kubernetes 集群中的 Pod。节点拥有不同的架构和标签后，Buildx 会自动把构建任务分配给合适节点。
下面是一个创建双架构远程构建集群的示例。假设已经有一台 amd64 构建机和一台 arm64 构建机，并且都启用了 SSH 登录：
docker buildx create --name mybuilder --node linux-amd64 --platform linux/amd64 docker buildx create --name mybuilder --append --node linux-arm64 --platform linux/arm64 ssh://builder@arm-host docker buildx use mybuilder docker buildx inspect --bootstrap
第一条命令创建一个名为 mybuilder 的 builder，并添加本地 amd64 节点。第二条命令将远程 arm64 主机追加到同一个 builder 中，指定其平台为 linux/arm64。第三条命令把当前 Docker CLI 切换到该 builder，第四条命令启动并检查所有节点状态。执行 docker buildx inspect --bootstrap 后，如果两个节点都显示为 running，说明分布式构建集群已经就绪。
之后执行构建时，只需要在命令中声明多个目标平台，Buildx 会把 amd64 任务分配给本机节点，把 arm64 任务分配给远程 ARM 主机，并在完成后合并成多架构镜像：
docker buildx build --platform linux/amd64,linux/arm64 -t registry.ipipp.com/app:latest --push .
这种方式的优势在于命令层面几乎没有改变，仍然使用 Dockerfile 和熟悉的构建参数。缺点是远程节点需要提前安装 Docker 和 BuildKit，并且 SSH 连接要稳定。对网络不稳定的环境，可以考虑使用 Kubernetes 驱动，让集群内部调度构建任务。
三、在 Kubernetes 集群中构建镜像的两种常见方式
如果团队已经有 Kubernetes 集群，把镜像构建迁移到集群内部可以更好地利用空闲资源。Kubernetes 的调度器能把构建 Pod 分配到不同 Node 上执行，天然具备分布式能力。常见做法有两种：部署 BuildKit 服务供 CI 调用，或者使用 Kaniko 在 Pod 中直接构建。
先看 BuildKit 的部署方式。可以在集群中运行一个 BuildKit Deployment，暴露 unix socket 或 TCP 端口，然后 CI 通过 Buildx 的 kubernetes driver 连接。下面是一个简化的 Deployment 示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: buildkit
spec:
replicas: 1
selector:
matchLabels:
app: buildkit
template:
metadata:
labels:
app: buildkit
spec:
containers:
- name: buildkitd
image: moby/buildkit:latest
args:
- --addr
- unix:///run/buildkit/buildkitd.sock
securityContext:
privileged: true
这个 Pod 以特权模式运行 BuildKit 守护进程，CI 端可以使用 docker buildx create --name k8s --driver kubernetes --driver-opt replicas=3 来创建基于 Kubernetes 的 builder。当 replicas 设置为 3 时，集群中会运行多个 BuildKit Pod，构建任务可以在这些 Pod 之间调度。这种方式适合高频构建，但特权容器在一些托管 Kubernetes 环境中可能受到安全策略限制。
如果不想使用特权容器，Kaniko 是更合适的选择。Kaniko 由 Google 开源，可以在用户态解析 Dockerfile 并逐层构建镜像，不需要 Docker daemon，也不需要特权模式。Kaniko 的典型用法是创建一个 Pod，把代码拉取下来后执行构建并推送镜像：
apiVersion: v1
kind: Pod
metadata:
name: kaniko
spec:
containers:
- name: kaniko
image: gcr.io/kaniko-project/executor:latest
args:
- --context=git://github.com/your/repo.git
- --destination=registry.ipipp.com/app:latest
Kaniko 免特权部署降低了集群安全风险，但每次构建都需要重新解析依赖，缓存控制不如 BuildKit 灵活。可以通过远程 registry 缓存来缓解重复拉取基础镜像的问题。总体来看，BuildKit 适合需要强缓存和高性能的场景，Kaniko 适合安全和权限控制更严格的场景。
四、分布式构建的缓存共享与多架构镜像推送优化
分布式构建中，缓存共享往往是决定构建时间的关键。如果每个节点各自维护本地缓存，同一基础镜像或依赖层可能被重复下载多次。BuildKit 支持把构建缓存导出到镜像仓库，供其他节点导入使用。常用的缓存方式包括 inline cache、registry cache、local cache 和云存储缓存。registry cache 在多节点场景下命中率较高，因为它允许所有节点访问同一个远程缓存位置。
下面是一个同时输出多架构镜像并使用 registry cache 的构建命令：
docker buildx build --platform linux/amd64,linux/arm64 \ --cache-from type=registry,ref=registry.ipipp.com/cache/app:buildcache \ --cache-to type=registry,ref=registry.ipipp.com/cache/app:buildcache,mode=max \ -t registry.ipipp.com/app:latest --push .
--cache-from 告诉构建节点从哪里读取缓存，--cache-to 则把本次构建产生的中间层缓存推送到指定镜像标签。参数 mode=max 会导出所有阶段和中间层的缓存，而默认的 mode=min 只导出最终镜像需要的层。对于分布式多节点构建，使用 mode=max 能显著提升远端节点的缓存命中率，但缓存镜像体积也会变大。
多架构镜像推送方面，Buildx 会自动生成 manifest list，把不同架构的镜像索引合并到一个 tag 下。用户可以继续使用 docker pull registry.ipipp.com/app:latest，Docker 会根据运行平台自动选择对应的架构层。手动维护多架构 manifest 时常见的架构遗漏问题，在分布式构建流程中会减少很多，因为构建平台列表就是 manifest 生成依据。
实际落地时，还需要关注构建日志和节点状态。CI 流水线中建议使用 --progress=plain 输出可读日志，方便定位是哪个架构节点失败。可以定期执行 docker buildx inspect --bootstrap 检查节点健康状态，避免远程主机离线导致整个构建任务挂起。对于构建任务量波动较大的团队，可以结合 Kubernetes 的弹性伸缩能力，让 BuildKit Pod 按队列长度自动增减。