Go应用上Kubernetes需关注镜像构建（禁用CGO、指定GOOS=linux、多阶段构建）、健康探针分离（/ready检查依赖、/health检查进程）、资源requests合理设置（内存1.2–1.5倍负载、CPU按吞吐估算）、client-go配置动态化及hostname稳定性处理。
Go 应用上 Kubernetes 不是“配个 YAML 就完事”，关键在容器镜像是否干净、健康探针是否真实有效、资源限制是否贴合实际负载。否则部署后 CrashLoopBackOff、OOMKilled 或就绪但不响应请求，都是高频问题。
Go 二进制构建必须禁用 CGO 且指定 GOOS=linux
本地 macOS 或 Windows 编译的 Go 二进制无法在 Alpine 或 distroless 镜像中运行——会报 no such file or directory（实际是动态链接器缺失）。多阶段构建里这步不能跳：
-
CGO_ENABLED=0禁用 C 语言依赖，避免引入 libc -
GOOS=linux强制目标系统为 Linux -
-ldflags="-s -w"去除调试符号，减小镜像体积 - 最终二进制要复制到
scratch或distroless基础镜像，而非带 shell 的 Alpine（除非真需要sh调试）
livenessProbe 和 readinessProbe 别共用同一端点
很多教程把 /health 同时用于存活和就绪检查，这会导致滚动更新卡住或误杀 Pod。真实场景中：
-
readinessProbe应检查依赖是否就绪（如 DB 连通、Redis 可写、配置加载完成），路径建议用/ready -
livenessProbe应检查进程是否僵死（如 goroutine 泄漏、死锁），路径建议用/health，只做轻量心跳 -
initialDelaySeconds必须大于应用冷启动耗时，Go HTTP server 启动快，但若含 config 加载、DB 迁移等逻辑，5 秒不够，设成 15–30 秒更稳妥
Deployment 的 resources.requests 影响调度，不是可选配置
Kubernetes 调度器靠 requests 决定 Pod 能落在哪个 Node 上。如果只设 limits 不设 requests，默认 requests == limits，容易导致节点资源碎片化、调度失败。
- Go 应用内存
requests建议设为稳定负载的 1.2–1.5 倍，比如压测平均占 100Mi，就设128Mi - CPU
requests按持续吞吐估算，Go 并发高但单核利用率未必满，100m（0.1 核）对中小服务常够用 - 别信“先不限制，上线后再调”——没 requests 的 Pod 会被优先驱逐，尤其在节点内存压力大时
用 client-go 管理资源时，config 文件路径和命名空间别硬编码
写脚本或 Operator 时，clientcmd.BuildConfigFromFlags("", "/path/to/kubeconfig") 看似简单，但生产环境常踩三个坑：
- kubeconfig 路径应从环境变量读取（如
KUBECONFIG），或支持--kubeconfig参数，否则无法适配多集群 - Namespace 必须显式传入，
client.CoreV1().Pods("default").List()在非 default 命名空间下直接报错NotFound - Context 超时要用
context.WithTimeout()包裹，避免 List/Watch 卡死阻塞整个协程
最易被忽略的是：Go 应用容器内 hostname 默认是 Pod 名，而很多日志或指标上报逻辑会拼接 hostname 做唯一标识——一旦 Deployment 缩容，旧 Pod 的 hostname 消失，监控断点或日志乱序就很难追溯。要么改用 downwardAPI 注入 stable ID，要么在应用层用 Pod UID 替代 hostname。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
