Go应用镜像必须用多阶段构建，否则资源限制形同虚设；需分离构建与运行环境，最终镜像压至10–15MiB，配合GOMAXPROCS、GOGC调优及合理探针配置，才能使Kubernetes资源限制真正生效。
Go应用镜像必须用多阶段构建，否则资源限制形同虚设
单阶段镜像（比如直接 FROM golang 运行）会把编译器、调试符号、Go运行时全塞进生产镜像，导致体积大、攻击面宽、启动慢——更重要的是，Kubernetes 的 resources.limits 对这种“胖镜像”约束效果极差：它限制的是容器进程的资源使用，但镜像本身冗余越多，实际开销越难预测。
正确做法是严格分离构建与运行环境：
-
FROM golang:1.21-alpine AS builder阶段只做下载依赖和构建，加-ldflags="-s -w"去掉调试信息 -
FROM alpine:latest阶段只复制二进制，不装 Go、不带源码、不保留/go目录 - 最终镜像大小通常压到 10–15 MiB，CPU/内存占用更稳定，
limits才真正生效
Deployment里resources字段怎么填才不翻车
CPU 和内存的语义完全不同，填错一个就可能让服务在半夜被 OOMKilled 或卡死在调度队列里。
CPU 用毫核（m）：250m = 0.25 核。它不是硬上限，而是 Kubernetes 在每 100ms 周期里最多给你分配 25ms 时间片。如果 Go 程序没调优（比如 GOMAXPROCS 默认是机器核数），它可能疯狂抢占、频繁切换，反而更慢。
内存是硬边界：超了直接杀 Pod。Go 的 GC 对内存压力敏感，limits.memory 设太小会导致 GC 频繁触发，CPU 升高；设太大又浪费资源、降低节点调度效率。
推荐起始值（生产环境）：
-
requests.cpu: "500m"—— 给调度器留出足够空间，避免被挤到低配节点 -
limits.cpu: "1000m"—— 允许短时突发，但需配合GOMAXPROCS=2（按 limits.cpu / 1000 取整）防止 goroutine 调度失衡 -
limits.memory: "512Mi"—— 必须大于 Go 程序常驻堆 + 缓存 + 日志缓冲，建议先压测再定
Go程序得主动适配CPU限制，不然白配
Kubernetes 的 CPU 限制不会自动告诉 Go 运行时“你只有 0.5 核”，runtime.GOMAXPROCS 仍会读取宿主机总核数。结果就是：16 核机器上跑一个 250m 限制的 Pod，Go 默认启 16 个 P，大量 goroutine 在 0.25 核上争抢，上下文切换飙升，延迟暴涨。
必须显式控制：
- 在容器启动前设置环境变量：
ENV GOMAXPROCS=1（若limits.cpu <= 500m），或按比例算（如 1000m →GOMAXPROCS=2） - 避免在代码里调用
runtime.GOMAXPROCS(0)或硬编码大数值 - GC 也得调：
ENV GOGC=20可降低内存峰值，配合limits.memory使用
验证方式：进 Pod 执行 ps aux | grep app 看线程数，再用 cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us 确认实际配额是否生效。
健康探针不写对，资源限制再准也没用
很多团队配了 resources 却忽略探针，结果 Pod 因启动慢被反复重启，或因内存抖动被误判为不健康。
关键点：
-
readinessProbe的initialDelaySeconds必须大于 Go 应用真实冷启动时间（尤其带 DB 连接池、配置加载的） -
livenessProbe的periodSeconds别设太短（ - 健康端点必须轻量：不查 DB、不调外部 API、不打日志，纯内存判断，响应时间
- 探针路径要和容器
containerPort一致，且确保 Go 服务监听的是0.0.0.0:8080，不是127.0.0.1:8080
最常被忽略的是：探针失败后，Kubernetes 会 kill 容器并重建，如果此时资源限制偏紧，新 Pod 可能陷入“启动→探针失败→重启→再启动”的循环，把节点 CPU 拉满。
真正卡住人的从来不是 YAML 写几行，而是 Go 运行时行为和 cgroup 限制之间的隐式耦合——比如 GOMAXPROCS 不设，limits.memory 再准也会因 GC 崩溃；比如探针超时设短了，requests.cpu 再合理也扛不住连续重建。
