Gin应用由K8s托管运行，部署成败取决于镜像构建方式、健康探针配置、资源限制策略三要素；漏任一环将导致滚动更新卡住、HPA不触发、Pod反复重启。
直接说结论：Gin 应用本身不“使用”K8s 部署，而是被 K8s 托管运行；真正决定部署成败的，是镜像构建方式、健康探针配置、资源限制策略这三件事。漏掉任一环，滚动更新会卡住、HPA 不会触发、Pod 反复重启。
怎么写 Dockerfile 才能在 Alpine 上跑起来
很多团队用 golang:1.21-alpine 构建，却在运行阶段切回 ubuntu:22.04——镜像体积暴涨 600MB+，还引入非必要包和漏洞。更致命的是，未禁用 CGO 会导致二进制依赖宿主机 glibc，在 Alpine 中直接报 no such file or directory 错误。
-
CGO_ENABLED=0 GOOS=linux go build -ldflags="-w -s"是硬性要求 - 多阶段构建中，build 阶段可用完整 golang 镜像，但 final 阶段必须基于
alpine或distroless - 别把
configs/目录 COPY 进镜像，应通过ConfigMap挂载，避免敏感信息泄露 - 务必用
adduser创建非 root 用户，并用USER指令切换，否则 PodSecurityPolicy 默认拒绝
为什么 /healthz 必须自己写，不能只靠端口探测
tcpSocket 探针只确认端口是否打开，但 Gin 服务可能已启动、路由未加载完成、DB 连接池未就绪——此时流量进来必然 500。真实生产环境必须用 HTTP 探针，且后端需暴露轻量端点。
- 在 Gin 中加一个简单路由：
router.GET("/healthz", func(c *gin.Context) { c.Status(200) }) -
Readiness探针建议设置初始延迟（initialDelaySeconds: 10），给 DB 连接、Redis 初始化留出时间 -
Liveness探针不要设太短（如periodSeconds: 5），否则 GC 或慢 SQL 可能误触发重启 - 避免在
/healthz里检查所有下游依赖；它只应反映本体可用性，依赖健康状态走单独的/readyz?verbose
HPA 伸缩不起作用，90% 是指标源没对齐
K8s 1.23+ 默认只支持 cpu 和 memory 两种 Resource 指标。想按 QPS 或延迟伸缩，必须部署 custom-metrics-apiserver 并配置 Prometheus Adapter。
- Gin 应用自身要暴露
/metrics（可用promhttp.Handler()），否则 Prometheus 抓不到指标 - 确认 HPA YAML 中
metrics类型：例如type: Resource对应 CPU，type: External对应网关 QPS - 若用 External 指标，确保
metricSelector.matchLabels与 ServiceMonitor 一致 -
minReplicas别设为 1——单点故障下，哪怕 CPU 飙到 100%，也不会触发扩容
gin.SetMode(gin.ReleaseMode) 必须显式调用
这是最容易被忽略的一点。Gin 默认是 DebugMode，会输出大量调试日志、开启重定向自动修复、禁用某些性能优化。生产环境不设，会导致日志刷爆、CPU 异常升高、路由行为不符合预期。
- 必须在
main()开头第一行调用：gin.SetMode(gin.ReleaseMode) - 它影响中间件执行顺序、错误处理逻辑、JSON 序列化行为（比如
time.Time格式） - 如果你用
viper加载配置，建议把gin.Mode也作为配置项读取，但最终仍需显式传入SetMode
复杂点在于：K8s 不是“部署工具”，而是运行时契约的强制执行者。你写的每行 Gin 代码、每个 Dockerfile 指令、每条探针配置，都在跟 K8s 的调度器、kubelet、HPA controller 做隐式协商。错一处，它就静默失败，不会报错，只会卡住或反复重启。
