一、背景
在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中的服务。
