多环境下的Kubernetes网络打通方案研究

发表于 | 更新于 | 分类于 | 评论数： | Views：
本文字数： 29k | 阅读时长 ≈ 27 分钟

前言

本文中的Kubernetes集群统称为集群。

现实的工作环境中，我们可能会在开发环境使用Kubernetes，也会在测试和开发环境使用Kubernetes。而一般来说，大部分人不会直接去连接或访问生产环境的集群，但是对于开发环境就不一样了。很多开发人员需要经常访问开发环境，而不是在本地起一堆依赖的服务。而且真的只有这么一个问题吗？

常见问题

整理了若干常见的问题：

  1. 开发人员本地服务访问开发环境
  2. 新集群和旧集群的网络互通，或者迁移
  3. 域名访问

因此，我们需要解决以上问题，才能更安心的使用Kubernetes。

网络互通

首先来解决最主要的问题，如何实现不同网络环境下的互通问题？

众所周知，集群暴露服务的方式有以下几种：

  1. NodePort 每个服务维护一个端口，服务越多端口越多
  2. LoadBalancer 在nodePort的基础上使用公有云的负载均衡器
  3. ClusterIP 每个service有一个虚拟IP
  4. Ingress 一个服务暴露多个service的服务，本质是一种路由转发机制

场景一、注册中心eureka的应用

首先eureka可以使用StatefulSet的方式，实现一个集群的部署。以下文件可以直接使用：

1. 办公网访问应用

开发人员本地访问的时候可以使用NodePort的方式访问，也可以使用Ingress的方式访问。

1651052056989.png

如图所示，创建了两个Python的应用，并注册到eureka。代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#!/usr/bin/python
# -*- coding: UTF-8 -*-
"""
@time:2022/04/27
@file:test_eureka.py
@author:medivh
@IDE:PyCharm 
"""
from flask import Flask
import py_eureka_client.eureka_client as eureka_client

app = Flask(__name__)


def setEureka():
    eureka_client.init(eureka_server="http://192.168.1.217:31331/eureka",
                       app_name="flask_server-2",
                       # 当前组件的主机名，可选参数，如果不填写会自动计算一个，如果服务和 eureka 服务器部署在同一台机器，请必须填写，否则会计算出 127.0.0.1
                       instance_host='10.1.3.141',
                       instance_port=5001,
                       # 调用其他服务时的高可用策略，可选，默认为随机
                       ha_strategy=eureka_client.HA_STRATEGY_RANDOM)


setEureka()


@app.route('/')
def hello_world():
    return 'Hello World!'


@app.route('/info')
def hello_info():
    return 'Hello Info!'


if __name__ == '__main__':
    app.run(debug=True, threaded=True, port=5001, host="0.0.0.0")

另外一个测试脚本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
#!/usr/bin/python
# -*- coding: UTF-8 -*-
"""
@time:2022/04/27
@file:test_eureka-service.py
@author:medivh
@IDE:PyCharm 
"""
import py_eureka_client.eureka_client as eureka_client
import json

eureka_client.init(eureka_server="http://192.168.1.109:31331/eureka", app_name='do_service', instance_host="10.1.3.141",
                   instance_port=5011)
# get请求的调用
res = eureka_client.do_service("flask_server-2", "/info",
                               # 返回类型，默认为 `string`，可以传入 `json`，如果传入值是 `json`，那么该方法会返回一个 `dict` 对象
                               return_type="string")
print(res)
res = eureka_client.do_service("O2O-SERVICE", "/env-path/actuator/info",
                               # 返回类型，默认为 `string`，可以传入 `json`，如果传入值是 `json`，那么该方法会返回一个 `dict` 对象
                               return_type="string")
print(res)
## post请求的调用
# d = {'a': 1}
# res = eureka_client.do_service('helloindex', '/user', return_type='string', method='POST', data=json.dumps(d))
# print(res)
res = eureka_client.do_service("O2O-SERVICE", "/env-path/actuator/info",
                               # 返回类型，默认为 `string`，可以传入 `json`，如果传入值是 `json`，那么该方法会返回一个 `dict` 对象
                               return_type="string")
print(res)

调用测试结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
python test_eureka-service.py
Hello Info!

