Kubernetes1.2如何使用iptables

  • Post author:
  • Post category:其他


本次分析的kubernetes版本号:v1.2.1-beta.0。

Kubernetes中kube-proxy组件负责维护NODE节点上的防火墙规则和路由规则,Kube-proxy有两种实现方式,一种是通过iptables,一种是通过userspace,在1.2中将使用iptables作为首选,可以大幅提升性能,下面看看kube-proxy组件是如何操作iptables的。

kube-proxy要求NODE节点操作系统中要具备/sys/module/br_netfilter文件,而且还要设置bridge-nf-call-iptables=1,如果不满足要求,那么kube-proxy只是将检查信息记录到日志中,kube-proxy仍然会正常运行,但是这样通过Kube-proxy设置的某些iptables规则就不会工作。

在源代码中有检查iptables版本是否低于1.4.11的校验,如果iptables版本低于1.4.11,那么不能使用-C/–check这个参数,这样可以保证kube-proxy对iptables版本的向下兼容性。

Iptables默认的数据包流向图如下图所示:

这里写图片描述

在iptables模式下,kube-proxy使用了iptables的filter表和nat表,并且对iptables的链进行了扩充,自定义了KUBE-SERVICES、KUBE-NODEPORTS、KUBE-POSTROUTING和KUBE-MARK-MASQ四个链,另外还新增了以“KUBE-SVC-”和“KUBE-SEP-”开头的数个链。

在iptables表中,通过iptables-save可以看到在filter表和nat表中创建好的这些链,下面是示例:

这里写图片描述

Kube-proxy配置iptables的过程通过syncProxyRules函数来执行的,首先在filter表和nat表中检查并创建KUBE-SERVICES和KUBE-NODEPORTS两个链,然后在filter表中插入一条iptables规则,将OUTPUT链的数据包导入KUBE-SERVICES链,另外在nat表中插入两条iptables规则,将OUTPUT链和PREROUTING链的数据包导入KUBE-SERVICES链;接着在NAT表中创建KUBE-POSTROUTING链,然后再NAT表中插入一条iptables规则,将POSTROUTING链的数据包导入KUBE-POSTROUTING链。

在iptables表中,通过iptables-save可以看到在nat表中创建好的规则,下面是这些规则的示例:

这里写图片描述

syncProxyRules函数在创建完上面iptables自定义链和规则后,调用操作系统命令iptables-save –t filter和iptables-save –t nat将filter表和nat表中内容保存到程序缓存中,在程序缓存中添加KUBE-MARK-MASQ链。

对于KUBE-MARK-MASQ链中所有规则设置了kubernetes独有MARK标记,在KUBE-POSTROUTING链中对NODE节点上匹配kubernetes独有MARK标记的数据包,进行SNAT处理。

在iptables表中,通过iptables-save可以看到在nat表中创建好的规则,下面是规则示例:

这里写图片描述

Kube-proxy接着对每个服务创建“KUBE-SVC-”链,并在nat表中将KUBE-SERVICES链中每个目标地址是service的数据包导入这个“KUBE-SVC-”链;如果service使用到了NODE节点端口,那么将KUBE-NODEPORTS链中每个目的地址是NODE节点端口的数据包导入这个“KUBE-SVC-”链;如果service没有配置endpoint,那么REJECT所有数据包,这意味着没有endpoint的service是无法被访问到的。如果service已经配置了endpoint,那么对每个endpoint创建“KUBE-SEP-”开头的链,并在“KUBE-SVC-”链中创建iptables规则,将所有“KUBE-SVC-”链中的数据包都导入“KUBE-SEP-”开头的链中,接着在每个“KUBE-SEP-”链中创建iptables规则,其中一条规则就是对所有由endpoint发出的数据包都导入KUBE-MARK-MASQ链中,如果一个service有多个endpoint,那么就采用随机方法将数据包导入不同的“KUBE-SEP-”开头的链中,其实如果一个service对应多个endpoint(相当于一个service对应多个POD),其实就意味着要实现负载均衡,默认情况下是采用随机的方法从“KUBE-SVC-”链向“KUBE-SEP-”链转发数据包,但是如果service的sessionAffinity配置成了ClientIP,那么在一定时间范围内向“KUBE-SVC-”链请求的数据包都会发给固定的“KUBE-SEP-”链,通过这种方式实现业务应用的会话保持。

