kube-proxy –proxy-mode=iptables 与 rp_filter 冲突

2015年12月16日,朱鹏安装了新版kubernetes master版本(比1.1新,为1.2alpha**),然后发现,访问 clusterIP:clusterPort 会发生无法连接的故障。

从集群内Node上访问

分别在Node rz-ep19和container里执行curl访问,发现container里curl可以成功访问,但Node上一般不行(偶尔成功,几率很低)。查看iptables规则,发现新版kube-proxy已经不再将请求REDIRECT到本机kube-proxy端口,而是:

  1. 先把PREROUTING、OUTPUT无条件指向KUBE-SERVICES链;如匹配不上KUBE-SERVICES链,则再尝试匹配发给docker0
  2. 在KUBE-SERVICES链里匹配clusterIP:clusterPort条件,然后发到KUBE-SVC-***链
  3. 在KUBE-SVC-***链中,用-m statistic –mode random –probability这样的条件将流量按等比例分给多个KUBE-SEP-***链
  4. 然后再在KUBE-SEP-***链中,将数据包DNAT给endpoint

为了减少干扰,我们缩减了kube-system/elasticsearch-logging 10.16.59.73:9200服务的规模,到只有一个endpoint 172.16.86.48:9200运行在rz-ep10上;rz-ep19 10.16.49.16作为运行curl的客户端

  • 在rz-ep19的flannel接口上抓包,抓到了 10.16.49.16->172.17.86.48的TCP SYN,但没有收到回应。
  • 在rz-ep10(endpoint Pod所在的Node)的flannel接口上抓包,抓到了和上述相同的包,也没有收到回应。
  • 在rz-ep10的docker0接口上抓包,没有抓到

由此判断,rz-ep10的内核在转发时主动丢弃掉了 10.16.49.16->172.17.86.48的SYN,以至于无法建立TCP连接。查看/proc/sys/net/ipv4/conf/{all,flannel.7890}/rp_filter,发现flannel.7890/rp_filter内容为1,即在此网卡上执行“根据回溯路由检查数据包是否为伪造”的检查。因为源IP 10.16.49.16在rz-ep10看来理应出现自eth0而非flannel.7890接口,所以被判定为假造包,丢弃。

将此参数改为0,再去docker0上抓包,可以收到172.17.86.48发回10.16.49.16 SYNACK包;但rz-ep19上curl仍显示无法建立连接。

在rz-ep10的角度考虑,这个172.17.86.48->10.16.49.16的包应该从eth0发出,也就是在rz-ep19的eth0上收到。而在rz-ep19的角度考虑,源IP 172.16.86.48不应来自eth0,也会被rp_filter参数影响,丢弃掉,所以无法建立连接。把rz-ep19的eth0/rp_filter参数改为0,终于可以正常访问了。

 

plantuml9098040596798137974

 

从集群外访问

从办公区我的笔记本电脑 172.30.26.169 访问 10.16.59.67:80 服务,该虚IP被手工绑在rz-ep01上,ping可以通,但访问不通。

在笔记本电脑上抓包,发现只有从本机发往clusterIP的SYN包,没有返回,所以无法建立TCP连接。

改以Pod IP为过滤条件,发现Pod IP直接发回 SYN_ACK给我的笔记本电脑,但因为笔记本电脑这边没有发起对Pod的SYN,所以直接回复RST给Pod了。

改用iptables模式之后,由于不对称路径的问题,这种访问基本上无法以以前“把clusterIP绑在Node上”的做法实现

This entry was posted in 默认分类 and tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.