IPVS
ipvs是工作在内核态的4层负载均衡,和iptables一样都是基于内核底层netfilter实现,netfilter主要通过各个链的钩子实现包处理和转发。ipvsadm和ipvs的关系,就好比netfilter和iptables的关系,它运行在用户态,提供简单的CLI接口进行ipvs配置。
由于ipvs工作在内核态,直接基于内核处理包转发,所以最大的特点就是性能非常好。又由于它工作在4层,因此不会处理应用层数据,经常有人问ipvs能不能做SSL证书卸载、或者修改HTTP头部数据,显然这些都不可能做的。
而ipvs工作在内核态,只处理四层协议,因此只能基于路由或者NAT进行数据转发,可以把ipvs当作一个特殊的路由器网关,这个网关可以根据一定的算法自动选择下一跳,或者把ipvs当作一个多重DNAT,按照一定的算法把ip包的目标地址DNAT到其中真实服务的目标IP。针对如上两种情况分别对应ipvs的两种模式–网关模式和NAT模式,另外ipip模式则是对网关模式的扩展
用法
ipvsadm命令行用法和iptables命令行用法非常相似,毕竟是兄弟,比如-L列举,-A添加,-D删除。
1 | ipvsadm -A -t 192.168.193.172:32016 -s rr |
但是其实ipvsadm相对iptables命令简直太简单了,因为没有像iptables那样存在各种table,table嵌套各种链,链里串着一堆规则,ipvsadm就只有两个核心实体,分别为service和server,service就是一个负载均衡实例,而server就是后端member,ipvs术语中叫做real server,简称RS。
如下命令创建一个service实例172.17.0.1:32016,-t指定监听的为TCP端口,-s指定算法为轮询算法rr(Round Robin),ipvs支持简单轮询(rr)、加权轮询(wrr)、最少连接(lc)、源地址或者目标地址散列(sh、dh)等10种调度算法。
1 | ipvsadm -A -t 172.17.0.1:32016 -s rr |
然后把1x.xx.1.2:8080、1x.xx.1.3:8080、1x.xx.3.2:8080添加到service后端member中。
1 | ipvsadm -a -t 172.17.0.1:32016 -r 1x.xx.1.2:8080 -m -w 1 |
其中-t指定service实例,-r指定server地址,-w指定权值,-m即前面说的转发模式,其中-m表示为masquerading,即NAT模式,-g为gatewaying,即直连路由模式,-i为ipip,ji即IPIP隧道模式。
与iptables-save、iptables-restore对应的工具ipvs也有ipvsadm-save、ipvsadm-restore。
NAT(network access translation)模式
NAT模式由字面意思理解就是通过NAT实现的,但究竟是如何NAT转发的,我们通过实验环境验证下。
现环境中LB节点IP为192.168.193.197,三个RS节点如下:
- 192.168.193.172:30620
- 192.168.193.194:30620
- 192.168.193.226:30620
为了模拟LB节点IP和RS不在同一个网络的情况,在LB节点中添加一个虚拟IP地址:
1 | ip addr add 10.222.0.1/24 dev ens5 |
创建负载均衡Service并把RS添加到Service中:
1 | ipvsadm -A -t 10.222.0.1:8080 -s rr |
这里需要注意的是,和应用层负载均衡如haproxy、nginx不一样的是,haproxy、nginx进程是运行在用户态,因此会创建socket,本地会监听端口,而ipvs的负载是直接运行在内核态的,因此不会出现监听端口:
1 | root@ip-192-168-193-197:/var/log# netstat -lnpt |
可见并没有监听10.222.0.1:8080 Socket。
Client节点IP为192.168.193.226,为了和LB节点的虚拟IP 10.222.0.1通,我们手动添加静态路由如下:
1 | ip r add 10.222.0.1 via 192.168.193.197 dev ens5 |
此时Client节点能够ping通LB节点VIP:
1 | root@ip-192-168-193-226:~# ping -c 2 -w 2 10.222.0.1 |
可见Client节点到VIP的链路没有问题,那是否能够访问我们的Service呢?
我们验证下:
1 | root@ip-192-168-193-226:~# curl -m 2 --retry 1 -sSL 10.222.0.1:8080 |
非常意外的结果是并不通。
在RS节点抓包如下:

