Kubernetes 负载均衡深度实践：Service 数据面到生产级流量治理全链路

来源：小随小看 | 2026-05-16 关键词：Kubernetes、Service、Ingress、IPVS、eBPF、Service Mesh、conntrack、高并发、流量治理

Kubernetes 负载均衡不是单点能力，而是一条跨越控制面、节点网络、代理层、应用层的协同链路。本文从数据面出发，系统梳理从 Service 到生产级流量治理的全链路方案。

为什么要重新理解 Kubernetes 负载均衡

很多团队对 Kubernetes 负载均衡的理解停留在"创建一个 Service，流量就会自动打到后端 Pod"。但这个认知掩盖了生产环境中最关键的问题：

• 流量到底经过了哪些组件？
• 哪一层负责"发现后端"，哪一层负责"转发请求"？
• 为什么同样是 ClusterIP，有的集群很稳，有的集群在大促时频繁抖动？
• 为什么 Pod 明明是 Ready 的，用户仍然会出现 502、超时、长尾延迟飙升？

负载均衡全链路架构

端到端请求路径

客户端 -> DNS -> 外部负载均衡 -> Ingress/Gateway API -> NodePort/ClusterIP -> kube-proxy -> Endpoints -> Pod

每一层都可能成为瓶颈或故障点。理解全链路才能设计出高可用的负载均衡体系。

四层负载均衡（L4）

• ClusterIP：集群内部虚拟 IP，通过 kube-proxy 实现流量转发
• NodePort：在每个节点开放端口，外部流量通过节点端口进入
• LoadBalancer：云厂商 LB + NodePort 组合
• ExternalName：DNS 级别的转发

七层负载均衡（L7）

• Ingress：基于 Host/Path 的 HTTP 路由，支持 TLS 终结
• Gateway API：新一代 API 网关标准，支持定向流量、灰度发布、跨命名空间路由

kube-proxy 三种数据面模式对比

iptables 的核心缺陷

• 规则链膨胀：每增加一个 Service，iptables 规则链线性增长，更新一条规则需全量 reload
• 连接跟踪压力：iptables 依赖 conntrack 模块，高并发时 conntrack 表打满导致丢包
• 随机转发：仅支持随机（random）选后端，无法实现加权或一致性哈希

IPVS 的调度算法

IPVS 支持以下调度算法，天然支持加权：

• rr（轮询）
• wrr（加权轮询）
• lc（最少连接）
• wlc（加权最少连接）
• lblc（本地最少连接）
• sh（源地址哈希）
• dh（目标地址哈希）

Ingress Controller 选型

Service Mesh 对负载均衡的影响

Service Mesh（如 Istio、Linkerd）在 Pod 级别注入 sidecar 代理，接管 Pod 的入站和出站流量。这会改变负载均衡链路：

原链路：客户端 -> Service -> kube-proxy -> Pod
Mesh 链路：客户端 -> Service -> kube-proxy -> sidecar(inbound) -> 应用容器
                        <- sidecar(outbound) <- Service <- 客户端

Mesh 带来的变化

• 流量在 sidecar 层面再做一次负载均衡，支持更精细的路由规则
• mTLS 加密：sidecar 之间自动加密，数据面零代码改动
• 可观测性：每个请求自动生成 metrics/tracing/logs
• 灰度/流量镜像：支持基于 Header/权重/延迟注入等的流量治理
• 性能代价：每次请求多一次代理转发（约 1-5ms 延迟）

conntrack 与高并发陷阱

为什么高并发时 Service 会丢包？

Kubernetes 默认 conntrack 表大小有限（nf_conntrack_max 默认 65536 或 262144）。在以下场景容易打满：

• 大量短连接：每个请求创建新连接，TIME_WAIT 堆积
• DNS 解析风暴：应用频繁解析 Service DNS 导致大量 UDP conntrack 条目
• DNAT 双倍消耗：Service 的 DNAT 使每个连接产生两条 conntrack 条目（转换前+转换后）

四步止血

1. 调大 net.netfilter.nf_conntrack_max（建议 1048576+）
2. 缩短 net.netfilter.nf_conntrack_tcp_timeout_time_wait（默认 120s → 建议 30s）
3. 启用 IPVS 模式（减少 conntrack 依赖）
4. 应用层启用连接池（减少短连接）

生产级流量治理实践

无损发布与流量迁移

• 优雅终止（Graceful Shutdown）：Pod 收到 SIGTERM 后等待已有请求完成再退出
• Readiness 探针 + preStop：先切流量再停止进程
• 连接排空（Connection Draining）：Ingress Controller 支持 draining 配置

网关层面的灰度策略

• Header 路由：根据 User-Agent/Cookie/自定义 Header 分流
• 权重路由：新版本 10% → 30% → 100%
• 镜像流量：复制请求到新版本，不影响线上

跨可用区流量治理

• Pod 级别 topologySpreadConstraints 确保跨 AZ 分布
• Ingress Controller 的 externalTrafficPolicy: Local 避免跨节点 SNAT
• 考虑 zone-aware 路由避免跨 AZ 延迟和成本

故障排查清单

Service 访问异常

1. 检查 Endpoints 是否正常：kubectl get endpoints <svc>
2. 检查 kube-proxy 模式：kubectl logs -n kube-system kube-proxy-xxx
3. 检查 iptables/IPVS 规则：
4. iptables：iptables-save | grep <svc-name>
5. IPVS：ipvsadm -Ln
6. 检查 conntrack 表：conntrack -S
7. 检查节点网络策略：calicoctl get networkpolicy
8. 抓包确认：tcpdump -i any port <svc-port>

Ingress 异常

1. 检查 Ingress Controller Pod 状态
2. 查看 Ingress 日志：kubectl logs -n ingress-nginx deploy/ingress-nginx-controller
3. 检查 Ingress 资源配置：kubectl describe ingress <name>
4. 确认 TLS 证书有效性
5. 测试后端 Service 直连是否正常

性能抖动

1. conntrack 表是否打满：sysctl net.netfilter.nf_conntrack_count
2. iptables 规则数量：iptables-save | wc -l（超过 5000 条需关注）
3. IPVS 是否启用：lsmod | grep ip_vs
4. 抓包分析长尾连接：tcpdump -i any -s 0 -w capture.pcap

关联页面