go服务必须监听0.0.0.0而非127.0.0.1，否则kube-proxy等组件无法访问；必须配置readinessprobe和livenessprobe且路径、端口、状态码正确；containerport须与代码监听端口严格一致；镜像需静态编译、非root运行、日志输出到stdout。
监听地址写成 127.0.0.1:8080 或没配探针，服务就只是“假运行”——Pod 状态是 Running，但请求全丢、健康检查失败、滚动更新卡住，这是最常见也最容易被忽略的部署失败原因。
Go 代码必须监听 0.0.0.0 而非 127.0.0.1
Kubernetes 的 Pod IP 是绑定在容器网卡上的独立地址，localhost 在容器内只指向自己。一旦你写 http.ListenAndServe("127.0.0.1:8080", nil)，kube-proxy、Service、Ingress、甚至同 Pod 内的 istio-proxy 都连不上。
- 正确写法是显式绑定
0.0.0.0:8080：http.ListenAndServe("0.0.0.0:8080", nil) - 更稳妥的做法是从环境变量读取端口：
port := os.Getenv("PORT"); if port == "" { port = "8080" }; http.ListenAndServe("0.0.0.0:"+port, nil) -
containerPort字段必须和这个端口一致，否则readinessProbe会报connection refused - 别依赖
:8080的默认行为——某些 Go 版本或网络栈下它仍可能 fallback 到127.0.0.1
readinessProbe 和 livenessProbe 必须分离且路径真实可访问
Kubernetes 不看进程是否活着，只认探针返回码。共用一个 /health 路径，或者路径根本没注册 handler，都会导致 Pod 卡在 Ready: 0/1 或反复重启。
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 代码里至少暴露两个独立 endpoint：
/livez（只返回 200，不查 DB）、/readyz（检查 DB 连接、下游服务等） - YAML 中
livenessProbe.httpGet.port和readinessProbe.httpGet.port必须等于containerPort，不能填 Service 的port -
initialDelaySeconds得留足启动时间：带 DB 迁移的 Go 服务建议livenessProbe≥ 30s，readinessProbe可设 5–10s - 别用 TCP 探针代替 HTTP 探针——TCP 成功只说明端口开了，不代表业务能处理请求
Dockerfile 必须禁用 CGO 并使用静态镜像
用 golang:alpine 直接运行，或忘了加 CGO_ENABLED=0，会导致容器启动时直接崩溃，日志只显示 standard_init_linux.go:228: exec user process caused: no such file or directory。
- 构建阶段必须加：
RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-s -w -extldflags "-static"' -o main . - 运行阶段推荐
FROM scratch或gcr.io/distroless/static-debian12，体积小、无 shell、无法交互式入侵 - 务必以非 root 用户运行：
USER 65532:65532，避免容器逃逸后获得高权限 - 别用
go run main.go启动，也别把编译器留在运行镜像里
Deployment 与 Service 的 label selector 必须逐字匹配
Service 流量进不去，90% 是因为 selector 和 Pod 的 labels 对不上——Kubernetes 的匹配是硬校验，空格、大小写、键名顺序错一点，就静默失败。
- Deployment 的
spec.selector.matchLabels和spec.template.metadata.labels必须完全一致，例如都写成app: go-api - Service 的
spec.selector必须和 Deployment 的matchLabels完全相同，不能多字段、不能少字段 - 别在 label 值里混用大小写或空格：
version: V2和version: v2是两个不同子集 - 如果用了 Istio 灰度，
ports[0].name必须是http或http2，否则 VirtualService 的路由规则不生效
真正卡点不在 YAML 写法，而在「监听地址 + 探针路径 + 镜像构建」三者是否对齐。哪怕只有一处写错，比如 containerPort: 8080 但代码监听 :3000，整个服务就变成不可达的黑盒——状态是 Running，日志没报错，但 curl 就是不通。这种问题必须靠 kubectl describe pod 查 Events、kubectl logs 看启动输出、curl -v http://POD_IP:PORT/healthz 手动验证三者交叉比对，才能快速定位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
