《Go 语言编程实战》14.3 非 root、健康检查与资源限制

本节把 TaskHub 的镜像从「能跑」升级到「敢放进生产」：进程以非 root 身份运行、容器自带健康探针、内存与 CPU 有硬上限，并让 Go 运行时正确感知这些上限。

前两节解决了镜像的体积和构建速度。但一个镜像「小」和「快」不代表「安全」和「稳定」。生产环境对容器还有三条硬要求，缺一条就可能出事：不以 root 运行（权限最小化）、有健康检查（编排系统能判断死活）、有资源限制（一个 Pod 不能拖垮整台机器）。

这一节逐条落地，并且用真实数据说明「没有限制会怎样」。

14.3.1 容器里的 root 为什么危险

容器不是虚拟机。容器里的 root 和宿主机的 root 共享同一个内核——隔离靠的是 namespace 和 cgroup，不是硬件边界。所以一个以 root 跑的容器一旦被攻破，攻击者拿到的是 uid 0，配合内核漏洞或配置不当的挂载，就可能逃逸到宿主机。

「以非 root 运行」是最基础的一道防线。它的价值不在于「绝对安全」，而在于把攻击者从 uid 0 降级到普通用户：

注意最后一行：非 root 不能绑定 1024 以下的端口。所以 TaskHub 监听 :8080 而不是 :80——这也是为什么现代服务的默认端口普遍是 8080/8443。

14.3.2 USER + 只读根文件系统

distroless 的 nonroot 变体已经预置了 uid 65532 的用户，声明一行就生效：

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /out/taskhub /taskhub
COPY --from=build /out/memhog /memhog
USER nonroot:nonroot
EXPOSE 8080
ENTRYPOINT ["/taskhub"]

实测确认运行身份：

$ docker inspect -f '{{.Config.User}}' taskhub-distroless:14.1
nonroot:nonroot

再进一步是只读根文件系统。 大多数服务不需要写自己的根文件系统，用 --read-only 把它锁死，任何写入都会失败：

docker run --rm --read-only --tmpfs /tmp taskhub-prod:14.3

这样即使攻击者拿到了命令执行，也没法往磁盘上落工具或后门——因为根文件系统根本不可写。需要临时写文件时，显式挂一个 tmpfs 到 /tmp（内存盘，进程退出即清空）。

在 Kubernetes 里对应两个字段（第 15 章展开）：

securityContext:
  runAsNonRoot: true
  runAsUser: 65532
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

runAsNonRoot: true 有个坑：如果镜像里的 USER 没设或设成 root，Pod 会直接启动失败（CreateContainerConfigError），而不是悄悄以 root 跑。这是好事——它逼你把镜像改对。TaskHub 的镜像设了 USER nonroot:nonroot，正好满足。

14.3.3 HEALTHCHECK：让容器自带探针

HEALTHCHECK 指令让容器自己带一个周期性探针，Docker 会定期执行它并根据退出码更新容器状态。distroless 里没有 curl，所以探针只能靠二进制自身——给程序加一个 -health 子命令：

health := flag.Bool("health", false, "run health probe and exit")
flag.Parse()
if *health {
	url := os.Getenv("TASKHUB_HEALTH_URL")
	if url == "" {
		url = "http://127.0.0.1:8080/healthz/live"
	}
	c := &http.Client{Timeout: 2 * time.Second}
	resp, err := c.Get(url)
	if err != nil || resp.StatusCode != http.StatusOK {
		fmt.Fprintln(os.Stderr, "unhealthy:", err)
		os.Exit(1) // 非 0 退出码 = 不健康
	}
	resp.Body.Close()
	os.Exit(0)
}

Dockerfile 里声明：

HEALTHCHECK --interval=3s --timeout=2s --start-period=1s --retries=2 \
  CMD ["/taskhub", "-health"]

四个参数各有含义：

--start-period 是新手最常漏的参数。 如果服务冷启动需要加载大文件或建连接池，启动期间探针必然失败；没有宽限期，容器可能还没起来就被判成 unhealthy。

14.3.4 实测：healthy 与 unhealthy

正常运行时，探针返回 0：

