负载均衡——LVS DR模式

目录：

IPVS简介：

尽管 Kubernetes 在版本v16中已经支持5000个节点，但使用 iptables 的 kube-proxy 实
际上是将集群扩展到5000个节点的瓶颈。 在5000节点集群中使用 NodePort 服务，如
果有2000个服务并且每个服务有10个 pod，这将在每个工作节点上至少产生20000个
iptable 记录，这可能使内核非常繁忙。

ipvs (IP Virtual Server) 实现了传输层负载均衡，也就是我们常说的4层LAN交换，作为
Linux 内核的一部分。ipvs运行在主机上，在真实服务器集群前充当负载均衡器。ipvs
可以将基于TCP和UDP的服务请求转发到真实服务器上，并使真实服务器的服务在单个
IP 地址上显示为虚拟服务。

我们知道kube-proxy支持 iptables 和 ipvs 两种模式， 在kubernetes v18 中引入了 ipvs
模式，在 v19 中处于 beta 阶段，在 v111 中已经正式可用了。iptables 模式在 v11 中
就添加支持了，从 v12版本开始 iptables 就是 kube-proxy 默认的 *** 作模式，ipvs 和
iptables 都是基于netfilter的。ipvs 会使用 iptables 进行包过滤、SNAT、masquared。
具体来说，ipvs 将使用ipset来存储需要DROP或masquared的流量的源或目标地址，
以确保 iptables 规则的数量是恒定的，这样我们就不需要关心我们有多少服务了。

启动ipvs的要求：

先前基于iptables规则表的DNAT->SNAT方式来处理外部客户端到k8s集群pod内的流量
和集群内部流量(cluster-ip到pod ip)，无需在宿主机上管理cluster-ip都由iptables来进行
管理。

使用IPVS后是需要对vs(虚拟服务也就是vip)进行管理，由于IPVS的DNAT钩子挂在
INPUT链上，因此必须要让内核识别 VIP(cluster-ip) 是本机的 IP。k8s 通过设置将
service cluster ip 绑定到虚拟网卡kube-ipvs0，其中下面的1096xx都是VIP，也就
是cluster-ip。如下图：

ipvs 会使用 iptables 进行包过滤、SNAT、masquared(伪装)。具体来说，ipvs 将使用
ipset来存储需要DROP或masquared的流量的源或目标地址，以确保 iptables 规则的
数量是恒定的，这样我们就不需要关心我们有多少服务了。

这里访问cluster ip为1096010，k8s集群内部的dns服务

1)、入口流量匹配：
数据包是通过本地协议发出的，在宿主机本地通过访问cluster-ip到后端真是的pod那
么就要伪装所有访问 Service Cluster IP 的外部流量，k8s只能在OUTPUT这个链上
来做相应的规则：
$iptables -S -tnat | grep OUTPUT

2)、入口流量引流到全局链KUBE-SERVICES中：
ipset list KUBE-CLUSTER-IP
iptables -S -tnat | grep KUBE-SERVICES

第一步中上面的数据包流入到KUBE-SERVICES该规则中目的就是让源地址不是
1024400/16，目的地址match 到 KUBE-CLUSTER-IP 的数据包打上标签。

3)、入口流量标签化处理：
将上面KUBE-SERVICES链中的流量进行打标签处理：
$iptables -S -tnat | grep KUBE-MARK-MASQ

4)、入口流量SNAT处理：
那么数据包在出去的时候一定是要经过POSTROUTING链进行SNAT即将所有来源外部
流量转换成该cluster ip的源地址。
$iptables -S -tnat | grep POSTROUTING

然后通过内部的lvs进行流量转发到后端pod上。如下图：
$ipvsadm -Ln

这里创建一个service为NodePort的nginx应用对应为nodeip:port(192168100100:30080)，
clusterip:port(1010119237:80)
$ip ad| grep ipvs

$kubectl get svc

