基于IPVS的集群内负载均衡深入解读
在Kubernetes官方博客之前的文章《Kubernetes1.11: In-Cluster Load Balancingand CoreDNS Plugin Graduate to General Availability中我们宣布了基于IPVS的集群内负载均衡已经实现了GA(General Availability)，在这篇文章中我们将详细介绍该特性的实现细节。
什么是IPVS
IPVS (IP Virtual Server)是基于Netfilter的、作为linux内核的一部分实现传输层负载均衡的技术。
IPVS集成在LVS(Linux Virtual Server)中，它在主机中运行，并在真实服务器集群前充当负载均衡器。IPVS可以将对TCP/UDP服务的请求转发给后端的真实服务器，因此IPVS天然支持Kubernetes Service。
为什么选择IPVS
随着kubernetes使用量的增长，其资源的可扩展性变得越来越重要。特别是对于使用kubernetes运行大型工作负载的开发人员或者公司来说，service的可扩展性至关重要。
kube-proxy是为service构建路由规则的模块，之前依赖iptables来实现主要service类型的支持，比如(ClusterIP和NodePort)。但是iptables很难支持上万级的service，因为iptables纯粹是为防火墙而设计的，并且底层数据结构是内核规则的列表。
kubernetes早在1.6版本就已经有能力支持5000多节点，这样基于iptables的kube-proxy就成为集群扩容到5000节点的瓶颈。举例来说，如果在一个5000节点的集群，我们创建2000个service，并且每个service有10个pod，那么我们就会在每个节点上有至少20000条iptables规则，这会导致内核非常繁忙。
基于IPVS的集群内负载均衡就可以完美的解决这个问题。IPVS是专门为负载均衡设计的，并且底层使用哈希表这种非常高效的数据结构，几乎可以允许无限扩容。
基于IPVS的kube-proxy
IPVS (IP Virtual Server)是基于Netfilter的、作为linux内核的一部分实现传输层负载均衡的技术。
IPVS集成在LVS(Linux Virtual Server)中，它在主机中运行，并在真实服务器集群前充当负载均衡器。IPVS可以将对TCP/UDP服务的请求转发给后端的真实服务器，因此IPVS天然支持Kubernetes Service。
1. 启动参数变更
启动参数：--proxy-mode。除了userspace模式和iptables模式外，现在用户可以通过--proxy-mode=ipvs使用IPVS模式。它默认使用IPVS的NAT模式，用于实现service端口映射。
启动参数：--ipvs-scheduler。引入新的kube-proxy参数以支持IPVS的负载均衡算法，用户可以通过--IPVS-scheduler配置，默认使用轮询模式(rr)。下面是另外支持的几种负载均衡算法：
• rr：轮询
• lc：最少连接数
• dh：目的地址哈希
• sh：源地址哈希
• sed：最短期望延时
• nq：从不排队
未来还可以实现通过service定义调度策略(可能是基于annotation)，覆盖kube-proxy默认的调度策略。
启动参数：-cleanup-ipvs。与iptables的--cleanup-iptables参数类似，如果设置为true，清理IPVS相关配置，以及IPVS模式创建的iptables规则。
启动参数：--ipvs-sync-period。刷新IPVS规则的最大时间间隔，必须大于0。
启动参数：--ipvs-min-sync-period。刷新IPVS规则的最小时间间隔，必须大于0。
启动参数：--ipvs-exclude-cidrs。指定一个用逗号分隔的CIDR列表，这个列表规定了IPVS刷新时不能清理的规则。因为基于IPVS的kube-proxy不能区分自身创建的规则和系统中用户自带的规则，因此如果您要使用基于IPVS的kube-proxy并且系统中原来存在一些IPVS规则，那么应该加上这个启动参数，否则系统中原来的规则会被清理掉。
2. 设计细节
a） IPVS service网络拓扑
当我们创建ClusterIP类型的service时，IPVS模式的kube-proxy会做下面几件事:
• 确认节点中的虚拟网卡，默认是kube-ipvs0
• 绑定service IP地址到虚拟网卡
• 为每个service IP地址创建IPVS虚拟服务器
下面是一个示例：
# kubectl describe svc nginx-service Name: nginx-service ... Type: ClusterIP IP: 10.102.128.4 Port: http 3080/TCP Endpoints:10.244.0.235:8080,10.244.1.237:8080 Session Affinity: None # ip addr ... 73：kube-ipvs0：<BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 1a:ce:f5:5f:c1:4d brd ff:ff:ff:ff:ff:ff inet 10.102.128.4/32 scope global kube-ipvs0 valid_lft forever preferred_lft forever # ipvsadm -ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.102.128.4:3080 rr -> 10.244.0.235:8080 Masq 1 0 0 -> 10.244.1.237:8080 Masq 1 0 0
需要注意的是，service与IPVS虚拟服务器应该是1:N的对应关系，因为service可能有多个IP地址(比如ExternalIP类型的service，就有clusterIP和ExternalIP两个地址)。而endpoint与IPVS真实服务器的对应关系应该是1:1。
删除kubernetes的service将会触发删除相应的IPVS虚拟服务器、IPVS真实服务器并且解绑虚拟网卡上的IP。
b）端口映射
IPVS有三种代理模式：NAT(masq)，IPIP 和DR，其中只有NAT模式支持端口映射。kube-proxy使用NAT模式进行端口映射，以下示例是IPVS映射service端口3080到pod端口8080：
TCP 10.102.128.4:3080 rr
-> 10.244.0.235:8080 Masq 1 0 0
-> 10.244.1.237:8080 Masq 1 0
c） 会话保持
IPVS支持会话保持，当kubernetes的service指定会话保持时，IPVS会设置超时时间，默认180分钟，下面是会话保持示例：
# kubectl describe svc nginx-service
Name: nginx-service
...
IP: 10.102.128.4
Port: http 3080/TCP
Session Affinity: ClientIP
# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.102.128.4:3080 rr persistent 10800
d） IPVS模式中的iptables和ipset
IPVS是专门为负载均衡设计的，因此IPVS自身不能实现kube-proxy的其他功能，比如包过滤、hairpin、源地址转换等。
IPVS模式会在上述场景中使用iptables，具体来说分为下面四种场景：
• kube-proxy启动参数中带有--masquerade-all=true，即所有流量作源地址转换。
• kube-proxy启动参数中指定CIDR。
• 支持LoadBalancer类型的service。
• 支持NodePort类型的service。
但是IPVS模式不会像iptables模式，创建太多iptables规则。所以我们引入了ipset来减少iptables规则。以下是IPVS模式维护的ipset表：
| ipset名称 | set成员 | 功能 |
|---|---|---|
| KUBE-CLUSTER-IP | 所有Service IP + port | 如果启动参数中加了masquerade-all=true或clusterCIDR，用来做masquerade |
| KUBE-LOOP-BACK | 所有Service IP + port + IP | 针对hairpin问题做masquerade |
| KUBE-EXTERNAL-IP | Service External IP + port | 对方问外部IP的流量做masquerade |
| KUBE-LOAD-BALANCER | lb型service的ingress IP + port | 对访问lb类型service的流量做masquerade |
| KUBE-LOAD-BALANCER-LOCAL | 规定了externalTrafficPolicy=local的lb型的service的ingress IP + port | 接收规定了externalTrafficPolicy=local的lb型service |
| KUBE-LOAD-BALANCER-FW | 规定了loadBalancerSourceRanges的lb型的service的ingress IP + port | 针对规定了loadBalancerSourceRanges的lb型service，用于过滤流量 |
| KUBE-LOAD-BALANCER-SOURCE-CIDR | lb型的service的ingress IP + port + source CIDR | 针对规定了loadBalancerSourceRanges的lb型service，用于过滤流量 |
| KUBE-NODE-PORT-TCP | NodePort型Service TCP port | 对访问NodePort(TCP)的流量作masquerade |
| KUBE-NODE-PORT-LOCAL-TCP | 规定了externalTrafficPolicy=local的NodePort型Service TCP port | 接收规定了externalTrafficPolicy=local的NodePort型service |
| KUBE-NODE-PORT-UDP | NodePort型Service UDP port | 对访问NodePort(UDP)的流量作masquerade |
| KUBE-NODE-PORT-LOCAL-UDP | 规定了externalTrafficPolicy=local的NodePort型Service UDP port | 接收规定了externalTrafficPolicy=local的NodePort型service |
通常来说，对于IPVS模式的kube-proxy，无论有多少pod/service，iptables的规则数都是固定的。
e）使用基于IPVS的kube-proxy
目前，local-up-cluster脚本，GCE部署集群脚本，kubeadm都已经支持通过环境变量KUBE_PROXY_MODE=ipvs自动部署IPVS模式的集群。
另外可以通过在kube-proxy的启动参数中添加--proxy=mode=ipvs启动IPVS模式的kube-proxy，不过需要保证事先加载了IPVS依赖的内核模块。
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
nf_conntrack_ipv4
最后，在kubernetes之前的版本中，需要通过设置特性开关SupportIPVSProxyMode来使用IPVS。在kubernetes v1.10版本中，特性开关SupportIPVSProxyMode默认开启，在1.11版本中该特性开关已经被移除。但是如果您使用kubernetes 1.10之前的版本，需要通过--feature-gates=SupportIPVSProxyMode=true开启SupportIPVSProxyMode才能正常使用IPVS
