Kubernetes 关于kube-proxy转发tcp请求到pod时连接数增多问题


最近在生产环境部署了kubernetes,引了部分流量预上线。遇到不少坑(也有可能是我操作方式不当)。实际引流测试时发现几个问题

环境:


centos7
docker 1.9.2
kubernetes 1.0.3
flanned 0.5.3
1,连接数差不多翻倍
tcp        0      0 172.17.64.1:11883       172.17.64.34:1883       CLOSE_WAIT  19160/kube-proxy       
tcp        0      0 172.17.64.1:64908       172.17.64.38:1883       ESTABLISHED 19160/kube-proxy    
tcp        0      0 172.17.64.1:23767       172.17.64.32:1883       CLOSE_WAIT  19160/kube-proxy    
tcp        0      0 172.17.64.1:53714       172.17.64.36:1883       CLOSE_WAIT  19160/kube-proxy    


源IP为docker0 ip , 目的地址为pod ip

kube-proxy代理请求转发到后端pod(我起了8个)时,又重新建立了连接(难道它不能直接转发吗?google那帮人为什么要这么设计,源码看不懂),使用docker0的IP,并创建n多个端口,连接数翻了一倍不止,更要命的是,我的源IP没有了。日志里的IP都是172.17.64.1。本来还有一些针对源IP的分析和过滤功能都没发用了。究竟是我打开方式不对还是本来这个kube-proxy就是这么无语。。。。

后来在kubernetes.io上发现了一段话,看来google自己也意识到了这是个不足之处:


Using the kube-proxy obscures the source-IP of a packet accessing a Service. This makes some kinds of firewalling impossible.
kube-proxy转发时会抹掉源IP地址,如果我英语还算靠谱的话

这个问题怎么解决啊?在线急等!!!

2,大量CLOSE_WAIT状态

后面改了主机上的keep_alive参数为600,当时并没有生效,后来重启了kube-proxy,CLOSE_WAIT状态的连接数变少了。所以我也不知道是不是重启的原因,因为我现在看,又有很多CLOSE_WAIT状态的连接

3,kube-proxy性能

当机器连接数增大时(其实并不大,比普通情况部署时小很多),感觉服务就快撑不住了,查看连接:
tcp6       129     0 :::17100                :::*                    LISTEN      19160/kube-proxy


recv_Q已经堵了包了,然后服务就像挂掉了似的,不能建立新的连接了,客户端已经连不上去了,只能重启kube-proxy。NO!

总:之前也部署过kubernetes到生成环境,因为流量并不大,没有发现这么多问题。有没有什么办法能解决这些问题,除了扩节点
已邀请:

wulonghui - PaaS工程师

赞同来自: root2000xyz


经过测试kube-proxy作为7层代理性能很差,一种方法可以自己开发替换kube-proxy,另外可以试试新版本的Kube-proxy优化: iptables模式

参考:
https://github.com/kubernetes/ ... ables

gosharplite

赞同来自: root2000xyz


实际测试v1.1的kube-proxy也有iptables模式,要开启 --proxy-mode=iptables 。
确认iptables模式的方式。https://github.com/thockin/kub ... rules

难易 - 华为杭州研究院PaaS开发者

赞同来自:


目前的设计就是这样的,kube-proxy是个7层的代理,没办法换上源IP,社区已经在考虑用iptables实现4层代理了。具体的proposal还要看看,忘了在哪里了。

gosharplite

赞同来自:


是真的,Kube-proxy 的 iptables 优化模式从 v1.2.0-alpha.4 开始了。

gosharplite

赞同来自:


从这个起点希望有帮助。
https://github.com/kubernetes/ ... 97115

张涵 - codoon高级工程师

赞同来自:


谢谢大家,我准备升级下版本,使用iptables模式尝试一下,原理我还要再调研一下。就是不知道iptables靠不靠谱?我已经对kube-proxy产生怀疑了

张涵 - codoon高级工程师

赞同来自:


使用iptables模式后,连接数和CLOSE_WAIT的问题没有了,但是源IP被修改的问题还存在:
tcp        0      0 172.17.64.40:1883       172.17.64.1:56314       ESTABLISHED 16/mosquitto        
tcp        0      0 172.17.64.40:1883       172.17.64.1:12915       ESTABLISHED 16/mosquitto        
tcp        0      0 172.17.64.40:1883       172.17.64.1:62489       ESTABLISHED 16/mosquitto        
tcp        0      0 172.17.64.40:1883       172.17.64.1:58195       TIME_WAIT   -                   
tcp        0      0 172.17.64.40:1883       172.17.64.1:60898       ESTABLISHED 16/mosquitto        
tcp        0      0 172.17.64.40:1883       172.17.64.1:16620       ESTABLISHED 16/mosquitto        
tcp        0      0 172.17.64.40:1883       172.17.64.1:47931       ESTABLISHED 16/mosquitto 


这是其中一个pod的连接情况,从上面看源IP都是172.17.64.1。我使用的方式是NodePort,会不会和使用NodePort访问有关,我的NodePort是31883,现在这个端口直接变成kube-proxy的监听端口了
tcp6       0      0 :::31883                :::*                    LISTEN      8289/kube-proxy   

张涵 - codoon高级工程师

赞同来自:


问题发现了:
iptable 有这么一条rule
-A POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -m mark --mark 0x4d415351 -j MASQUERADE


kubernetes自己做了SNAT转换,其实如果只有一块网卡的话,我想还是不用这样做SNAT转换,只需要DNAT。但是为了保证可靠性,google还是转了.因为我机器上有很多路由:
0.0.0.0         120.26.19.247   0.0.0.0         UG    0      0        0 eth1
10.0.0.0        10.252.215.247  255.0.0.0       UG    0      0        0 eth0
10.252.208.0    0.0.0.0         255.255.248.0   U     0      0        0 eth0
100.64.0.0      10.252.215.247  255.192.0.0     UG    0      0        0 eth0
120.26.16.0     0.0.0.0         255.255.252.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 eth1
172.16.0.0      10.252.215.247  255.240.0.0     UG    0      0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 flannel.7890
172.17.64.0     0.0.0.0         255.255.255.0   U     0      0        0 docker0


如果不转的话,最后包找不到出口地址。不知道这部分的架构或者设计能不能改进一下

要回复问题请先登录注册