1、LVS简介
LVS的IP负载均衡技术是通过IPVS模块实现的。IPVS模块是LVS集群的核心软件模块，它安装在LVS集群作为负载均衡的主节点上，虚拟出一个IP地址和端口对外提供服务。用户通过访问这个虚拟服务（VS），然后访问请求由负载均衡器（LB）调度到后端真实服务器（RS）中，由RS实际处理用户的请求给返回响应。
ipvs (IP Virtual Server) 实现了传输层负载均衡，也就是我们常说的4层LAN交换，作为 Linux 内核的一部分。ipvs运行在主机上，在真实服务器集群前充当负载均衡器。ipvs可以将基于TCP和UDP的服务请求转发到真实服务器上，并使真实服务器的服务在单个 IP 地址上显示为虚拟服务。
ipvs vs. iptables
我们知道kube-proxy支持 iptables 和 ipvs 两种模式， 在kubernetes v1.8 中引入了 ipvs 模式，在 v1.9 中处于 beta 阶段，在 v1.11 中已经正式可用了。iptables 模式在 v1.1 中就添加支持了，从 v1.2 版本开始 iptables 就是 kube-proxy 默认的操作模式，ipvs 和 iptables 都是基于netfilter的，那么 ipvs 模式和 iptables 模式之间有哪些差异呢？
- ipvs 为大型集群提供了更好的可扩展性和性能
- ipvs 支持比 iptables 更复杂的复制均衡算法（最小负载、最少连接、加权等等）
- ipvs 支持服务器健康检查和连接重试等功能
ipvs 依赖 iptables
ipvs 会使用 iptables 进行包过滤、SNAT、masquared(伪装)。具体来说，ipvs 将使用ipset来存储需要DROP或masquared的流量的源或目标地址，以确保 iptables 规则的数量是恒定的，这样我们就不需要关心我们有多少服务了。
如图所示，前端调度器虚拟出 VS（Virtual Server）监听和接收请求，真正提供服务的是后端的 Member（亦称为 RealServer 或者 RS），数个 Member 组成一个 Pool，VS 的请求分发到 Pool 上，并在 Pool 当中的 Member 之间按一定策略分发轮询。
2、 调度模式
据负载均衡器转发客户端请求以及RS返回响应机制的不同，将IPVS的转发模式分为三种：NAT，DR，FULLNAT。（还有一种IP TUNNEL模式，IP通道技术，接触比较少）
2.1 DR模式（Direct Routing）
DR模式下，客户端的请求包到达负载均衡器的虚拟服务IP端口后，负载均衡器不会改写请求包的IP和端口，但是会改写请求包的MAC地址为后端RS的MAC地址，然后将数据包转发；真实服务器处理请求后，响应包直接回给客户端，不再经过负载均衡器。所以DR模式的转发效率是最高的，特别适合下行流量较大的业务场景，比如请求视频等大文件。
DR模式的特点：
- 数据包在LB转发过程中，源/目的IP端口都不会变化
LB只是将数据包的MAC地址改写为RS的MAC地址，然后转发给相应的RS。
- 每台RS上都必须在环回网卡上绑定LB的虚拟服务IP
因为LB转发时并不会改写数据包的目的IP，所以RS收到的数据包的目的IP仍是LB的虚拟服务IP。为了保证RS能够正确处理该数据包，而不是丢弃，必须在RS的环回网卡上绑定LB的虚拟服务IP。这样RS会认为这个虚拟服务IP是自己的IP，自己是能够处理这个数据包的。否则RS会直接丢弃该数据包！
- RS上的业务进程必须监听在环回网卡的虚拟服务IP上，且端口必须和LB上的虚拟服务端口一致
因为LB不会改写数据包的目的端口，所以RS服务的监听端口必须和虚拟服务端口一致，否则RS会直接拒绝该数据包。
- RS处理完请求后，响应直接回给客户端，不再经过LB
因为RS收到的请求数据包的源IP是客户端的IP，所以理所当然RS的响应会直接回给客户端，而不会再经过LB。这时候要求RS和客户端之间的网络是可达的。
- LB和RS须位于同一个子网
因为LB在转发过程中需要改写数据包的MAC为RS的MAC地址，所以要能够查询到RS的MAC。而要获取到RS的MAC，则需要保证二者位于一个子网，否则LB只能获取到RS网关的MAC地址。
2.2 NAT模式（Network Address Translation）
NAT模式下，请求包和响应包都需要经过LB处理。当客户端的请求到达虚拟服务后，LB会对请求包做目的地址转换（DNAT），将请求包的目的IP改写为RS的IP。当收到RS的响应后，LB会对响应包做源地址转换（SNAT），将响应包的源IP改写为LB的IP。
NAT模式的特点：
- LB会修改数据包的地址
对于请求包，会进行DNAT；对于响应包，会进行SNAT。
- LB会透传客户端IP到RS（DR模式也会透传）
虽然LB在转发过程中做了NAT转换，但是因为只是做了部分地址转发，所以RS收到的请求包里是能看到客户端IP的。
- 需要将RS的默认网关地址配置为LB的浮动IP地址
因为RS收到的请求包源IP是客户端的IP，为了保证响应包在返回时能走到LB上面，所以需要将RS的默认网关地址配置为LB的虚拟服务IP地址。当然，如果客户端的IP是固定的，也可以在RS上添加明细路由指向LB的虚拟服务IP，不用改默认网关。
- LB和RS须位于同一个子网，并且客户端不能和LB/RS位于同一子网
因为需要将RS的默认网关配置为LB的虚拟服务IP地址，所以需要保证LB和RS位于同一子网。
又因为需要保证RS的响应包能走回到LB上，则客户端不能和RS位于同一子网。否则RS直接就能获取到客户端的MAC，响应包就直接回给客户端了，不会走网关，也就走不到LB上面了。这时候由于没有LB做SNAT，客户端收到的响应包源IP是RS的IP，而客户端的请求包目的IP是LB的虚拟服务IP，这时候客户端无法识别响应包，会直接丢弃。
2.3 FULLNAT模式
FULLNAT模式下，LB会对请求包和响应包都做SNAT+DNAT。
FULLNAT模式的特点：
- LB完全作为一个代理服务器
FULLNAT下，客户端感知不到RS，RS也感知不到客户端，它们都只能看到LB。此种模式和七层负载均衡有点相似，只不过不会去解析应用层协议，而是在TCP层将消息转发
- LB和RS对于组网结构没有要求
不同于NAT和DR要求LB和RS位于一个子网，FULLNAT对于组网结构没有要求。只需要保证客户端和LB、LB和RS之间网络互通即可。
三种转发模式性能从高到低：DR > NAT >FULLNAT。
虽然FULLNAT模式的性能比不上DR和NAT，但是FULLNAT模式没有组网要求，允许LB和RS部署在不同的子网中，这给运维带来了便利。并且 FULLNAT模式具有更好的可拓展性，可以通过增加更多的LB节点，提升系统整体的负载均衡能力。
3、LVS调度算法
1. 轮叫调度 rr
这种算法是最简单的，就是按依次循环的方式将请求调度到不同的服务器上，该算法最大的特点就是简单。轮询算法假设所有的服务器处理请求的能力都是一样的，调度器会将所有的请求平均分配给每个真实服务器，不管后端 RS 配置和处理能力，非常均衡地分发下去。
2. 加权轮叫 wrr
这种算法比 rr 的算法多了一个权重的概念，可以给 RS 设置权重，权重越高，那么分发的请求数越多，权重的取值范围 0 – 100。主要是对rr算法的一种优化和补充， LVS 会考虑每台服务器的性能，并给每台服务器添加要给权值，如果服务器A的权值为1，服务器B的权值为2，则调度到服务器B的请求会是服务器A的2倍。权值越高的服务器，处理的请求越多。
3. 最少链接 lc
这个算法会根据后端 RS 的连接数来决定把请求分发给谁，比如 RS1 连接数比 RS2 连接数少，那么请求就优先发给 RS1
4. 加权最少链接 wlc
这个算法比 lc 多了一个权重的概念。
5. 基于局部性的最少连接调度算法 lblc
这个算法是请求数据包的目标 IP 地址的一种调度算法，该算法先根据请求的目标 IP 地址寻找最近的该目标 IP 地址所有使用的服务器，如果这台服务器依然可用，并且有能力处理该请求，调度器会尽量选择相同的服务器，否则会继续选择其它可行的服务器
6. 复杂的基于局部性最少的连接算法 lblcr
记录的不是要给目标 IP 与一台服务器之间的连接记录，它会维护一个目标 IP 到一组服务器之间的映射关系，防止单点服务器负载过高。
7. 目标地址散列调度算法 dh
该算法是根据目标 IP 地址通过散列函数将目标 IP 与服务器建立映射关系，出现服务器不可用或负载过高的情况下，发往该目标 IP 的请求会固定发给该服务器。
8. 源地址散列调度算法 sh
与目标地址散列调度算法类似，但它是根据源地址散列算法进行静态分配固定的服务器资源。
3、使用场景
我们都知道，我们一般用nginx或者haproxy来作为我们的负载均衡，但是当并发超过nginx/haproxy上限时，就可以使用LVS了。日1000-2000W pv或并发请求1万以上可以考虑LVS+nginx/haproxy的方案，如下图所示。
4、LVS 高可用性
4.1 主播模式
在冗余方面，LVS 分别支持主备模式和集群模式。在主备模式下，LVS 可采用成熟的开源软件 Keepalived 实现冗余功能。在 LVS 主备方案实施当中，一台为主机正常提供服务，另外一台提供热备份。当主机离线时，备机会自动接管所有 VS，接替主机承担负载均衡的职责。
Keepalived 参照了 VRRP 协议实现故障切换。LVS 的 Self IP 与 F5 的 Self IP 在概念上并不相同。LVS 不需要像 F5 那样为每台设备的每个网段配置 Self IP，再配置一个不同于 Self IP 的 Float IP 对外提供服务。在 LVS 中，Self IP 直接对外提供服务，Fullnat 模式下还拥有不会随主备切换的 Local Addres。在正常情况下，主机对外宣告 Self IP，备机没有配置 IP，保持静默。如果主机发生故障，备机会在一秒钟内检测到，产生故障切换事件，通过发送免费 ARP 宣告自己拥有 Self IP，引发流量切换。
Keepalived 可以指定某个网络接口运行 VRRP 实例，为了避免 VRRP 影响现有网络，可以采用单独的心跳线传输 Failover 流量。备机通过监听 VRRP 通告确认主机是否存活，如果主备机因为意外同时 ACTIVE，会导致严重的网络故障，并且需要人为干预才能恢复。为了避免单根链路故障而导致的意外故障切换，建议心跳线采用两根链路捆绑，可以大大降低故障几率。LVS 支持人为的进行主备机倒换，但是并不具备 F5 的会话镜像功能，因此在主备机倒换和故障切换之后，所有会话的连接性都会丢失。
4.2 集群模式
集群模式采用了 LVS ospf 方案，利用开源的软路由软件 quagga，对 IDC 接入交换机宣告 VIP 的主机路由信息，通过 OSPF 等价路由的特性可以提供最多八台 LVS All-active 的集群服务。在集群模式下，LVS 可以横向扩展，自由伸缩，但是会增加网络的复杂性。
单 OSPF 区域，LVS 只能使用 DR 模式，与内网核心使用 TRUNK 连接，在每一个服务 VLAN 宣告 IP，并且所有后端服务器必须配置 LVS 为网关，对网络的要求和后端服务器的变动需求非常大。如果要使用 NAT 模式，需要 LVS 与内网核心也建立 OSPF 邻居关系，将 SNAT IP 同时宣告给内网核心。
受限于 ospf 调度算法，集群模式有可能无法提供无感知的伸缩特性。如果三层设备不支持 ospf 调度一致性 hash，那么当某台 LVS 离线的时候，所有长连接都会丢失。目前只有 Cisco 设备支持一致性 Hash 算法。
参考文档：
https://blog.csdn.net/codebay118/article/details/72630066
https://www.cnblogs.com/bananaaa/p/7929796.html