我们发现数据包的源IP为Client IP,目标IP为RS IP,换句话说,LB节点IPVS只做了DNAT,把目标IP改成RS IP了,而没有修改源IP。此时虽然RS和Client在同一个子网,链路连通性没有问题,但是由于Client节点发出去的包的目标IP和收到的包源IP不一致,因此会被直接丢弃,相当于给张三发信,李四回的信,显然不受信任。
既然IPVS没有给我们做SNAT,那自然想到的是我们手动做SNAT,在LB节点添加如下iptables规则:
1 | iptables -t nat -A POSTROUTING -m ipvs --vaddr 10.222.0.1 --vport 8080 -j LOG --log-prefix '[int32bit ipvs]' |
再次检查Service是否可以访问:
1 | root@ip-192-168-193-226:~# curl -m 2 --retry 1 -sSL 10.222.0.1:8080 |
服务依然不通。并且在LB节点的iptables日志为空:
1 | root@ip-192-168-193-197:~# cat /var/log/syslog | grep 'int32bit ipvs' |
也就是说,ipvs的包根本不会经过iptables nat表POSTROUTING链?
那mangle表呢?我们打开LOG查看下:
1 | iptables -t mangle -A POSTROUTING -m ipvs --vaddr 10.222.0.1 --vport 8080 -j LOG --log-prefix "[int32bit ipvs]" |
此时查看日志如下:

我们发现在mangle表中可以看到DNAT后的包。
只是可惜mangle表的POSTROUTING并不支持NAT功能:

对比Kubernetes配置发现需要设置如下系统参数:
1 | sysctl net.ipv4.vs.conntrack=1 |
再次验证:
1 | root@ip-192-168-193-226:~# curl -i 10.222.0.1:8080 |
终于通了,查看RS抓包:

如期望,修改了源IP为LB IP。
原来需要配置net.ipv4.vs.conntrack=1参数,这个问题折腾了一个晚上,不得不说目前ipvs的文档都太老了。
前面是通过手动iptables实现SNAT的,性能可能会有损耗,于是如下开源项目通过修改lvs直接做SNAT:
- 小米运维部在LVS的FULLNAT基础上,增加了SNAT网关功能,参考xiaomi-sa/dsnat
- lvs-snat
除了SNAT的办法,是否还有其他办法呢?想想我们最初的问题,Client节点发出去的包的目标IP和收到的包源IP不一致导致包被丢弃,那解决问题的办法就是把包重新引到LB节点上,只需要在所有的RS节点增加如下路由即可:
1 | ip r add 192.168.193.226 via 192.168.193.197 dev ens5 |
此时我们再次检查我们的Service是否可连接:
1 | root@ip-192-168-193-226:~# curl -i -m 2 --retry 1 -sSL 10.222.0.1:8080 |
结果没有问题。
不过我们是通过手动添加Client IP到所有RS的明细路由实现的,如果Client不固定,这种方案仍然不太可行,所以通常做法是干脆把所有RS默认路由指向LB节点,即把LB节点当作所有RS的默认网关。
由此可知,用户通过LB地址访问服务,LB节点IPVS会把用户的目标IP由LB IP改为RS IP,源IP不变,包不经过iptables的OUTPUT直接到达POSTROUTING转发出去,包回来的时候也必须先到LB节点,LB节点把目标IP再改成用户的源IP,最后转发给用户。
显然这种模式来回都需要经过LB节点,因此又称为双臂模式。
2.4 网关(Gatewaying)模式
网关模式(Gatewaying)又称为直连路由模式(Direct Routing)、透传模式,所谓透传即LB节点不会修改数据包的源IP、端口以及目标IP、端口,LB节点做的仅仅是路由转发出去,可以把LB节点看作一个特殊的路由器网关,而RS节点则是网关的下一跳,这就相当于对于同一个目标地址,会有多个下一跳,这个路由器网关的特殊之处在于能够根据一定的算法选择其中一个RS作为下一跳,达到负载均衡和冗余的效果。
既然是通过直连路由的方式转发,那显然LB节点必须与所有的RS节点在同一个子网,不能跨子网,否则路由不可达。换句话说,这种模式只支持内部负载均衡(Internal LoadBalancer)。
另外如前面所述,LB节点不会修改源端口和目标端口,因此这种模式也无法支持端口映射,换句话说LB节点监听的端口和所有RS节点监听的端口必须一致。
现在假设有LB节点IP为192.168.193.197,有三个RS节点如下:
- 192.168.193.172:30620
- 192.168.193.194:30620
- 192.168.193.226:30620
创建负载均衡Service并把RS添加到Service中:
1 | ipvsadm -A -t 192.168.193.197:30620 -s rr |
注意到我们的Service监听的端口30620和RS的端口是一样的,并且通过-g参数指定为直连路由模式(网关模式)。
Client节点IP为192.168.193.226,我们验证Service是否可连接:
1 | root@ip-192-168-193-226:~# curl -m 5 -sSL 192.168.193.197:30620 |
我们发现并不通,在其中一个RS节点192.168.193.172上抓包:

