Service的负载均衡由kube-proxy自动实现，通过Service类型（ClusterIP/NodePort/LoadBalancer）选择、标签选择器匹配Pod，并注入iptables或ipvs规则完成流量分发，整个过程对用户透明。
Service 本身不“配置负载均衡算法”，而是通过类型选择和底层组件（kube-proxy）自动实现流量分发。真正起作用的是 Service 类型 + 标签选择器 + kube-proxy 的规则注入，整个过程对用户透明。
选对 Service 类型是关键
不同场景对应不同类型，每种都自带负载均衡能力：
- ClusterIP：默认类型，仅集群内访问。kube-proxy 在每个节点写 iptables 或 IPVS 规则，把发往 ClusterIP:Port 的请求随机转发到匹配 selector 的健康 Pod（默认轮询）
-
NodePort：在所有节点上开放固定端口（如 30080），外部通过
<NodeIP>:30080访问。流量先到节点，再由 kube-proxy 转发到后端 Pod，仍走集群内负载逻辑 - LoadBalancer：云环境首选。Kubernetes 创建 Service 后，自动调用云厂商 API（如 AWS ALB、Azure Standard LB）创建外部负载均衡器，并将后端指向集群节点或直接 Pod（取决于云平台实现）
- ExternalName：不涉及负载均衡，只是 DNS CNAME 重定向，适用于对接外部服务
控制流量分发行为
默认轮询已满足多数场景，但可通过字段微调：
-
会话保持：设置
spec.sessionAffinity: ClientIP，让同一客户端 IP 的请求尽量落到同一个 Pod（适合有状态轻量场景） -
外部流量策略：对 LoadBalancer/NodePort 类型，设
externalTrafficPolicy: Local可避免跨节点转发，保留真实源 IP，同时减少跳数；设Cluster（默认）则允许跨节点调度，利用率更高 - 就绪探针必须正确配置：kube-proxy 只将流量转给通过 readinessProbe 检查的 Pod。没配或配置不合理会导致部分 Pod 被持续转发请求却无法响应
确保 kube-proxy 正常工作
它才是负载均衡的实际执行者：
- 确认运行模式：推荐使用
ipvs（性能优于 iptables），可通过kubectl get configmap -n kube-system kube-proxy -o yaml查看 mode 字段 - 检查 DaemonSet 状态：
kubectl get ds -n kube-system kube-proxy应为 READY 与 DESIRED 一致 - 节点间网络互通：Service 负载均衡依赖 Pod IP 可达，若节点网络插件（如 Calico、Cilium）异常，规则生效但转发失败
验证负载是否生效
不要只看 Service 是否创建成功，要验证实际流量分发：
- 从集群内 Pod curl Service DNS 名（如
curl http://my-svc.default.svc.cluster.local），多次请求观察响应头或日志，确认请求落到不同 Pod - 查 kube-proxy 日志：
kubectl logs -n kube-system ds/kube-proxy | grep "my-svc"，看是否有规则同步记录 - 在节点上执行
ipvsadm -ln（IPVS 模式）或iptables-save | grep my-svc（iptables 模式），确认虚拟服务条目及后端 RealServer 列表
