关于Kube-Proxy在IPVS模式下的路由问题
我们知道kube-proxy在1.8之后就增加了ipvs模式，直到我在部署1.9.1版本的Proxy时，ipvs默认仍然还在beta版本。
最近试用了一下，运行在ipvs模式下的kube-proxy大体和之前我所用的kube-router类似，但是功能反而没有kube-router支持的完善。比如对于ipvs的负载均衡策略的支持，kube-proxy是配置在启动参数当中，而kube-router是配置在svc的annotate中。相比kube-proxy的功能kube-router要更灵活一些。当然这些都不是问题，作为Kubernetes的亲儿子，这些功能应该很快都会被支持。
好了，说下最近遇到的问题吧。
背景
既然文章标题说是网络问题，下面就简单介绍下kube-proxy所在的物理机的网络环境：
| 服务器类型 | 管理网 | 容器网 | SVC网络 | 存储网 |
|---|---|---|---|---|
| Kube-Proxy | 10.17.64.0/22 | IPVLAN | 10.17.74.0/24 | 10.17.70.0/23 |
问题现象：
- 外部服务器无法ping通eth2网卡，也无法ping通svc网络。下面是我kube-proxy的环境：
kube-proxy运行在ipvs模式下，通过svc创建的Cluster都绑定在kube-ipvs0这块虚拟网卡上。
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 18:66:da:6d:b5:ac brd ff:ff:ff:ff:ff:ff
inet 10.17.64.14/22 brd 10.17.67.255 scope global eth0
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 18:66:da:6d:b5:ad brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 18:66:da:6d:b5:ae brd ff:ff:ff:ff:ff:ff
inet 10.17.74.253/24 scope global eth2
valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 18:66:da:6d:b5:af brd ff:ff:ff:ff:ff:ff
inet 10.17.70.14/23 scope global eth3
valid_lft forever preferred_lft forever
18: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether ee:16:fe:84:08:df brd ff:ff:ff:ff:ff:ff
19: kube-ipvs0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/ether 22:41:85:c1:65:54 brd ff:ff:ff:ff:ff:ff
inet 10.17.74.1/32 brd 10.17.74.1 scope global kube-ipvs0
valid_lft forever preferred_lft forever
inet 10.17.74.2/32 brd 10.17.74.2 scope global kube-ipvs0
valid_lft forever preferred_lft forever
这里可以看到我的eth2网卡和kube-ipvs0所处一个网段。由于默认网关是处于管理网，这样就出现访问SVC网络不通的尴尬场景。这里就牵扯出一个新的概念了，策略路由
简单来说策略路由，是一种可以灵活配置路由包转发的机制，可以根据配置服务器上的路由策略来选择外出包的路径。如果服务器配置了多网卡，这个时候就需要配置策略路由来调整出口的网卡。
以我这里的kube-proxy为例：
默认情况下服务器用的路由表空间是default，由于需要另加路由表，就需要在/etc/iproute2/rt_tables文件下创建一张新表，如下：
$ cat /etc/iproute2/rt_tables
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
100 eth2
添加路由策略
# 清空路由表100
ip route flush table 100
# 添加一个默认的路由表
ip route add default via 10.17.74.254 dev eth2 src 10.17.74.253 table 100
# 将来自10.17.74.253转发到table 100上处理
ip rule add from 10.17.74.253 table 100
# 查看路由表信息
ip rule list
这样就eth2网卡就能在外部被访问了。
同理，我们将来源是SVC地址的IP也转发到table 100上处理，这样SVC的地址就能在外部访问了。
总结
虽然这样能够暂时访问svc，但是毕竟不是长久之计，目前准备给社区提交解决方案。