正如前面所说,LB是通过路由转发的,根据路由的原理,源MAC地址修改为LB的MAC地址,而目标MAC地址修改为RS MAC地址,相当于RS是LB的下一跳。
并且源IP和目标IP都不会修改。问题就来了,我们Client期望访问的是RS,但RS收到的目标IP却是LB的IP,发现这个目标IP并不是自己的IP,因此不会通过INPUT链转发到用户空间,这时要不直接丢弃这个包,要不根据路由再次转发到其他地方,总之两种情况都不是我们期望的结果。
那怎么办呢?为了让RS接收这个包,必须得让RS有这个目标IP才行。于是不妨在lo上添加个虚拟IP,IP地址伪装成LB IP 192.168.193.197:
1 | ifconfig lo:0 192.168.193.197/32 |
问题又来了,这就相当于有两个相同的IP,IP重复了怎么办?办法是隐藏这个虚拟网卡,不让它回复ARP,其他主机的neigh也就不可能知道有这么个网卡的存在了,参考Using arp announce/arp ignore to disable ARP。
1 | sysctl net.ipv4.conf.lo.arp_ignore=1 |
此时再次从客户端curl:
1 | root@ip-192-168-193-226:~# curl -m 2 --retry 1 -sSL 192.168.193.197:30620 |
终于通了。
我们从前面的抓包中知道,源IP为Client IP 192.168.193.226,因此直接回包给Client即可,不可能也不需要再回到LB节点了,即A->B,B->C,C->A,流量方向是三角形状的,因此这种模式又称为三角模式。
我们从原理中不难得出如下结论:
- Client、LB以及所有的RS必须在同一个子网。
- LB节点直接通过路由转发,因此性能非常高。
- 不能做端口映射。
2.5 ipip隧道模式
前面介绍了网关直连路由模式,要求所有的节点在同一个子网,而ipip隧道模式则主要解决这种限制,LB节点IP和RS可以不在同一个子网,此时需要通过ipip隧道进行传输。
现在假设有LB节点IP为192.168.193.77/25,在该节点上增加一个VIP地址:
ip addr add 192.168.193.48/25 dev eth0
有三个RS节点如下:
- 192.168.193.172:30620
- 192.168.193.194:30620
- 192.168.193.226:30620
如上三个RS节点子网掩码均为255.255.255.128,即25位子网,显然和VIP 192.168.193.48/25不在同一个子网。
创建负载均衡Service并把RS添加到Service中:
1 | ipvsadm -A -t 192.168.193.48:30620 -s rr |
注意到我们的Service监听的端口30620和RS的端口是一样的,并且通过-i参数指定为ipip隧道模式。
在所有的RS节点上加载ipip模块以及添加VIP(和直连路由类型):
1 | modprobe ipip |
Client节点IP为192.168.193.226/25,我们验证Service是否可连接:
1 | root@ip-192-168-193-226:~# curl -i -sSL 192.168.193.48:30620 |
Service可访问,我们在RS节点上抓包如下:

我们发现和直连路由一样,源IP和目标IP没有修改。
所以IPIP模式和网关(Gatewaying)模式原理基本一样,唯一不同的是网关(Gatewaying)模式要求所有的RS节点和LB节点在同一个子网,而IPIP模式则可以支持跨子网的情况,为了解决跨子网通信问题,使用了ipip隧道进行数据传输。
2.4 总结
ipvs是一个内核态的四层负载均衡,支持NAT、Gateway以及IPIP隧道模式,Gateway模式性能最好,但LB和RS不能跨子网,IPIP性能次之,通过ipip隧道解决跨网段传输问题,因此能够支持跨子网。而NAT模式没有限制,这也是唯一一种支持端口映射的模式。
我们不难猜想,由于Kubernetes Service需要使用端口映射功能,因此kube-proxy必然只能使用ipvs的NAT模式。
3 kube-proxy使用ipvs模式
3.1 配置kube-proxy使用ipvs模式
使用kubeadm安装Kubernetes可参考文档Cluster Created by Kubeadm,不过这个文档的安装配置有问题kubeadm #1182,如下官方配置不生效:
1 | kubeProxy: |
需要修改为如下配置:
1 | --- |
可以通过如下命令确认kube-proxy是否修改为ipvs:
1 | # kubectl get configmaps kube-proxy -n kube-system -o yaml | awk '/mode/{print $2}' |
3.2 Service ClusterIP原理
创建一个ClusterIP类似的Service如下:
1 | # kubectl get svc | grep kubernetes-bootcamp-v1 |
ClusterIP 1x.xx.54.11为我们查看ipvs配置如下:
1 | # ipvsadm -S -n | grep 1x.xx.54.11 |
可见ipvs的LB IP为ClusterIP,算法为rr,RS为Pod的IP。
另外我们发现使用的模式为NAT模式,这是显然的,因为除了NAT模式支持端口映射,其他两种均不支持端口映射,所以必须选择NAT模式。
由前面的理论知识,ipvs的VIP必须在本地存在,我们可以验证:
1 | # ip addr show kube-ipvs0 |
可见kube-proxy首先会创建一个dummy虚拟网卡kube-ipvs0,然后把所有的Service IP添加到kube-ipvs0中。
(dummy网卡是内核虚拟出来的网卡)
我们知道基于iptables的Service,ClusterIP是一个虚拟的IP,因此这个IP是ping不通的,但ipvs中这个IP是在每个节点上真实存在的,因此可以ping通:

