核心障碍是构建产物、镜像环境、pod启动行为未对齐：需禁用cgo构建静态二进制，监听0.0.0.0并配置独立健康探针，service/ingress标签与端口严格匹配，且go程序须捕获sigterm优雅退出。
直接跑通 Golang 项目到 Kubernetes 的核心障碍不是语法或 YAML 写错，而是构建产物、镜像环境、Pod 启动行为三者没对齐——CGO_ENABLED=0 没加、监听地址写成 127.0.0.1:8080、探针路径返回非 200，任一环节都会导致 Pod CrashLoopBackOff 或 Service 503。
构建静态二进制必须禁用 CGO
Alpine 或 scratch 镜像里没有 glibc，而默认 go build 启用 CGO 就会动态链接它，运行时直接报 standard_init_linux.go:228: exec user process caused: no such file or directory。
-
CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-s -w -extldflags "-static"' -o app .是安全底线，必须写在 Dockerfile 的RUN行里，不能只靠ENV - 别信“本地能跑就行”：Mac 或 Ubuntu 构建的二进制，在 Alpine/scratch 里大概率启动失败
- 用
file app检查输出：若含dynamically linked，说明 CGO 还开着；statically linked才算过关
Deployment 必须配两个独立探针且监听 0.0.0.0
Kubernetes 不看进程是否活着，只认 HTTP 返回码。共用 /health 路径、监听 127.0.0.1、探针超时太短，都会让 Pod 卡在 ContainerCreating 或反复重启。
-
livenessProbe和readinessProbe的path必须不同：/livez（只返回 200）和/readyz（检查 DB 连通性等） - Go 代码里必须用
http.ListenAndServe(":8080", nil)，写成127.0.0.1:8080会导致 Service 流量进不来，Ingress 返回 502 -
initialDelaySeconds别设太小：滚动更新时，新 Pod 还没连上 DB 就触发 readiness 检查，会被立即摘流量
Service 与 Ingress 的端口和标签必须严丝合缝
Service 找不到 Pod、Ingress 转发 503，90% 是因为 selector 标签拼错、port.name 不匹配、或 Ingress 的 host 域名没解析到控制器 IP。
-
Service.spec.selector的键值对，必须和Deployment.spec.template.metadata.labels完全一致，包括大小写和空格 -
Service.ports[0].name必须是http或http2（不是8080或留空），否则 Ingress/VirtualService 规则不生效 - Ingress 的
spec.rules.host必须小写，且 DNS A 记录已指向ingress-nginxService 的外部 IP；kubectl get svc -n ingress-nginx确认类型是LoadBalancer或NodePort
容器内必须响应 SIGTERM 并优雅退出
不处理信号，Kubernetes 发出 SIGTERM 后 Go 进程立刻终止，正在处理的 HTTP 请求被硬中断，客户端收到 connection reset 或 5xx。
- main 函数开头加：
quit := make(chan os.Signal, 1); signal.Notify(quit, os.Interrupt, syscall.SIGTERM) - 启动 server 后起 goroutine 监听：
go func() { -
Shutdown()返回后，再关闭 DB 连接池、Redis 客户端等依赖；别用os.Exit()或 panic 替代
最易被忽略的是探针路径与代码实际路由不一致——写了 /healthz 探针，但 Go 里只注册了 /health，结果 readiness 一直 failed，Pod 永远不会进入 Ready 状态。每次改完探针配置，务必 curl -v http://localhost:8080/your-probe-path 在容器内实测返回码。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
