IPVS 完整详解

核心概念 IPVS（IP Virtual Server）是 Linux 内核四层负载均衡技术，基于哈希表实现高性能 Service 流量转发。

1. 基础概念

1.1. 定位

IPVS（IP Virtual Server）是 Linux 内核内置四层负载均衡模块，是 LVS 的内核转发核心，工作在 netfilter 框架之上，但独立于 iptables 四表五链体系，专门做 TCP/UDP 流量分发。
用户态管理工具：ipvsadm，用来配置虚拟服务 VS、后端真实服务器 RS。

1.2. 核心架构对象

1. VS VirtualServer 虚拟服务
   对外暴露统一 VIP:PORT，客户端只访问这个地址，对应一条负载均衡规则。
2. RS RealServer 真实后端节点
   业务真实服务地址，一台 VS 可以挂载多个 RS，配置权重、转发模式。
3. 转发三种模式：DR / NAT / TUN（隧道）
4. 独立连接跟踪表：ipvs_conn，不完全依赖系统全局 nf_conntrack。

1.3. 与 iptables 的关系

1. IPVS 是独立四层转发模块，只负责流量分发 DNAT；
2. 不具备防火墙过滤、出站 SNAT 能力，必须配合 iptables 完成：

• 后端访问外网的 MASQUERADE 源地址伪装；
• 黑白名单、端口拦截、mangle 流量标记；

3. 执行优先级：IPVS 在 PREROUTING 钩子早于 nat 表 iptables 执行，命中 VIP 流量直接走 IPVS 转发逻辑，不再遍历 iptables nat 链。

2. 三种转发模式（核心考点）

2.1. DR 直接路由模式（生产最常用）

2.1.1. 原理

• 入站包：客户端→VS(VIP)，VS 仅修改二层 MAC 地址，转发给同网段 RS；
• 出站包：RS 直接回包给客户端，回程流量不经过 VS。

2.1.2. 关键约束

1. VS 调度器与所有 RS 必须在同一二层局域网；
2. RS 本机环回 lo 需绑定 VIP，并且抑制 ARP 广播，避免多台机器同时广播VIP导致冲突：

# RS 抑制ARP
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

2.1.3. 优缺点

✅ 性能最强，VS 仅处理请求包，无带宽瓶颈；单机支撑几十万并发长连接；
❌ 同网段限制，无法跨机房跨子网。

2.2. NAT 网络地址转换模式

2.2.1. 原理

双向流量全部经过 VS：

1. 入站 PREROUTING：DNAT 修改目的IP为RS内网IP；
2. 出站 POSTROUTING：SNAT 修改源IP为VS内网IP；
3. RS 的默认网关必须指向 VS 内网网卡。

2.2.2. 优缺点

✅ 支持跨网段后端，配置简单，无需修改RS内核参数；
❌ 进出流量都过VS，大流量场景网卡带宽成为瓶颈。

2.3. TUN IPIP隧道模式

2.3.1. 原理

VS 将原始数据包封装进新IP报文，通过IPIP隧道发给跨机房RS；RS解封装处理，响应包直回客户端。

2.3.2. 优缺点

✅ 支持跨机房异地多活后端；
❌ 隧道封装有性能损耗，配置复杂，线上极少使用。

3. 十种调度算法（常用5种）

3.1. rr Round Robin 轮询

均等分发，不考虑后端性能、连接数。

3.2. wrr Weighted Round Robin 加权轮询

根据配置 weight 权重分配流量，高配机器权重更高承载更多流量。

3.3. lc Least Connections 最小连接

当前活跃连接最少的RS优先接收新连接。

3.4. wlc Weighted Least Connections（系统默认推荐）

综合 连接数 + 权重，生产标准算法，均衡性能与负载。

3.5. sh Source Hashing 源IP哈希

同一客户端源IP固定调度到同一RS，简易会话保持，适合不需要Cookie的四层长连接。

3.6. 其余小众算法（dh/dsed/nq/lblc/lblcr）

dh目的哈希、sed最短期望延迟等，Web业务几乎不用。

4. IPVS 完整工作流程（DR举例）

1. 客户端请求 VIP:PORT 到达VS网卡；
2. IPVS 匹配 VS 虚拟服务，根据调度算法选出一台 RS；
3. 二层修改MAC为RS物理网卡MAC，数据包转发至RS；
4. RS lo 绑定VIP，接收数据包处理业务；
5. RS 直接构造响应包，源IP=VIP，不经过VS，直连返回客户端。

5. 连接跟踪机制 ipvs_conn

1. IPVS 维护独立连接哈希表，存储五元组（源IP/源端口/目的IP/目的端口/协议）；
2. 四层长连接、短连接都记录超时时间，超时自动释放；
3. DR模式回程不经过VS，仅记录入站连接状态，不依赖全局nf_conntrack；
4. NAT模式双向流量经过VS，会复用部分系统conntrack逻辑。