$ docker inspect -f 'health={{.State.Health.Status}} user={{.Config.User}}' th143
health=healthy user=nonroot:nonroot

故意把探针指向一个不存在的端口，模拟「依赖挂了」：

$ docker inspect -f 'health={{.State.Health.Status}}' th143b
health=unhealthy
$ docker inspect -f '{{range .State.Health.Log}}exit={{.ExitCode}} out={{.Output}}{{end}}' th143b
exit=1 out=unhealthy: Get "http://127.0.0.1:9999/healthz/live":
dial tcp 127.0.0.1:9999: connect: connection refused

docker inspect 里的 Health.Log 会保留最近几次探针的退出码与输出，这是排查「容器为什么被重启」的第一手证据。看到 exit=1 加一句 connection refused，就立刻知道是探针 URL 配错了，而不是程序崩了。

一个重要的区分（第 15 章会细化）：Docker 的 HEALTHCHECK 和 Kubernetes 的探针是两套独立机制。K8s 不会看 Docker 的 HEALTHCHECK，它用自己的 livenessProbe / readinessProbe。所以两处都要配，或者干脆把健康检查逻辑做成 HTTP 端点（TaskHub 的做法），两边都能复用。

14.3.5 资源限制：一个 Pod 不能拖垮整台机器

没有资源限制的容器是一个「吵闹的邻居」：它能把宿主机内存吃光，让同节点上的其他 Pod 一起 OOM；也能占满所有 CPU 核心，让别人的请求延迟飙升。两个维度分别设：

docker run --memory=64m --cpus=0.5 taskhub-prod:14.3

• --memory 是硬上限，超了就被内核 OOM killer 干掉；
• --cpus 是 CPU 配额，超了会被限流（throttle），但不会被杀。

Kubernetes 里的对应关系值得记清楚，因为名字和语义容易混：

内存超限是被杀，CPU 超限是被限速——这个区别决定了你要不要给 limit 留余量。内存 limit 设太紧会频繁重启，CPU limit 设太紧只是变慢（但延迟会飙升，可能触发上游超时）。

14.3.6 实测：OOMKilled 与 CPU 限流

用一个申请 200MB 并逐页触碰的程序（memhog，确保内存真正驻留而不是被内核 lazy 分配）测内存上限：

$ docker run -d --memory=64m --entrypoint /memhog taskhub-prod:14.3 200
$ docker inspect -f 'OOMKilled={{.State.OOMKilled}} exit={{.State.ExitCode}}' m1
OOMKilled=true exit=137

$ docker run -d --memory=512m --entrypoint /memhog taskhub-prod:14.3 200
$ docker inspect -f 'OOMKilled={{.State.OOMKilled}} exit={{.State.ExitCode}}' m2
OOMKilled=false exit=0
$ docker logs m2
allocated MB: 200

读法：64MB 限额下申请 200MB，容器被 OOMKilled，退出码 137（128 + SIGKILL 的 9）；放宽到 512MB 就正常分配 200MB 后退出 0。退出码 137 是 OOM 的典型信号，在 K8s 里表现为 Last State: Terminated, Reason: OOMKilled。

CPU 限额用一个 800 万次 SHA-256 的计算任务测：

--cpus=4    -> elapsed=562ms
--cpus=1    -> elapsed=541ms
--cpus=0.5  -> elapsed=1091ms

关键观察：--cpus=4 和 --cpus=1 几乎一样快（562ms vs 541ms），因为这个任务是单线程的，给再多核也用不上；而 --cpus=0.5 正好慢一倍（1091ms），说明限流精确生效。这告诉我们两件事：

1. CPU limit 只对「确实并行」的程序有意义。单线程服务给 4 核配额是浪费。
2. 限流是线性的，配额减半耗时翻倍——所以 CPU limit 设得太紧，P99 延迟会成比例恶化。

14.3.7 Go 运行时对 cgroup 的感知

这一节最容易被忽略、也最容易踩坑的一点：Go 运行时会不会自动读容器的资源限制？ 我用同一个二进制在不同配额下打印 GOMAXPROCS 和 GOMEMLIMIT：

