k8s集群网络(9)-service之iptables与ipvs对比

在前面的几篇文章里我们介绍了基于iptables和ipvs模式下cluster ip类型的service和node port类型的service实现原理，这里我们做一下回顾总结和对比，相关文章可以参考如下：

• service之iptable cluster ip实现原理

• service之iptable node port实现原理

• service之ipvs cluster ip实现原理

• service之ipvs node port实现原理

对于iptable方式的service：

• 流量从pod network namespace（cluster ip类型的service）或者外部(node port类型的service)进入到host netwok namespace之中。

• 在host netwok namespace的PREROUTING chain中会经过一系列target，KUBE-SERVICES(cluster ip类型的service)，KUBE-NODEPORTS (node port类型的service)，KUBE-SVC-XXX，KUBE-SEP-XXX。

• 在这些target里根据iptable内核随机模块random来实现匹配endpoint target，实现负载均衡。

• 在endpoint target(KUBE-SEP-XXX)里实现了DNAT，也就是将目标地址cluster ip转化为实际的pod的ip。

• 数据包经过以上修改根据host network namespace的路由表做下一跳路由选择。

对于ipvs方式的service：

• 流量从pod network namespace（cluster ip类型的service）或者外部(node port类型的service)进入到host netwok namespace之中。

• 对于clutser ip类型的service，在host netwok namespace的PREROUTING chain中经过匹配ipset KUBE-CLUSTER-IP做mask标记操作。

• 对于node port类型的service，在PREROUTING chain中经过匹配ipset KUBE-NODE-PORT-TCP做mask标记操作。

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

• 对于node port类型的service，由于数据包的目标ip是host的ip地址，所以也进入了host network namespace的INPUT chain中。

• 利用linux内核模块ipvs，数据在INPUT chain中被ipvs的规则修改(可由ipvsadm查看规则)，完成负载均衡和DNAT，然后将数据直接送入POSTROUTING chain。

• 数据在POSTROUTING chain中，经过KUBE-POSTROUTING target，根据之前的mark操作完成MASQUERADE SNAT。

• 数据包经过以上修改根据host network namespace的路由表做下一跳路由选择。
  

对于iptable和ipvs方式的service：

• 两者都是采用linux内核模块完成负载均衡和endpoint的映射，所有操作都在内核空间完成，没有在应用程序的用户空间。

• iptable方式依赖于linux netfilter/iptable内核模块。

• ipvs方式依赖linux netfilter/iptable模块，ipset模块，ipvs模块。

• iptable方式中，host宿主中ipatble的entry数目会随着service和对应endpoints的数目增多而增多。举个例子，比如有10个cluster ip类型的service，每个service有6个endpoints。那么在KUBE-SERVICES target中至少有10个entries(KUBE-SVC-XXX)与10个service对应，每个KUBE-SVC-XXX target中会有6个KUBE-SEP-XXX与6个endpoints来对应，每个KUBE-SEP-XXX会有2个enrties来分别做mark masq和DNAT，这样算起来至少有10*6*2=120个entries在iptable中。试想如果application中service和endpoints数目巨大，iptable entries也是非常庞大的，在一定情况下有可能带来性能上的问题。

• ipvs方式中host宿主中iptable的entry数目是固定的，因为iptable做匹配的时候会利用ipset(KUBE-CLUSTER-IP或者KUBE-NODE-PORT-TCP)来匹配，service的数目决定了ipset的大小，并不会影响iptable的大小。这样就解决了iptable模式下，entries随着service和endpoints的增多而增多的问题。

• 对于负载均衡，iptable方式采用random模块来完成负载均衡，ipvs方式支持多种负载均衡，例如round-robin，least connection，source hash等（可参考http://www.linuxvirtualserver.org/），并且由kubelet启动参数--ipvs-scheduler控制。

• 对于目标地址的映射，iptable方式采用linux原生的DNAT，ipvs方式则利用ipvs模块完成。

• ipvs方式会在host netwok namespace中创建网络设备kube-ipvs0，并且绑定了所有的cluster ip，这样保证了cluster-ip类型的service数据进入INPUT chain，从而让ipvs来完成负载均衡和目标地址的映射。

• iptable方式不会在host netwok namespace中创建额外的网络设备。

• iptable方式数据在host network namespace的chain中的路径是：PREROUTING-->FORWARDING-->POSTROUTING 

  在PREROUTING chain中完成负载均衡，mark masq和目标地址映射。
  

• ipvs方式数据在host network namespace的chain中的路径是：

  PREROUTING-->INPUT-->POSTROUTING 

  在PREROUTING chain中完成mark masq SNAT，在INPUT chain利用ipvs完成负载均衡和目标地址映射。

• iptable和ipvs方式在完成负载均衡和目标地址映射后都会根据host network namespace的路由表做下一跳路由选择。

• 关于iptable和ipvs方式的选择并没有固定答案，要根据项目的需求和实际情况而定。
  

目前先写到这里，下一篇文章里我们继续介绍k8s集群overlay网络中pod到pod的数据通讯。