办公网段与Kubernetes Pod及Svc网络互通方案
一、背景
在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中的服务。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· Docker 太简单,K8s 太复杂?w7panel 让容器管理更轻松!