Go应用自身不提供负载均衡，需依赖Kubernetes的Service、Probe、Ingress等机制实现；健康检查必须正确暴露/healthz端点并返回200–399状态码；服务调用应使用DNS域名而非硬编码IP；连接复用、超时控制与HPA指标暴露是保障实际均衡的关键。
Go 语言本身不提供容器编排或负载均衡能力，它只是被部署的对象；真正的负载均衡由容器编排平台（如 Kubernetes）完成，Go 应用只需做好适配。
Go 服务必须正确响应健康检查
Kubernetes 的 livenessProbe 和 readinessProbe 是负载均衡路由的前提。如果 Go 服务没暴露健康端点，K8s 会持续将流量打到未就绪或已崩溃的 Pod 上。
- 用
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(200) })暴露简单健康接口 -
readinessProbe应检查依赖（如 DB 连接、下游服务），而不仅是进程存活 - 避免在
/healthz中执行耗时操作，超时默认是 1 秒，超过会触发重启或剔除 - HTTP 状态码必须为
200–399才算就绪；返回503或超时会被从 Service Endpoints 中移除
Kubernetes Service 类型决定流量分发方式
Go 应用跑在 Pod 里，真正做四层负载均衡的是 Service 对象，不是 Go 自身逻辑。
-
ClusterIP：集群内访问，默认使用 iptables/ipvs 规则做随机或连接数加权转发 -
NodePort：节点端口映射，适合调试，但不建议生产直接暴露 -
LoadBalancer：云厂商自动创建外部 LB（如 AWS ELB、阿里云 SLB），流量先到云 LB，再经 kube-proxy 转到 Pod - 若需七层（HTTP/HTTPS）路由，必须配合
Ingress+Ingress Controller（如 nginx-ingress、traefik），Go 服务无需改代码，但要确保Host或path路由规则匹配
Go 客户端调用应避免硬编码服务地址
在集群内调用其他 Go 微服务时，若写死 IP 或域名，会绕过 K8s 的 DNS 和 Service 负载均衡，导致单点压力和故障扩散。
立即学习“go语言免费学习笔记（深入）”；
- 用
http://my-service.default.svc.cluster.local:8080替代http://10.244.1.5:8080 - K8s CoreDNS 将该域名解析为 ClusterIP（虚拟 IP），再由 kube-proxy 转发到后端 Pod
- 若服务启用了 headless Service（
clusterIP: None），DNS 会直接返回所有 Pod IP，此时需客户端自行实现轮询或一致性哈希 —— 但绝大多数场景应避免 headless，除非你明确需要客户端负载均衡（如 gRPC） -
环境变量注入（如
MY_SERVICE_SERVICE_HOST）已过时，优先走 DNS
水平扩缩容与连接管理直接影响均衡效果
即使 Service 配置正确，Go 应用自身若未合理管理连接或阻塞请求，仍会导致实际负载倾斜。
- 启用 HTTP/2 并复用
*http.Client（设置Transport.MaxIdleConns、MaxIdleConnsPerHost），避免新建连接风暴 - 不要在 handler 中长时间阻塞（如同步调用慢下游、大文件处理）；用 context 控制超时，及时释放 goroutine
- HPA（Horizontal Pod Autoscaler）依赖指标（如 CPU、自定义 Prometheus 指标），Go 服务需暴露
/metrics（可用promhttp.Handler()）并确保指标真实反映负载 - 滚动更新时，确保 preStop hook 留足时间（如
sleep 10），让 kube-proxy 有窗口期摘除 Endpoint，避免 5xx
apiVersion: v1
kind: Service
metadata:
name: go-api
spec:
selector:
app: go-api
ports:
- protocol: TCP
port: 80
targetPort: 8080
type: ClusterIP真正难的不是写个能跑的 Go 服务，而是理解每个 YAML 字段如何影响流量路径，以及 Go 运行时行为怎样和 kube-proxy、CNI、Ingress 协同 —— 这些环节出一点偏差，负载均衡就变成“看起来均衡，实际全压在一个 Pod 上”。
