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的路由表做下一跳路由选择。

原文地址:https://www.cnblogs.com/cheyunhua/p/15223912.html