当然由于这个IP就是配置在本地虚拟网卡上,所以对诊断问题没有一点用处的。
我们接下来研究下ClusterIP如何传递的。
当我们通过如下命令连接服务时:
1 | curl 1x.xx.54.11:8080 |
此时由于1x.xx.54.11就在本地,所以会以这个IP作为出口地址,即源IP和目标IP都是1x.xx.54.11,此时相当于:
1 | 1x.xx.54.11:xxxx -> 1x.xx.54.11:8080 |
其中xxxx为随机端口。
然后经过ipvs,ipvs会从RS ip列中选择其中一个Pod ip作为目标IP,假设为1x.xx.2.2:
1 | 1x.xx.54.11:xxxx -> 1x.xx.54.11:8080 |
我们从iptables LOG可以验证:

我们查看OUTPUT安全组规则如下:
1 | -A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES |
其中ipset集合KUBE-CLUSTER-IP保存着所有的ClusterIP以及监听端口。
如上规则的意思就是除了Pod以外访问ClusterIP的包都打上0x4000/0x4000。
到了POSTROUTING链:
1 | -A POSTROUTING -m comment --comment "kubernetes postrouting rules" -j KUBE-POSTROUTING |
如上规则的意思就是只要匹配mark0x4000/0x4000的包都做SNAT,由于1x.xx.2.2是从flannel.1出去的,因此源ip会改成flannel.1的ip 1x.xx.0.0:
1 | 1x.xx.54.11:xxxx -> 1x.xx.54.11:8080 |
最后通过Vxlan 隧道发到Pod的Node上,转发给Pod的veth,回包通过路由到达源Node节点,源Node节点通过之前的MASQUERADE再把目标IP还原为1x.xx.54.11。
3.3 NodePort实现原理
查看Service如下:
1 | root@ip-192-168-193-172:~# kubectl get svc |
Service kubernetes-bootcamp-v1的NodePort为32016。
现在假设集群外的一个IP 192.168.193.197访问192.168.193.172:32016:
1 | 192.168.193.197:xxxx -> 192.168.193.172:32016 |
最先到达PREROUTING链:
1 | -A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES |
如上4条规则看起来复杂,其实就做一件事,如果目标地址为NodeIP,则把包标记0x4000,0x4000。
我们查看ipvs:
1 | # ipvsadm -S -n | grep 32016 |
我们发现和ClusterIP实现原理非常相似,ipvs Service的VIP为Node IP,端口为NodePort。ipvs会选择其中一个Pod IP作为DNAT目标,这里假设为1x.xx.3.2:
1 | 192.168.193.197:xxxx -> 192.168.193.172:32016 |
剩下的到了POSTROUTING链就和Service ClusterIP完全一样了,只要匹配0x4000/0x4000的包就会做SNAT。
3.4 总结
Kubernetes的ClusterIP和NodePort都是通过ipvs service实现的,Pod当作ipvs service的server,通过NAT MQSQ实现转发。
简单来说kube-proxy主要在所有的Node节点做如下三件事:
- 如果没有dummy类型虚拟网卡,则创建一个,默认名称为
kube-ipvs0; - 把Kubernetes ClusterIP地址添加到
kube-ipvs0,同时添加到ipset中。 - 创建ipvs service,ipvs service地址为ClusterIP以及Cluster Port,ipvs server为所有的Endpoint地址,即Pod IP及端口。
使用ipvs作为kube-proxy后端,不仅提高了转发性能,结合ipset还使iptables规则变得更“干净”清楚,从此再也不怕iptables。
更多关于kube-proxy ipvs参考IPVS-Based In-Cluster Load Balancing Deep Dive.



