接着删除程序缓存中已经不存在的“KUBE-SVC-”链和“KUBE-SEP-”链,最后添加一条iptables规则目的地址是本地的数据包导入KUBE-NODEPORTS链中。

在iptables表中,通过iptables-save可以看到在nat表中创建好的“KUBE-SVC-”链和“KUBE-SEP-”链,以及这些链中的规则,下面是这些规则示例:

这里写图片描述

如果一个service后端有多个POD,那么在iptables表中通过iptables-save可以看到,下面是使用负载均衡后的规则示例:

这里写图片描述

通过上面规则示例可以看到service如何向后端POD负载均衡分发数据包。

在负载均衡实际使用中,最常用的还有会话保持功能,也就是说一个客户端同服务器端建立会话连接之后,要保证这个会话连接,通过iptables来实现就需要使用recent模块,kube-proxy会使用“-m recent –rcheck –seconds 180 –reap”命令来实现会话保持,目前还无法配置会话保持的持续时间,因为kube-proxy在代码中写成了180秒,期待以后可以作为参数传入。

Kube-proxy将程序缓存中的iptables规则通过iptables-restore命令更新到NODE节点操作系统中。

Kube-proxy配置后的Iptables数据包流入图如下:

这里写图片描述

从这张图上可以看到,从主机网卡上得到的数据包在经过PREROUTING链的nat表时,被导入kube-proxy的KUBE-SERVICES链,然后被导入KUBE-SVC-XXX链,这里的XXX表示十六位字符,是由SHA256 算法生成哈希值后通过base32进行编码,然后取16位,最后数据包被导入KUBE-SEP-XXX,数据包被DDAT到一个POD上,然后返回到PREROUTING链中,如果不需要路由,那么发送给本地上层协议栈,否则路由出主机网卡。

下面是kubernetes环境下NODE节点、service、POD和Docker容器的示意图,用于形象的展现这四者之间的关系。

这里写图片描述

在这个kubernetes环境下有两个NODE节点,IP分别是192.168.1.100和192.168.1.101,有两个ClusterIP模式的service,IP分别是172.16.100.238和172.19.216.162,每个service对应一个POD,在每个POD中。

从上图中可以看到在每个NODE节点上都会存在service,service在物理上是不存在的,只是在iptables中,POD在物理上也是不存在的,只是一个概念,这个概念是由POD中POD容器来实现的,POD容器是物理存在的。在ClusterIP模式下,POD容器采用HOST模式创建,用户容器采用Container模式创建,也就是说用户容器同POD容器共享网络命名空间、IPC命名空间和文件系统命名空间,通过引入POD容器来实现逻辑上POD概念。

在名称是nginx的POD上,用户容器如果要访问名称是nginx2的service,经过NODE节点192.168.1.100上的iptables表路由到了NODE节点192.168.1.101上,在NODE节点192.168.1.101上通过iptables里面kube-proxy创建的规则就会目标重定向给名称是nginx2的POD,最后这个POD上面的用户容器收到访问请求。

下面是使用NodePort模式的service示意图:

这里写图片描述

如果service使用ClusterIP模式,由于service是个虚拟的概念,所以service对应的IP其实也是个虚拟IP,在真是的外部物理网络中是无法访问的,所以只能在kubernetes集群中使用,在这张图上service使用了NodePost模式,从图中就可以清楚的看到kube-proxy在NODE节点上创建端口,kubernetes默认在30000-32767之间选择端口号给service,并且建立从NODE节点上物理端口到service的iptables规则,这样kubernetes外部应用就可以通过访问NODE节点IP和端口来实现访问service的目的。



版权声明:本文为horsefoot原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。