K8s有哪些负载均衡方案？优缺点有哪些？

在Kubernetes集群中，”负载均衡”是一个被频繁提及却又容易被简化的概念。很多开发者第一反应是”Service不就是负载均衡吗”，但在实际生产环境中，流量从集群外部进入、在Pod之间分发、再到服务间调用，每一层的负载均衡机制都不相同，各自解决的问题和引入的约束也截然不同。如果不理解这些方案的边界，就容易在排障时陷入”日志一切正常但用户就是偶发失败”的困境。

本文将从流量路径出发，系统梳理K8s中主流的负载均衡方案，分析各自的优缺点与适用场景，并结合一个典型的隐性故障案例，说明负载均衡配置中容易被忽视的细节。

一、先厘清：K8s中的负载均衡分为哪几个层次

在讨论具体方案之前，有必要先建立一个分层视角。K8s的负载均衡大致可以划分为四个层次：

1. Pod级别的流量分发：由Service（配合kube-proxy或eBPF数据面）实现，工作在四层（TCP/UDP），负责将请求分发到后端Pod。
2. 集群入口的七层路由：由Ingress或Gateway API实现，基于HTTP Host、Path等规则做路由，通常再对接一个Ingress Controller。
3. 集群边界的外部负载均衡：由云厂商的负载均衡器或自建的边缘代理承担，负责把外部流量引入集群。
4. 服务间通信的负载均衡：由服务网格的数据面（Sidecar或节点级代理）实现，支持更细粒度的流量治理。

这四层并非互斥，生产环境往往是组合使用。理解每一层的职责，才能判断某个问题应该在哪一层解决。

二、Service：K8s原生的四层负载均衡

工作原理

Service是K8s最基础的负载均衡抽象。它为后端Pod提供稳定的虚拟IP（ClusterIP）和DNS名称，并通过kube-proxy将访问VIP的流量转发到选中的Pod。常见的实现模式包括iptables模式和IPVS模式。

• iptables模式：通过追加iptables规则实现DNAT，规则数量随Service和Endpoint规模线性增长，大规模集群下规则匹配开销明显。
• IPVS模式：基于内核的IPVS子系统，使用哈希表管理转发规则，在大规模Service场景下性能更优，支持更多调度算法（如轮询、最小连接数、源地址哈希等）。

优点

• 原生集成，无需额外组件，声明式配置简单。
• 提供稳定的服务发现入口，Pod扩缩容对调用方透明。
• 支持ClusterIP、NodePort、LoadBalancer等多种暴露方式。

缺点

• 仅工作在四层，无法基于HTTP路径、Header做路由。
• iptables模式下大规模集群存在性能瓶颈。
• NodePort方式会占用节点端口，端口范围有限且暴露面较大。
• 默认的请求分发不感知后端真实负载，长连接场景下容易出现分配不均。

适用场景

集群内部服务间调用、对七层路由无要求的简单暴露场景，是绝大多数服务的默认选择。

三、Ingress与Gateway API：七层入口路由

工作原理

Ingress通过声明式规则定义外部流量如何到达集群内服务，规则可以基于Host和Path匹配，并支持TLS终止。Ingress本身只是一个抽象规范，实际生效需要部署Ingress Controller（如基于Nginx、Envoy等数据面的控制器）。Gateway API则是对Ingress的演进，将资源职责拆分得更细（GatewayClass、Gateway、HTTPRoute等），支持更强的表达能力和多租户场景。

优点

• 支持基于HTTP层的精细路由，适合微服务和多租户共存。
• 集中管理TLS证书、重写、限流等入口策略。
• Gateway API具备更好的扩展性和角色分离能力。

缺点

• 引入额外的Controller组件，增加了运维复杂度和故障点。
• 不同Controller的实现差异较大，配置迁移成本高。
• Ingress注解（Annotation）生态碎片化，可移植性差。
• 控制器本身可能成为性能瓶颈，需要关注连接数与超时配置。

适用场景

需要统一南北向入口、按域名或路径分发、集中做TLS与入口治理的场景。

四、外部负载均衡器：集群边界的流量入口

工作原理

