最常卡在容器启动后立即退出，根本原因是环境适配缺失：main函数执行完进程退出、监听地址写死localhost、健康探针路径未暴露、依赖文件缺失，或未正确处理SIGTERM信号导致优雅关闭失败。
Go应用在Kubernetes中启动失败，常见原因是什么
最常卡在容器启动后立即退出，kubectl logs 空或只显示 panic 前几行，本质是进程没起来就挂了。根本原因往往不是代码逻辑错误，而是环境适配缺失：
-
http.Server启动后没加select{}或time.Sleep阻塞主 goroutine，导致main()函数执行完进程直接退出 - 监听地址写死
"localhost:8080"，应改为":8080"（绑定所有网卡），否则 Pod 内其他容器无法访问 - 健康探针路径未暴露，或 handler 未注册，导致 readiness/liveness 检查失败，Kubernetes 主动 kill 容器
- 程序依赖本地文件（如配置文件、证书），但镜像里没 COPY 进去，运行时报
open /config.yaml: no such file
如何让 Go 应用正确响应 Kubernetes 的优雅关闭信号
不处理 SIGTERM 会导致连接被粗暴中断，用户请求失败。关键不是“捕获信号”，而是“给正在处理的请求留出完成时间”：
- 必须用
http.Server.Shutdown()替代server.Close()，前者会等待活跃连接结束 - 传入的
context.Context要带超时（如30*time.Second），避免无限等待 - 数据库连接、消息队列消费者等外部资源，需在
Shutdown前主动关闭，否则 context 超时后仍可能 panic - 不要在 signal handler 里直接调
os.Exit()，这会跳过 defer 和 Shutdown 流程
示例片段：server := &http.Server{Addr: ":8080"}; go server.ListenAndServe(); c := make(chan os.Signal, 1); signal.Notify(c, os.Interrupt, syscall.SIGTERM);
client-go 初始化时为什么总报 401 Unauthorized
绝大多数情况是认证配置没走对路径，不是 token 权限问题。in-cluster 和本地开发两种场景必须严格区分：
- Pod 内运行时，必须优先用
rest.InClusterConfig()，它自动读取/var/run/secrets/kubernetes.io/serviceaccount/下的token和ca.crt - 本地调试时，
clientcmd.BuildConfigFromFlags()第二个参数必须是绝对路径（如"/home/user/.kube/config"），相对路径（"./kubeconfig"）在容器里一定失败 - ServiceAccount 缺少 RBAC 权限时，错误仍是 401，不是 403 —— Kubernetes 默认把无权限也返回 401，需检查
RoleBinding是否绑定了正确的 namespace 和 ServiceAccount - 不要手动拼接
rest.Config字段，比如硬编码Host或BearerToken，client-go 内部逻辑会覆盖
构建镜像时如何避免体积膨胀和安全风险
Go 静态编译不等于镜像安全，没做多阶段构建的镜像通常含完整 Go 工具链、调试符号、甚至 shell，既大又危险：
- 构建阶段用
golang:1.21，运行阶段切到alpine:latest或scratch，只 COPY 二进制文件 - 编译时加
-ldflags="-s -w"：去掉符号表和调试信息，体积可减少 30%~50% - 禁用 CGO：
CGO_ENABLED=0 GOOS=linux，避免动态链接 libc，保证 scratch 镜像可运行 - 别在最终镜像里留
apk add curl或bash—— 运维排查时临时 exec 进去是方便，但生产镜像该删就删
真正容易被忽略的是：即使用了多阶段构建，如果 COPY --from=builder 复制了整个 /app 目录而非仅 /app/main，依然会把 go.mod、测试文件等冗余内容带进去。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
