负载均衡是保障后端服务高可用和横向扩展能力的核心手段。在传统的物理机或虚拟机集群中，LVS 长期作为高性能四层负载均衡的事实标准；而在云原生场景下，Kubernetes Service 则承担起集群内部服务发现和流量分发的职责。虽然它们都能把请求转发到多个后端实例，但在工作位置、转发原理、运维方式上存在本质区别。理解这些区别，有助于我们在不同技术栈下做出合理的架构选择。
LVS 的负载均衡实现原理与模式
LVS 全称 Linux Virtual Server，是集成在 Linux 内核中的四层负载均衡器，依托 netfilter 框架在 PREROUTING 和 INPUT 链上拦截数据包。它不修改应用层数据，仅根据目标 IP 和端口将流量调度到真实服务器（Real Server）。由于转发逻辑运行在内核态，LVS 能轻松应对十万级并发连接，且自身几乎不成为性能瓶颈。
LVS 提供了三种典型工作模式。NAT 模式下，调度器改写数据包的目标地址，回包也经由调度器，部署简单但调度器网络压力较大；DR 模式通过修改 MAC 地址将包直接送到 Real Server，响应不经过调度器，吞吐最高，但要求 Real Server 和调度器同二层网络；TUN 模式用 IP 隧道封装请求，适合跨机房，但配置繁琐。实际生产中 DR 模式使用最广。
下面是一段 LVS DR 模式的 ipvsadm 配置示例，展示了如何添加虚拟服务和真实服务器：
# 添加虚拟服务，使用轮询调度算法 ipvsadm -A -t 192.168.10.100:80 -s rr # 添加真实服务器，采用 DR 模式，权重为 1 ipvsadm -a -t 192.168.10.100:80 -r 192.168.10.11:80 -g -w 1 ipvsadm -a -t 192.168.10.100:80 -r 192.168.10.12:80 -g -w 1 # 查看当前规则 ipvsadm -Ln
从运维角度看，LVS 需要专人维护调度器高可用（通常配合 Keepalived 做主备），且 Real Server 需绑定 VIP 并抑制 ARP。这种偏底层的操作对容器环境并不友好，因为 Pod IP 动态变化，手动维护 ipvsadm 规则不可持续。
Kubernetes Service 的负载均衡机制
Kubernetes Service 是一种抽象资源，为一组动态变化的 Pod 提供稳定的访问入口。当用户创建 Service 时，控制面分配一个 ClusterIP，并通过 Endpoints 或 EndpointSlice 持续跟踪就绪的 Pod IP。真正完成转发的是节点上的 kube-proxy，它监听 API Server 变化并写入本地转发规则。
kube-proxy 早期默认使用 iptables 模式，利用 nat 表做随机转发。当后端 Pod 数量增多时，iptables 规则线性匹配会导致性能下降。因此新版本默认推荐使用 IPVS 模式，该模式底层正是复用 LVS 的 IPVS 内核模块，以哈希表管理转发，支持轮询、最小连接等算法，规则更新也更高效。
以下示例定义了一个 ClusterIP 类型的 Service，将 80 端口映射到容器的 8080：
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
selector:
app: web
ports:
- protocol: TCP
port: 80
targetPort: 8080
type: ClusterIP
除了 ClusterIP，Kubernetes 还提供 NodePort 和 LoadBalancer 类型。NodePort 在每个节点开放固定端口，LoadBalancer 则调用云厂商接口生成外部负载均衡器。这种声明式 API 让负载均衡随应用生命周期自动伸缩，无需人工干预，是它与 LVS 最显著的易用性差距。
核心差异与适用场景对比
从技术层次看，LVS 处于基础设施网络层，不感知业务实例的生命周期；Kubernetes Service 处于编排层，深度绑定 Pod 状态。当后端是固定物理机部署的传统应用时，LVS 配合 Keepalived 能提供极简且高效的四层转发。而当系统全面容器化后，Pod 随时重建，只有 Service 的自动端点同步才能避免流量丢失。
性能方面，纯 LVS 在 DR 模式下略优于 kube-proxy IPVS 模式，因为前者无额外封装；但 IPVS 模式已足够覆盖绝大多数集群规模。运维成本上，LVS 需手动或脚本维护规则，Kubernetes Service 全自动。下表归纳了两者关键维度：
| 维度 | LVS | Kubernetes Service |
|---|---|---|
| 工作位置 | 主机网络层 | 集群编排层 |
| 后端感知 | 静态配置 | 自动跟踪 Pod |
| 配置方式 | 命令行或脚本 | 声明式 YAML |
| 适用架构 | 虚拟机或物理机 | 容器化集群 |
在混合架构中，两者也常结合使用：用 LVS 作为集群入口的统一四层网关，后面接 Kubernetes 节点的 NodePort 或 LoadBalancer，再由 Service 做细粒度路由。这种分层方案兼顾了高性能与弹性，也是很多大型企业落地云原生的过渡形态。
选型建议与常见误区
不少团队在容器化初期试图把 LVS 直接指向 Pod IP，结果 Pod 重建后规则失效，引发间歇超时。正确做法是让 Service 管理后端，LVS 仅调度到固定节点端口。另一个误区是认为 Kubernetes Service 只能做四层转发，实际上配合 Ingress 或 Gateway API 可扩展七层能力，只是基础 Service 对象本身不解析 HTTP 路径。
如果业务尚未容器化且追求极致网络性能，LVS DR 加 Keepalived 仍是稳妥选择。若研发迭代快、实例伸缩频繁，则应直接使用 Kubernetes Service 的 IPVS 模式，减少人为误操作。长远来看，随着 eBPF 等新技术在 Cilium 等项目中替代 kube-proxy，Service 的实现会更轻量，但 LVS 作为底层能力仍会被间接调用。
综合而言，两者并非替代关系，而是不同技术阶段的负载均衡工具。理解 LVS 与 Kubernetes Service 的实现对比，能让我们在架构演进时清楚每一层该用什么组件，既不盲目追新，也不被旧方案拖慢效率。
LVSKubernetes_Service负载均衡修改时间：2026-08-18 13:28:30