Go本身不部署或管理微服务，Kubernetes才是部署主体；Go只需写好服务、暴露/healthz和/readyz探针、构建轻量镜像，再确保监听:8080、标签匹配、资源限制与探针配置正确。
Go 本身不部署集群，也不管理应用；Kubernetes 才是部署和编排的主体。Go 只负责写好服务、打好镜像、暴露探针——剩下的交给 YAML 和 client-go 控制器。
Go 应用必须满足的三个运行前提
哪怕 Kubernetes 集群再健壮，你的 Go 服务没配对好，照样起不来：
-
http.ListenAndServe(":8080", nil)必须绑定:8080，不能是127.0.0.1:8080；否则 Service 流量进不来 -
livenessProbe和readinessProbe的path必须真实响应 HTTP 200，比如/healthz和/readyz；别写成/health却没实现 -
Deployment的selector.matchLabels和 Pod 模板里的template.metadata.labels必须逐字一致；差一个空格或大小写，Deployment 就找不到 Pod
client-go 连多集群时最容易踩的 transport 坑
多个集群共用一个 http.Transport 实例，会导致 TLS 连接复用错乱、超时策略互相覆盖、甚至 token 混用。这不是并发安全问题，而是连接池污染。
正确做法是为每个集群构造独立的 rest.Config，并显式设置：
-
Config.QPS = 3、Config.Burst = 6（避免压垮某个集群 API server） -
Config.Transport = &http.Transport{...}，不要复用全局 Transport - 若从 kubeconfig 加载，用
clientcmd.NewNonInteractiveDeferredLoadingClientConfig+ 自定义clientcmd.ClientConfigLoadingRules，别直接BuildConfigFromFlags("", "")
Deployment YAML 中 resource limits 不填的后果
不设 resources.limits 和 requests，Kubernetes 调度器无法判断节点是否有足够资源容纳 Pod。尤其在资源紧张的生产集群，Pod 会长期处于 Pending 状态，kubectl describe pod 显示 0/3 nodes are available: 3 Insufficient memory 或类似提示。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
更隐蔽的问题是：没设 limits 时，容器可能被 OOMKilled，但日志里只显示 Exit Code 137，看不出内存爆了。
建议值（按典型 Web 服务）：
-
requests.cpu: "100m"、limits.cpu: "500m" -
requests.memory: "128Mi"、limits.memory: "512Mi"
Ingress 配置后 502/503 的真实原因
Ingress 报 502 或 503，90% 不是 Ingress 控制器本身坏了，而是后端 Service 或 Pod 没准备好：
- Ingress 的
spec.rules.http.paths.backend.service.port.number必须和 Go 容器的containerPort一致；写成80但 Go 监听:8080，就必然 502 - Service 的
selector必须匹配 Pod label；哪怕 Deployment 里写了app: go-app，但 Service 写成app: goapp，Endpoints 就为空 - Pod 必须通过
readinessProbe；Ingress 控制器只把流量发给 Ready 状态的 Pod，probe 失败等于“不可达”
最常被忽略的是：Ingress 控制器本身是否可被外部访问。kubectl get svc -n ingress-nginx 查看它的 TYPE 是 LoadBalancer 还是 NodePort，再确认云厂商控制台或裸机防火墙是否放行了对应端口——否则域名解析再准也没用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
