基于scratch镜像构建的容器镜像在Kubernetes Deployment中启动失败的原因解析及疑问

你遇到的这个报错看起来是找不到可执行文件，但其实背后的原因和Go程序的编译方式以及scratch镜像的特性有关，我来详细拆解一下：

问题场景回顾 #

你使用了多阶段构建的Dockerfile：

• 第一阶段基于golang:1.19.2-bullseye编译Go程序，编译命令是CGO_ENABLED=1 go build -race -ldflags "-s -w" -o client-go
• 第二阶段基于scratch镜像，复制编译好的client-go作为入口程序
  部署到Kubernetes后出现启动失败，报错提示找不到文件，但换成ubuntu镜像后问题解决。

核心原因：动态链接库缺失 #

这个报错的真实原因不是找不到/client-go可执行文件本身，而是找不到它依赖的动态系统库。具体来说：

• 当你设置CGO_ENABLED=1时，Go编译器会生成动态链接的二进制文件，它依赖系统的glibc库（这是bullseye镜像里自带的）
• scratch是一个完全空的基础镜像，不包含任何系统库、shell甚至基础的系统文件，所以动态链接的client-go在执行时找不到依赖的glibc，就会抛出这个看似“找不到文件”的错误。

而ubuntu镜像自带完整的glibc库，所以动态链接的程序能正常找到依赖并启动。另外补充一点：-race参数也会强制开启CGO，因为竞态检测依赖CGO实现，所以即使你没显式设置CGO_ENABLED=1，用-race也会自动开启动态链接。

解决方案 #

根据你的需求，有几种可选方案：

1. 编译静态链接的二进制文件（推荐用于scratch镜像） #

修改编译命令，关闭CGO并强制静态链接：

RUN CGO_ENABLED=0 GOOS=linux go build -ldflags "-s -w" -o client-go

注意：-race参数和CGO_ENABLED=0不兼容，如果你不需要竞态检测，可以去掉-race；如果必须保留竞态检测，就不能用scratch镜像，需要选择带glibc的基础镜像（比如debian、ubuntu）。

2. 使用轻量的带glibc的基础镜像 #

如果不想关闭CGO，又想保持镜像较小，可以选择debian:bullseye-slim或者ubuntu:latest这类轻量发行版镜像，它们包含glibc但比完整的ubuntu镜像小很多。

3. 使用alpine镜像（需要额外处理） #

alpine使用的是musl libc而非glibc，如果你想用alpine，需要在编译时针对musl构建：

FROM golang:1.19.2-alpine as builder
RUN apk add --no-cache gcc musl-dev
COPY src /src
WORKDIR /src
RUN CGO_ENABLED=1 GOOS=linux go build -race -ldflags "-s -w" -o client-go
FROM alpine:latest
COPY --from=builder /src/client-go /client-go
ENTRYPOINT [ "/client-go" ]

不过这种方式需要安装编译依赖，且某些CGO特性可能和musl存在兼容性问题，需要测试验证。

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