$ docker run --rm gmp:1
GOMAXPROCS=6 NumCPU=6 GOMEMLIMIT=9223372036854775807

$ docker run --rm --cpus=0.5 gmp:1
GOMAXPROCS=2 NumCPU=6 GOMEMLIMIT=9223372036854775807

$ docker run --rm --memory=64m gmp:1
GOMAXPROCS=6 NumCPU=6 GOMEMLIMIT=9223372036854775807

两个结论，一个惊喜一个坑：

惊喜：GOMAXPROCS 会自动感知 cgroup 的 CPU 配额。 宿主机有 6 核，但 --cpus=0.5 时 GOMAXPROCS 自动降到 2。实测的完整映射：

（配额较小时统一收敛到 2，是运行时的取整与下限策略；具体规则以运行时实现为准。）这意味着你不需要再引入 automaxprocs 库——Go 1.25 起运行时原生支持 cgroup CPU 感知。

坑：GOMEMLIMIT 不会自动设置。 无论 --memory=64m 还是不限，GOMEMLIMIT 都是 9223372036854775807（math.MaxInt64，即「不限制」）。这意味着：

• 容器内存上限是 64MB，但 Go 的 GC 完全不知道这件事；
• GC 会一直等到堆涨到默认的 GOGC 触发点（默认 100%，即堆翻倍）才回收；
• 在内存限额很紧的容器里，GC 还没触发，进程就已经被 OOMKilled 了。

解决办法是显式设置 GOMEMLIMIT，给它留出安全余量：

ENV GOMEMLIMIT=48MiB

或者用环境变量在运行时注入（K8s 里从 limit 推导，比如 limit 的 80%）。GOMEMLIMIT 是软限制：它让 GC 在接近这个值时更激进地回收，但不会阻止超限——所以它必须小于容器硬限制，留出余量给非堆内存（goroutine 栈、runtime 结构、CGO 等）。

一句话记住：CPU 配额 Go 自动感知，内存限制 Go 不感知，GOMEMLIMIT 必须自己设。

14.3.8 生产容器检查清单

三条最实在的建议：

1. GOMEMLIMIT 是 Go 服务进容器的必修课，而且它不会自动设置（实测确认）。这一条不做，内存限制越紧，越容易莫名 OOMKilled。
2. 内存 limit 要留余量。如果 GOMEMLIMIT 设成等于 limit，非堆内存一涨就 OOM。经验值：GOMEMLIMIT ≈ limit 的 75%–80%。
3. CPU limit 按实际并行度设，别拍脑袋。单线程服务设 1 核就够；设成 4 核既浪费配额，也不会更快（实测 4 核与 1 核耗时几乎相同）。

小结

• 容器与宿主机共享内核，root 容器被攻破等于拿到 uid 0；以 nonroot 运行是最基础的防线。
• runAsNonRoot: true 会在镜像 USER 是 root 时直接拒绝启动，逼你把镜像改对。
• --read-only + --tmpfs /tmp 让攻击者无法在根文件系统落盘。
• distroless 没有 shell，探针必须靠二进制自带的 -health 子命令；docker inspect 的 Health.Log 是排查重启的第一手证据。
• 实测：64MB 限额下申请 200MB → OOMKilled、退出码 137；512MB 下正常退出 0。
• 实测 CPU 限流：--cpus=0.5 让同一任务从 541ms 变成 1091ms（正好翻倍）。
• GOMAXPROCS 自动感知 cgroup CPU 配额（0.5 核 → GOMAXPROCS=2），不需要 automaxprocs。
• GOMEMLIMIT 不会自动设置（实测始终是 math.MaxInt64），必须显式配置，且要小于容器内存硬限制。

到这里，TaskHub 的镜像已经是一个合格的生产镜像了：15MB、非 root、带探针、有资源上限。但镜像只是「能跑起来的东西」，真正让它高可用的是编排系统——下一章我们把镜像部署到 Kubernetes，用 Deployment/Service/Ingress 组织它，用探针、HPA、优雅停机让它在流量波动和滚动更新中保持不丢请求。

阅读导航：上一节：14.2 构建缓存与多平台 · 下一节：15.1 清单与探针 。