4. 多阶段构建：编译与运行分离，减小最终镜像体积
多阶段构建（Multi-stage Build）是 Docker 17.05+ 引入的核心特性，它允许在单个 Dockerfile 中使用多个 FROM 指令，每个 FROM 可以基于不同的基础镜像，且只有最后一个阶段的产物会被保留到最终镜像中。这一机制天然实现了“编译环境”与“运行环境”的物理隔离，是减小容器镜像体积最有效的手段之一。
4.1 为什么需要编译与运行分离？
传统单阶段构建将编译工具链、依赖库、源代码与最终产物打包在同一层，导致镜像体积膨胀。以下对比表清晰展示了分离前后的差异：
| 对比维度 | 单阶段构建 | 多阶段构建 |
|---|---|---|
| 基础镜像 | 通常使用完整 SDK 镜像（如 golang:1.21，~1.2GB） |
编译阶段使用 SDK 镜像，运行阶段使用精简镜像（如 alpine:3.19，~5MB） |
| 包含内容 | 编译器、调试工具、头文件、源代码、中间产物 | 仅包含编译后的二进制文件、运行时库、配置文件 |
| 最终镜像体积 | 通常 800MB ~ 1.5GB | 通常 10MB ~ 150MB |
| 安全攻击面 | 包含大量不必要的工具和库，漏洞风险高 | 仅保留最小运行依赖，攻击面显著缩小 |
| 构建缓存利用率 | 依赖层顺序，变更源代码后缓存易失效 | 编译阶段与运行阶段缓存独立，运行阶段层几乎不变 |
核心收益： 多阶段构建可将镜像体积减少 80%~95%，同时降低安全漏洞扫描范围，提升镜像分发和节点池升级速度。
4.2 多阶段构建的典型流程
下图展示了多阶段构建中编译阶段与运行阶段的分离关系，以及最终镜像的构成：
4.3 实战：Go 应用多阶段构建 Dockerfile
以下是一个典型的 Go 应用多阶段构建示例，展示了如何将编译与运行彻底分离：
# ========== 阶段一：编译阶段 ==========
FROM golang:1.21-alpine AS builder
# 设置工作目录
WORKDIR /app
# 先复制依赖文件，利用 Docker 缓存层
COPY go.mod go.sum ./
RUN go mod download
# 复制源代码并编译
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /app/server .
# ========== 阶段二：运行阶段 ==========
FROM alpine:3.19
# 安装运行时依赖（如有必要）
RUN apk add --no-cache ca-certificates tzdata
# 从编译阶段复制二进制文件
COPY --from=builder /app/server /usr/local/bin/server
# 复制配置文件（如有）
COPY --from=builder /app/config /etc/app/config
# 暴露端口
EXPOSE 8080
# 设置启动命令
CMD ["server"]
优化要点：
--ldflags="-s -w"：去除调试信息和符号表，进一步减小二进制体积。CGO_ENABLED=0：禁用 CGO，生成纯静态二进制，避免依赖 glibc。- 先复制
go.mod和go.sum再执行go mod download，可最大化利用构建缓存。
4.4 多阶段构建的进阶技巧
除了基本的编译/运行分离，以下技巧可进一步优化镜像体积和构建效率：
- 多阶段链式传递： 使用多个中间阶段分别处理依赖安装、代码编译、测试、静态分析，最终阶段只保留必要产物。
- 使用
--from=0语法： 在COPY指令中引用前面阶段的别名，支持跨阶段复制任意文件或目录。 - 结合
.dockerignore： 排除node_modules、.git、test等非必要文件，减少构建上下文体积。 - 运行阶段使用
distroless镜像： 如gcr.io/distroless/base，仅包含应用运行所需的库和运行时，无 shell 和包管理器，体积更小、安全性更高。
| 运行阶段基础镜像 | 体积 | 适用场景 | 注意事项 |
|---|---|---|---|
alpine:3.19 |
~5MB | 通用场景，需要 shell 调试或安装额外包 | 使用 musl libc，部分 CGO 程序需适配 |
gcr.io/distroless/base |
~12MB | 生产环境，追求最小攻击面 | 无 shell，无法 exec 进入容器调试 |
ubuntu:22.04 (slim) |
~30MB | 需要 glibc 兼容性或复杂运行时依赖 | 体积相对较大，但兼容性最好 |
常见陷阱：
- 不要在运行阶段使用
apt-get install安装编译工具，这违背了分离原则，会大幅增加镜像体积。 - 注意
COPY --from=builder的路径必须与编译阶段中产物的实际路径一致，否则会导致构建失败。 - 如果应用依赖动态链接库（如 glibc），运行阶段必须包含对应的库文件，否则二进制无法执行。
4.5 多阶段构建对节点池升级的收益
在 Kubernetes 节点池升级场景中，镜像体积直接影响升级速度：
- 镜像拉取时间缩短： 15MB 的镜像相比 1.2GB，拉取时间从分钟级降至秒级，尤其在大规模节点池滚动升级时效果显著。
- 节点磁盘占用减少： 更小的镜像意味着更少的磁盘 I/O 和存储压力，节点可以承载更多 Pod 实例。
- 升级失败率降低： 镜像拉取超时是节点池升级失败的主要原因之一，小体积镜像大幅降低了超时概率。
通过多阶段构建，我们不仅获得了更小的镜像体积，还实现了更快的部署速度、更高的安全性和更低的运维成本。这是容器化应用从开发到生产的最佳实践，也是提升节点池升级效率的关键基础。