golang + kubernetes 项目开发流程核心是 client-go 初始化、controller-runtime reconciler 设计、dockerfile 多阶段构建三件事；client-go 必须优先用 rest.inclusterconfig()（pod 内）或绝对路径 buildconfigfromflags（本地），避免 401/403；reconciler 必须幂等、限时、绑定 ownerreference；dockerfile 必设 cgo_enabled=0、监听 0.0.0.0:8080、非 root 用户、独立探针路径。
直接上结论：Golang + Kubernetes 的项目开发流程不是“先写代码再塞进集群”，而是从第一天起，client-go 初始化方式、controller-runtime 的 reconciler 设计、Dockerfile 多阶段构建策略这三件事就决定了你后续 80% 的调试成本和上线稳定性。
如何初始化 client-go 并避免 401/403 错误
绝大多数权限失败不是 RBAC 配置错了，而是 rest.Config 拿错了——Pod 内运行时硬写 ~/.kube/config 路径，或用相对路径传给 clientcmd.BuildConfigFromFlags，都会导致认证失败。
- 必须优先调用
rest.InClusterConfig()，它会自动读取/var/run/secrets/kubernetes.io/serviceaccount/下的token和ca.crt - fallback 到本地 kubeconfig 时，第二个参数必须是绝对路径，比如
"/home/user/.kube/config"，不能是"./kubeconfig" - 未显式设置 QPS/Burst 时，默认
5/10极易被 apiserver 限流；建议在 config 返回后立即设Config.QPS = 20; Config.Burst = 30 - 永远用
kubernetes.NewForConfig(config)获取clientset，不要直接 newcorev1.Client，否则可能因版本不一致 panic
controller-runtime reconciler 必须满足的三个硬约束
Reconcile 函数不是普通 handler，它是 Kubernetes 控制循环的原子执行单元，卡住或 panic 会导致整个 controller 停摆。
- 必须幂等：同一
ctrl.Request可能被反复投递，不能依赖“只执行一次”的假设 - 必须快速返回：默认超时 15 秒，任何阻塞操作（如 HTTP 请求、DB 查询）都要加 context 超时和重试封装
- 不能留孤儿资源：比如创建了 Job 但没设
OwnerReference，控制器重启后无法自动清理；要用ctrl.SetControllerReference()绑定 - 监听资源必须调
.Complete(r)，只写.For(&corev1.Pod{})不会真正启动 informer，日志里看不到Starting workers
Dockerfile 多阶段构建中 CGO_ENABLED=0 不是可选项
不加 CGO_ENABLED=0 编译出的二进制会动态链接 libc，一旦用 scratch 或精简 alpine 运行就会报 no such file or directory——这个错误常被误判为路径问题，实际是链接器找不到 so。
- 构建阶段用
golang:1.22-alpine，运行阶段切到scratch，体积通常压到 6–8MB - 编译命令必须含
CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' -
EXPOSE 8080和监听地址0.0.0.0:8080必须同时存在；写成127.0.0.1:8080导致 Service 流量进不来，且无报错，只能靠 tcpdump 抓包定位 - 运行用户不能是 root：
USER 65532:65532是安全底线，否则容器逃逸后直接获得节点 root 权限
livenessProbe / readinessProbe 路径必须独立实现
Kubernetes 不看进程是否存活，只认探针 HTTP 状态码。很多 Go 服务只暴露 /，但没单独实现 /healthz 或 /readyz，结果 Pod 一直 Pending 或反复 CrashLoopBackOff。
-
livenessProbe应检查进程级健康（如能否响应 HTTP），不建议加 DB 连通性，否则 DB 挂了整个 Pod 被杀 -
readinessProbe才该做 DB、Cache、下游依赖连通性检查，确保流量只打到真正就绪的实例 - 两个探针路径必须真实注册到
http.ServeMux，且 handler 不能 panic；哪怕只是w.WriteHeader(http.StatusOK)也比空 handler 强 -
initialDelaySeconds要大于应用冷启动时间，Go 服务一般设10–30秒，太短会导致 probe 失败触发重启循环
最常被跳过的其实是 cache 同步等待：用 controller-runtime 时，mgr.GetCache().WaitForCacheSync(ctx) 必须在启动前显式调用，否则 Reconcile 里 client.Get() 可能返回 NotFound——不是资源真没了，是 informer 还没热加载完。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
