一、背景
在Kubernetes的网络模型中,基于官方支持的CNI插件Flannel、Calico等,可以轻松实现Pod之间的网络互通,当我们将Spring Cloud的微服务部署到Kubernetes中后,无需任何改动微服务的Pod即可通过Eureka注册后进行访问。除此之外还可以通过Ingress controller 基于80/http和443/https端口将用户的请求流量引入到集群服务中。
但在实际开发过程中,我们出现了如下需求:
- 办公网络和Kubernetes Pod网络不通,开发在电脑完成某个微服务模块开发后,希望在本地电脑能注册到Kubernetes中开发环境的注册中心(Nacos)进行调试,而不需要在本地起一堆的依赖服务。
- 办公网络和Kubernetes Svc网络不通,部分服务需要通过Service的NodePort代理访问,应用数量变多后导致维护量工作巨大。
二、环境介绍
网段名称 | IP地址范围 | 子网掩码 |
办公网段 | 172.16.0.0/18 | 255.255.192.0 |
Pod地址池 | 172.17.32.0/19 | 255.255.224.0 |
Svc地址池 | 172.17.16.0/20 | 255.255.240.0 |
三、网络互通配置
选择一个节点用来做路由转发,在本案例中我们使用了Master1来进行配置。
注:建议在集群中新加一台配置不高的Node节点,打上污点不允许调度Pod占用资源,让其专门做路由转发使用。
# 开启转发
[root@k8s-master1 ~]# vim /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
[root@k8s-master1 ~]# sysctl -p
# 在k8s-master1上设置snat
[root@k8s-master1 ~]# iptables -t nat -A POSTROUTING -s 172.16.0.0/18 -d 172.17.32.0/19 -j MASQUERADE
[root@k8s-master1 ~]# iptables -t nat -A POSTROUTING -s 172.16.0.0/18 -d 172.17.16.0/20 -j MASQUERADE
# (可选)查看设置的snat
[root@k8s-master1 ~]# 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 MASQUERADE all -- 192.168.0.0/20 0.0.0.0/0
4 MASQUERADE all -- 172.16.0.0/18 172.17.32.0/19
5 MASQUERADE all -- 172.16.0.0/18 172.17.16.0/20
# (可选)如配置失误可删除已设置的snat条目
[root@k8s-master1 ~]# iptables -t nat -D POSTROUTING 4
在办公室的出口路由上,设置静态路由,将Kubernetes的Pod和Service网段,路由到Master1节点上(具体可查看拓扑图)。
# 在路由器上需要做的配置:
ip route 172.17.32.0 255.255.224.0 172.17.14.11
ip route 172.17.16.0 255.255.240.0 172.17.14.11
配置完成后验证是否能从办公电脑访问:
# 查询集群某个Pod地址
[root@k8s-master1 ~]# kubectl get pod -o wide -n ingress-nginx
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
ingress-nginx-controller-688d67dc6d-68f85 1/1 Running 0 65d 172.17.54.238 k8s-node03 <none> <none>
# 查询集群某个Svc地址
[root@k8s-master1 ~]# kubectl get svc -n ingress-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx-controller NodePort 172.17.24.229 <none> 80:80/TCP,443:443/TCP 465d
# 在办公电脑ping测试连通性
$ ping 172.17.54.238
PING 172.17.54.238 (172.17.54.238): 56 data bytes
64 bytes from 172.17.54.238: icmp_seq=0 ttl=61 time=1.036 ms
64 bytes from 172.17.54.238: icmp_seq=1 ttl=61 time=1.200 ms
......
# 在办公电脑测试Svc连通性
$ curl -I 172.17.24.229:80/healthz
HTTP/1.1 200 OK
Date: Mon, 14 Mar 2022 03:02:30 GMT
Content-Type: text/html
Content-Length: 0
Connection: keep-alive
四、DNS解析配置
以上步骤完成后,我们就可以之间在本地电脑访问Pod和Svc的服务了,但是由于Pod IP根据部署频率会经常变化,Service IP也不是那么容易记忆。所以我们希望通过内网DNS在访问*.cluster.local
时自动去解析相应的IP。
最简单的方式,就是直接将本地dns解析地址设置成CoreDNS的SvcIP上。
# 获取coredns的IP
[root@k8s-master1 ~]# kubectl get svc -n kube-system -l k8s-app=kube-dns
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 172.17.16.10 <none> 53/UDP,53/TCP,9153/TCP 465d
# 本地测试是否能正常解析
$ nslookup -q=A kube-dns.kube-system.svc.cluster.local 172.17.16.10
Server: 172.17.16.10
Address: 172.17.16.10#53
Name: kube-dns.kube-system.svc.cluster.local
Address: 172.17.16.10
因为我们公司内网已有台单独的DNSmasq
用来做解析,所以我们这里直接在DNSmasq
服务器的/etc/dnsmasq.conf
配置文件中添加server=/cluster.local/172.17.16.10
,将内网的*.cluster.local
解析请求交给coreDNS(172.17.16.10)
去解析。
[root@centos-172-16-1-10 ~]# vim /etc/dnsmasq.conf
# 内网的*.cluster.local解析请求,交给coreDNS 172.17.16.10
server=/cluster.local/172.17.16.10
完成以上步骤后,我们办公网络与Kubernetes网络互通需求就都实现了,同时我们可以直接使用Service的域名规则<svc>.<namespaces>.svc.cluster.local:Port
去访问到Kubernetes中的服务。