镜像体积过大会降低集群部署效率，应通过多阶段构建、选用精简基础镜像、构建时清理临时文件及配置镜像自动清理策略来优化。
镜像体积过大直接影响集群部署效率：拉取慢、节点磁盘压力大、启动延迟高，严重时还会触发节点驱逐或导致 imagepullbackoff 错误。解决核心在于“构建即瘦身”，而不是事后压缩。
用多阶段构建剥离编译环境
编译工具链（如 Maven、Go SDK、Node.js）只在构建阶段需要，运行时完全不需要。把它们留在最终镜像里，是体积膨胀的主因。
- 第一阶段用完整工具镜像（如
maven:3.8.6或golang:1.22）完成编译打包 - 第二阶段切换为极简运行时镜像（如
openjdk:17-jdk-slim、alpine或distroless），仅复制编译产物（jar、binary、static assets） - 避免在最终镜像中安装任何额外包（如
curl、bash），除非业务强依赖
选对基础镜像，从源头减负
基础镜像决定下限。官方 slim 或 alpine 版本比标准版小 50%～70%，distroless 更进一步——只含运行时依赖，无 shell、无包管理器，安全性也更高。
- Java 应用优先用
openjdk:17-jre-slim或gcr.io/distroless/java17 - Python 应用可用
python:3.11-slim，避免python:3.11（含完整 deb 包系统） - Node.js 推荐
node:20-alpine，但注意某些 C++ 插件可能不兼容，需验证
构建过程清理临时文件和缓存
Docker 构建每层都会保留，RUN 指令产生的中间文件若未显式删除，会固化进镜像。
- 合并清理命令：比如
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/* - 避免分多行写 apt 安装和清理，否则前一层残留缓存目录
- 对于 Maven，加
-Dmaven.repo.local=/tmp/.m2并在最后RUN rm -rf /tmp/.m2
启用镜像扫描与定期清理策略
单靠构建优化不够，集群层面要防止旧镜像堆积。
- 在节点上配置
imageGCHighThresholdPercent（默认 85%）和imageGCLowThresholdPercent（默认 80%），触发自动清理 - 配合
crictl rmi --prune或脚本定期清理未被 Pod 引用的 dangling 镜像 - CI 流水线中集成
docker scout cve或trivy扫描，阻断高危或超大镜像入库
