k8s集群网络(7)-service之ipvs cluster ip实现原理

在之前文章中我们介绍了基于iptable方式实现的k8s集群中cluster ip类型和node port类型service的负载均衡。其本质上是当网络数据包从pod的network namespace中通过linux veth pair设备进入到host宿主中的network namespace时，经过iptable一系列的NAT转换，把service的cluster ip和端口DNAT成pod的ip和端口。同时leverage linux iptable的random模块，实现了对pod的负载均衡，然后再交由host对目标pod的路由策略来实现将数据包发往pod。当然，这一切都是在linux内核空间实现的，和应用程序的用户空间没有关系。在这里我们主要介绍基于ipvs的cluster ip类型service的实现原理。如果对于ipvs不熟悉的同学可以浏览一下网站http://www.linuxvirtualserver.org/，大名鼎鼎的LVS负载均衡就是基于ipvs来实现的。

要实现基于ipvs的k8s网络负载均衡需要如下：

• Linux内核高于2.4.x，参考如下：

  https://en.wikipedia.org/wiki/IP_Virtual_Server

  

• 在kube-proxy网络组件的启动参数中加入--proxy-mode=ipvs，在以前文章中有所介绍

• 安装ipvsadm工具，本质是ipvsadm是用户空间的程序，用来操作和管理ipvs

安装ipvsadm工具：

yum install ipvsadmwhereis ipvsadm

我们这里是介绍cluster ip类型的service，所以我们基于以前文章里安装的应用，显示k8s集群中的cluster ip：

kubectl get service --all-namespaces

根据以前文章，数据包会从pod的network namespace通过linux veth pair设备进入host的network namespace。host开启了路由转发功能，数据先进入到了iptable的PREROUTING chain中，我们查看这个chain：

iptables -nL -t nat

据这个chain，数据包会进入到KUBE-SERVICES这个targe中。

查看KUBE-SERVICES这个target：

iptables -nL -t nat

根据KUBE-SERVICES target，数据包匹配ipset KUBE-CLUSTER-IP。ipset是linux的内核数据结构，可以存储一些ip和端口的信息，ipvs模式的集群通过在iptable中匹配ipset，这样减少了iptable中的entry数量。在这里匹配了这个ipset之后进入了KUBE-MARK-MASQ这个target。

查看KUBE-CLUSTER-IP这个ipset：

ipset list KUBE-CLUSTER-IP

这里我们看到KUBE-CLUSTER-IP这个ipset里一共有9个entry，而且也匹配了集群中cluster ip类型service的ip和端口。

根据KUBE-SERVICES target，匹配KUBE-CLUSTER-IP这个ipset的items(也就是cluster ip类型的service)会进入到KUBE-MARK-MASQ这个target中，我们查看这个target：

我们观察这个target是对所有的items做了mark标记。

经过了PREROUTING chain以及相关的target之后数据会来到INPUT chain，这是因为对于ipvs模式，会在host的network namespace里创建kube-ipvs0网络设备，并且绑定了所有的cluster ip，这样数据就可以进入到INPUT chain。

ip addr|grep kube

对于k8s集群的ipvs负载均衡来说，其核心工作就是在INPUT chain，采用NAT模式(http://www.linuxvirtualserver.org/VS-NAT.html，当然ipvs不仅仅只有NAT模式，还有更多模式，详细的资料可以到LVS项目的官方网站参考www.linuxvirtualserver.org/Documents.html)，linux操作系统网络内核会对目标ip来做转DNAT换。这里我们以service service-nginx-app做为例子，它的cluster ip是10.254.226.173，我们查看ipvs如何做DNAT

kubectl describe service service-nginx-app --namespace defaultipvsadm -L

我们看到service service-nginx-app cluster ip为10.254.226.173:80，对应两个endpoint为10.1.86.6:80和10.1.86.7:80。然后通过ipvsadm工具查看确实是ipvs将其映射成两个endpoints，并且使用round robin的分配方式，分配权重为1和1，也就是均匀的实现负载均衡。

ipvs在INPUT chain完成上述DNAT操作，然后将数据送入POSTROUTING chain，我们查看这个chain。

iptables -nL -t nat

这里我们发现数据在POSTROUTING chain会进入KUBE-POSTROUTING这个target中。

查看KUBE-POSTROUTING target：

iptables -nL -t nat

这里我们发现是对数据包做了MASQUERADE伪装，并且匹配的就是在KUBE-MARK-MASQ target中做的标记，也就是用下一跳路由所使用网路设备的ip做了SNAT操作。所以到这里我们的数据包源ip为下一跳路由所使用网路设备的ip，目标ip为10.1.86.6或者10.1.86.7(RR 1:1的负载均衡方式)，然后根据host network namespace的路由表做下一跳路由选择。

总结对于ipvs下的cluster ip的通讯方式为：

• 数据包从pod network namespace发出，进入host的network namespace，源ip为pod ip，源端口为随机端口，目标ip为cluster ip，目标port为指定port。

• 数据包在host network namespace中进入PREROUTING chain。

• 在PREROUTING chain中经过匹配ipset KUBE-CLUSTER-IP做mask标记操作。

• 在host network namespace中创建网络设备kube-ipvs0，并且绑定所有cluster ip，这样从pod发出的数据包目标ip为cluster ip，有kube-ipvs0网络设备对应，数据进入INPUT chain中。

• 数据在INPUT chain中被ipvs的内核规则修改(可由ipvsadm查看规则)，完成DNAT，然后将数据直接送入POSTROUTING chain。这时源ip为pod ip，源端口为随机端口，目标ip为映射选择的pod ip，目标port为映射选择的port。

• 数据在POSTROUTING chain中，经过KUBE-POSTROUTING target完成MASQUERADE SNAT。这时源ip为下一跳路由所使用网路设备的ip，源端口为随机端口，目标ip为映射选择的pod ip，目标port为映射选择的port。

• 数据包根据host network namespace的路由表做下一跳路由选择。