5.1. 对比 iptables 连接跟踪优势

iptables 所有流量共用一张全局 nf_conntrack 表，高并发极易打满丢包；IPVS 连接表独立，压力隔离，大规模集群更稳定。

6. ipvsadm 核心命令实操

6.1. 查看规则

# 查看VS、RS、连接数、权重
ipvsadm -ln
# 清空所有规则
ipvsadm -C

6.2. 创建虚拟服务VS（VIP:80，wlc算法）

ipvsadm -A -t 10.0.0.100:80 -s wlc

参数：
-A 添加VS；-t tcp；-s 指定调度算法

6.3. 添加后端RS（DR模式，权重2）

ipvsadm -a -t 10.0.0.100:80 -r 192.168.1.10:80 -g -w 2

参数：
-a 添加RS；-r 后端地址；-g DR模式；-m NAT；-i TUN；-w 权重

6.4. 删除/修改RS权重

# 修改权重
ipvsadm -e -t 10.0.0.100:80 -r 192.168.1.10:80 -g -w 5
# 删除单个RS
ipvsadm -d -t 10.0.0.100:80 -r 192.168.1.10:80

6.5. 持久化保存规则（重启丢失）

# 导出
ipvsadm-save > /etc/ipvs.rules
# 开机加载
ipvsadm-restore < /etc/ipvs.rules

7. IPVS 优缺点

7.1. 优点

1. 内核态哈希表 O(1) 查找，性能碾压 iptables 线性遍历；
2. 成熟四层调度算法，支持权重、会话保持、最小连接；
3. DR 模式回程不经过调度器，无带宽瓶颈，支撑百万并发；
4. 独立连接跟踪，高并发短连接不容易出现 conntrack 表满丢包；
5. 支持 TCP/UDP 全四层流量（Redis、MySQL、游戏长连接）。

7.2. 缺点

1. 仅四层，无法解析HTTP/HTTPS七层协议，不能按域名、URL、Cookie分流；
2. 自身无健康检查、VIP漂移能力，必须配合 Keepalived；
3. 功能单一，无防火墙、SSL卸载、限流能力，依赖 iptables 补充；
4. DR 模式受二层同网段限制，跨机房部署复杂。

8. 两大典型生产落地场景

8.1. 场景1：传统IDC四层流量入口 LVS+Keepalived

1. Keepalived 实现 VRRP VIP 漂移、后端RS健康检查；
2. IPVS DR 模式做四层负载均衡，承载全站海量流量；
3. 后端HAProxy/Nginx做七层HTTPS、灰度分流。
   分层架构：客户端 → LVS(IPVS) → HAProxy → Web服务。

8.2. 场景2：K8s kube-proxy ipvs 模式

1. 集群每个节点运行 kube-proxy，调用 ipvsadm 为每个 Service 创建 VS；
2. Endpoint 对应 RS，支持加权、会话保持；
3. 相比 iptables 模式，上千 Service 时CPU、软中断压力大幅降低；
4. 限制：依然依赖 iptables 做 SNAT 出站伪装，无法处理七层网络策略。

9. IPVS vs iptables 核心区别

10. 生产避坑最佳实践

1. DR 模式 RS 必须配置 arp_ignore/arp_announce，防止VIP ARP冲突；
2. Keepalived 配合实现VIP漂移、后端健康检查，故障RS自动剔除；
3. 大规模集群默认使用 wlc 加权最小连接调度；
4. 内网四层长连接（Redis/MySQL）用 sh 源哈希实现会话保持；
5. NAT 模式注意网关指向VS，监控VS网卡带宽瓶颈；
6. K8s 集群 Service 数量大于100，推荐切换 kube-proxy ipvs 模式；
7. IPVS 仅四层，七层灰度、SSL卸载交给上层HAProxy。

11. 面试速记总结

1. IPVS 是 Linux 内核四层负载均衡模块，用户工具 ipvsadm；
2. 三种转发模式：DR（同网段高性能首选）、NAT（跨网段双向流量）、TUN（跨机房隧道）；
3. 主流调度算法 wrr/wlc/sh，哈希表查找性能远优于iptables线性规则；
4. DR模式回程流量不经过调度器，无带宽瓶颈，是IDC标准四层入口方案；
5. 自身无健康检查、VIP漂移，搭配Keepalived使用；
6. K8s kube-proxy ipvs模式解决iptables大规模性能衰减问题；
7. 仅四层转发，无七层解析能力，必须配合iptables完成SNAT、防火墙过滤。

关联文档

• iptables 完整详解
• iptables、IPVS、eBPF 完整深度对比
• kube-proxy 流量转发与代理模式详解