1)、入口流量匹配：
集群外部通过node ip 访问到后端pod服务，流量肯定是先在PREROUTING链中处理：
$iptables -S -tnat | grep PREROUTING

匹配到倒数第二条就是，将流量引入到KUBE-SERVICES规则中处理。

2)、入口流量引流到全局链KUBE-SERVICES中：
$ipset list KUBE-CLUSTER-IP

$iptables -S -tnat | grep KUBE-SERVICES

第一步中上面的数据包流入到KUBE-SERVICES该规则中目的就是让源地址不是1024400/16，目的地址match 到 KUBE-CLUSTER-IP 的数据包打上标签

3)、入口流量标签化处理：
$iptables -S -tnat | grep KUBE-MARK-MASQ

4)、入口流量SNAT处理：
那么数据包在出去的时候一定是要经过POSTROUTING链进行SNAT即将所有来源外部流量转换成该cluster ip的源地址。
$iptables -S -tnat | grep POSTROUTING

iptables中POSTROUTING链最先将流量引流到KUBE-POSTROUTING中做进一步的SNAT处理
$iptables -S -tnat | grep KUBE-POSTROUTING

端口的转换
$iptables -S -tnat | grep KUBE-NODE-PORT

上面的流程进行SNAT后即将所有来源外部流量转换成该cluster ip的源地址的对应得端
口。然后通过内部的lvs进行流量转发到后端pod上。

这种的LB方式和之前分析的swarm集群中LB类似都是用lvs来直接进行负载，这比起原先使用iptables来进行负载在性能上要好的多，同时也比较清晰友好。总之一句话流量都是要先经过iptables清理一遍然后交给4层的lvs进行负载。

普通的Web开发，常用的模式就是用户登录之后，登录状态信息保存在Session中，用户一些常用的热数据保存在文件缓存中，用户上传的附件信息保存在Web服务器的某个目录上。这种方式对于一般的Web应用，使用很方便，完全能够胜任。但是对于高并发的企业级网站，就应付不了了。需要采用Web集群实现负载均衡。
使用Web集群方式部署之后，首要调整的就是用户状态信息与附件信息。用户状态不能再保存到Session中，缓存也不能用本地Web服务器的文件缓存，以及附件，也不能保存在Web服务器上了。因为要保证集群里面的各个Web服务器，状态完全一致。因此，需要将用户状态、缓存等保存到专用的缓存服务器，比如Memcache。附件需要保存到云存储中。
　Web负载均衡

Web负载均衡（Load Balancing），简单地说就是给我们的服务器集群分配“工作任务”，而采用恰当的分配方式，对于保护处于后端的Web服务器来说，非常重要。
　负载均衡的策略有很多，我们从简单的讲起。 
 
1 >

1、特点不同：lvs基于4层的网络协议的，抗负载能力强，对于服务器的硬件要求除了网卡外，其他没有太多要求。keepalived主要的工作是提供lvs控制器的一个冗余，并且对real服务器做健康检查，发现不健康的real服务器，从lvs集群中剔除，real服务器只负责提供服务。

2、性质不同：LVS是一个开源的软件，可以实现LINUX平台下的简单负载均衡。LVS是Linux Virtual Server的缩写，意思是Linux虚拟服务器。keepalived是一个类似于layer3, 4 & 5交换机制的软件。

3、作用不同：Keepalived主要用作RealServer的健康状态检查以及LoadBalance主机和BackUP主机之间failover的实现。LVS的作用是在网上能找到一些相关技术资源。

扩展资料：

注意事项：

在LVS方案中，虚拟ip地址与普通网络接口大大不同，这点需要特别注意。虚拟ip地址的广播地址是lvs本身，子网掩码是255255255255，因为有若干机器要使用同一个ip地址，用本身做广播地址和把子网掩码设成4个255就不会造成ip地址冲突了,否则lvs将不能正常转发访问请求。

假如两台VS之间使用的互备关系>

参考资料来源：百度百科-Keepalived

参考资料来源：百度百科-LVS

---