Traceback (most recent call last):
  File "/Users/medivh/github/box/test_eureka-service.py", line 19, in <module>
    res = eureka_client.do_service("O2O-SERVICE", "/",
  File "/Users/medivh/github/box/venv/lib/python3.8/site-packages/py_eureka_client/eureka_client.py", line 1736, in do_service
    return cli.do_service(app_name=app_name, service=service, return_type=return_type,
  File "/Users/medivh/github/box/venv/lib/python3.8/site-packages/py_eureka_client/eureka_client.py", line 1467, in do_service
    return self.walk_nodes(app_name, service, prefer_ip, prefer_https, walk_using_urllib)
  File "/Users/medivh/github/box/venv/lib/python3.8/site-packages/py_eureka_client/eureka_client.py", line 1415, in walk_nodes
    raise http_client.URLError("Try all up instances in registry, but all fail")
urllib.error.URLError: <urlopen error Try all up instances in registry, but all fail>
[2022-04-27 17:32:39]-[eureka_client]-[line:1409] -WARNING: do service / in node [o2o-service-287077292-hj7q7:o2o-service:8080] error, use next node. Error: <urlopen error timed out>

这个时候说明注册中心是可以正常使用的，但是如果调用集群的服务就无法访问了，毕竟不在一个网段，也没有合适的路由。接下来就去解决这个问题。

2.办公网访问集群Pod/Service

在网关和路由器上添加路由，把属于集群的Pod和Service的子网IP全部转发给其中某个node，这样访问Pod IP和Service IP，网络包会到达某个node，而集群内的node中，CNI会与这些目的地址互通。

网段：

网段名称 网段范围
办公网段 10.1.3.0/24
Pod地址池 10.200.0.0/16
Svc地址池 10.96.0.0/12

如果不记得当时设置的网段是多少，可以用以下方式查询：

1
2
3
4
~ kubectl get cm kubeadm-config -n kube-system -o yaml | grep -i podsub
      podSubnet: 10.200.0.0/16
~ kubectl get cm kubeadm-config -n kube-system -o yaml | grep -i servicesub
      serviceSubnet: 10.96.0.0/12
steps 1

选择集群中的一个节点进行路由转发，可以使用一台配置不高的节点，打上污点不允许调度占用资源。本文中使用的是master节点。

  1. 设置污点 kubectl taint nodes k8s-master forward=k8s-node5:NoSchedule
  2. 开启路由转发 echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
  3. 查看是否生效 sysctl -p
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 开启转发
~ vim /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
~ sysctl -p
 
# 在k8s-master上设置snat
~ iptables -t nat -A POSTROUTING -s 10.200.0.0/16  -d 10.1.3.0/24   -j MASQUERADE
~ iptables -t nat -A POSTROUTING -s 10.96.0.0/12 -d 110.1.3.0/24   -j MASQUERADE
 
# (可选)查看设置的snat
~ iptables -t nat -L -n --line-numbers | grep -A 10 "Chain POSTROUTING"
Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination        
1    ......
2    ......
3    ......
4    MASQUERADE  all  --  10.1.3.0/24          10.200.0.0/16
5    MASQUERADE  all  --  10.1.3.0/24          10.96.0.0/12

# (可选)如配置失误可删除已设置的snat条目
~ iptables -t nat -D POSTROUTING 4
setps 2

在办公网的出口路由上设置静态路由，将集群的Pod和Service网段，路由到master节点。

1
2
3
# 在路由器上需要做的配置：
ip route add -net  10.200.0.0/16 gw 192.168.1.109
ip route add -net  10.96.0.0/12 gw 192.168.1.109

1651115644098.png

setps 3

这个时候在办公网主机上ping 集群中的Pod或者service的IP，理论上就是通的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Pod 
➜  ~ traceroute 10.200.96.148
traceroute to 10.200.96.148 (10.200.96.148), 64 hops max, 52 byte packets
 1  10.1.3.1 (10.1.3.1)  2.781 ms  2.422 ms  2.388 ms
 2  bogon (192.168.1.109)  2.723 ms  3.352 ms  3.647 ms
 3  bogon (10.200.96.128)  3.724 ms  3.485 ms  3.417 ms
 4  10.200.96.148 (10.200.96.148)  3.551 ms  3.440 ms  3.390 ms

 # service 

 ➜  ~ traceroute 10.96.230.195
traceroute to 10.96.230.195 (10.96.230.195), 64 hops max, 52 byte packets
 1  10.1.3.1 (10.1.3.1)  5.698 ms  2.482 ms  2.375 ms
 2  10.96.230.195 (10.96.230.195)  2.774 ms  2.807 ms  2.834 ms
问题总结

如果以上操作都执行了，但是还是不通，请检查以下项目：

  1. 转发是否开启
  2. iptables的规则是否正确
  3. iptables规则是否有MASQUERADE all -- 192.168.1.0/24 0.0.0.0/0 这么一条

至此，解决了开发人员无法在办公网访问集群环境的IP问题。

跨集群访问

如果我们有多个集群，这个时候如果实现网络打通呢，比如新旧集群迁移的时候？

以IP形式访问

其实我们依然可以采用之前的方案，添加静态路由。

网段：

网段名称 网段范围
办公网段 10.1.3.0/24
集群A Pod地址池 10.200.0.0/16
集群A Svc地址池 10.96.0.0/12
集群B Pod地址池 10.100.0.0/16
集群B Svc地址池 10.254.0.0/16

主要实现逻辑是每个集群选择一个节点，开启路由转发，实现办公网段可以访问集群中的IP。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
~ iptables -t nat -A POSTROUTING -s 10.1.3.0/24 -d 10.254.0.0/16 -j MASQUERADE -w
~ iptables -t nat -A POSTROUTING -s 10.1.3.0/24 -d 10.100.0.0/16 -j MASQUERADE -w
~ iptables -t nat -L -n --line-numbers | grep -A 10 "Chain POSTROUTING"
Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    MASQUERADE  all  --  10.100.72.0/24       0.0.0.0/0
2    KUBE-POSTROUTING  all  --  0.0.0.0/0            0.0.0.0/0            /* kubernetes postrouting rules */
3    MASQUERADE  all  --  10.1.3.0/24          10.254.0.0/16
4    MASQUERADE  all  --  10.1.3.0/24          10.100.0.0/16

Chain DOCKER (2 references)
num  target     prot opt source               destination
1    RETURN     all  --  0.0.0.0/0            0.0.0.0/0

~ iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 0.0.0.0/0  -j MASQUERADE

验证：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 办公网
➜  ~ traceroute 10.100.5.7
traceroute to 10.100.5.7 (10.100.5.7), 64 hops max, 52 byte packets
 1  bogon (10.1.3.1)  2.699 ms  2.201 ms  2.140 ms
 2  *.demo.yourdomain.com (192.168.1.243)  2.213 ms  7.957 ms  7.389 ms
 3  bogon (10.100.5.0)  2.902 ms  4.637 ms  2.616 ms
 4  bogon (10.100.5.7)  4.109 ms  3.944 ms  2.782 ms

 # A集群到B集群
~ tracepath 10.100.5.7
 1?: [LOCALHOST]                                         pmtu 1500
 1:  gateway                                               0.365ms
 1:  gateway                                               2.044ms
 2:  192.168.1.243                                         0.767ms
 3:  192.168.1.243                                         0.848ms pmtu 1450
 3:  10.100.5.0                                            1.536ms
 4:  10.100.5.7                                            1.382ms reached

办公网通过注册中心调用

1651117439545.png

以域名形式访问Service

实现了办公网和集群的网络互通后，就可以实现自由访问Pod和Service了。但是由于Pod IP会经常变化，Service IP也不是很容易记住，所以希望通过内网DNS的形式访问*.cluser.local时自动解析相应的IP。

steps 1. 获取coredns的IP

1
2
3
~ kubectl get svc -n kube-system -l k8s-app=kube-dns
NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
kube-dns   ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   34d

steps 2. 部署DNS服务dnsmasq

1
yum install dnsmasq

修改/etc/dnsmasq.conf：

1
2
3
4
5
6
resolv-file=/etc/resolv.dnsmasq.conf   #指定上游dns服务器
strict-order   #严格按照resolv-file文件中的顺序进行从上到下解析，直到成功为止
server=/cluster.local/10.96.0.10  #指定以cluster.local为后缀的域名，使用coredns的地址解析,这里可以不配直接把coredns配置在/etc/resolv.dnsmasq.conf 里面。
listen-address=192.168.1.109   #指定本地IP地址
addn-hosts=/etc/dnsmasq.hosts   #自定义dns记录文件
conf-dir=/etc/dnsmasq.d    #所有的解析记录都会存在此目录下

修改resolv.dnsmasq.conf

1
2
3
nameserver 61.139.2.69
nameserver 202.106.0.20
nameserver 192.168.1.109

开机并启动：

1
systemctl enable dnsmasq && systemctl start dnsmasq

steps 3. 验证

在其他机器上测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
~ traceroute eureka.default.svc.cluster.local
traceroute to eureka.default.svc.cluster.local (10.200.229.155), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.151 ms  0.145 ms  0.137 ms
 2  new.eureka.com (192.168.1.109)  0.622 ms  0.595 ms *
 3  bogon (10.200.229.128)  1.311 ms  1.972 ms  2.019 ms
 4  bogon (10.200.229.155)  2.075 ms  2.743 ms  2.741 ms

curl -I eureka.default.svc.cluster.local:8761
HTTP/1.1 200
X-Application-Context: DiscoveryServer:8761
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 7451
Date: Thu, 28 Apr 2022 05:47:08 GMT

后来在其他的服务器上测试可以正常访问，在Mac下能使用nslookup解析，但是无法访问，也无法路由跟踪，以后再解决。

后来发现如果是Mac的话，直接在网络设置-高级-DNS，添加dns地址并拖到上面即可实现访问。只是奇怪的是手动修改/etc/resolv.conf 并没有实现访问，这种界面的形式反而可以，总之，解决了问题。

------ 本文结束 ------

版权声明

Medivh's Notes by Medivh is licensed under a Creative Commons BY-NC-ND 4.0 International License.
由Medivh创作并维护的Medivh's Notes博客采用创作共用保留署名-非商业-禁止演绎4.0国际许可证。
本文首发于Medivh 博客（ http://www.mknight.cn ），版权所有，侵权必究。