当Service以LoadBalancer类型暴露时，云环境通常会自动创建或关联一个外部负载均衡实例，将流量转发到各节点的NodePort或直接到Pod。自建环境则常用Keepalived+VIP、或部署边缘代理的方式实现类似能力。

优点

• 提供集群外可访问的稳定公网/内网入口。
• 通常具备健康检查、连接 draining 等生产能力。
• 与云基础设施集成，便于弹性伸缩和计费管理。

缺点

• 依赖基础设施能力，跨环境可移植性差。
• 每个Service一个实例的模式成本较高，需要共享入口做收敛。
• 外部负载均衡到节点的转发链路较长，需关注超时与连接复用配置。

适用场景

对外暴露服务、需要公网入口或跨VPC访问的生产业务。

五、服务网格：服务间通信的精细化负载均衡

工作原理

服务网格通过数据面代理（Sidecar或节点级代理）接管服务间流量，实现七层负载均衡、重试、熔断、流量切分等能力。控制面负责下发路由与策略配置。

优点

• 支持按权重、按Header的灰度流量切分。
• 提供连接池管理、异常点剔除、重试等治理能力。
• 负载均衡策略可细化到单个服务级别。

缺点

• 架构复杂度显著提升，Sidecar带来额外延迟和资源开销。
• 排障链路变长，需要理解代理层的行为。
• 对团队运维能力要求较高。

适用场景

大规模微服务、需要精细化流量治理和多环境灰度发布的组织。

六、一个容易被忽视的陷阱：conntrack表溢出

理解了分层之后，再看一个真实场景：服务间歇性返回503，应用日志却完全正常，没有任何error记录，重启Pod后短暂恢复，几小时后又复发。

这类问题的迷惑性在于，它把排查方向引向了应用层，而真实原因往往在数据面。一个典型根因是conntrack表溢出。

Linux的netfilter使用conntrack（连接跟踪）表记录连接状态，NAT、iptables转发都依赖它。当表项数量达到上限（由nf_conntrack_max控制）时，新连接无法被跟踪，内核会丢弃数据包，表现为连接建立失败。对于客户端而言，就是间歇性的503或超时；而请求根本没到达应用进程，自然在应用日志里看不到任何异常。

排查思路可以按以下步骤展开：

# 查看当前conntrack使用量与上限
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
# 观察是否接近上限
cat /proc/sys/net/netfilter/nf_conntrack_count

同时可以在节点上观察内核日志中是否有类似”nf_conntrack: table full, dropping packet”的记录。如果确认是表溢出，通常的处理方向包括：

• 合理调大nf_conntrack_max，并同步调整nf_conntrack_buckets；
• 缩短nf_conntrack_tcp_timeout_established等超时时间，加速表项回收；
• 排查是否存在大量短连接、连接未正确关闭或长连接泄漏；
• 在Service层面启用连接复用，减少连接建立频率。

这个案例的启示是：负载均衡链路上的每一跳都可能成为瓶颈，应用层日志正常不代表请求链路正常。 在四层转发路径上，内核参数、连接跟踪、iptables规则规模都是需要纳入容量规划的因素。

七、选型建议与实践原则

综合来看，负载均衡方案的选择应遵循以下原则：

1. 按流量方向分层设计：南北向入口与东西向服务调用分开考虑，避免用一套方案解决所有问题。
2. 规模驱动技术选型：Service数量多、连接量大的集群，优先考虑IPVS或eBPF数据面，减少iptables规则膨胀。
3. 入口统一收敛：外部负载均衡器与Ingress Controller配合，避免每个服务单独占用一个入口实例。
4. 容量规划覆盖数据面：把conntrack表、连接数、文件描述符等内核资源纳入监控与容量评估。
5. 治理能力按需引入：服务网格能力强但成本高，中小规模集群可先用Ingress+Service满足需求，再按治理复杂度渐进演进。
6. 可观测性先行：在入口、Service、Pod各层建立指标与链路追踪，避免故障定位时信息断层。

K8s的负载均衡不是单一方案的选择题，而是分层组合的设计题。理解每一层的能力边界，既能在架构设计时做出合理取舍，也能在出现”日志正常但服务异常”这类问题时，快速把排查范围从应用层收敛到数据面，少走弯路。