办公网段与Kubernetes Pod及Svc网络互通方案

一、背景

      在Kubernetes的网络模型中,基于官方支持的CNI插件Flannel、Calico等,可以轻松实现Pod之间的网络互通,当我们将Spring Cloud的微服务部署到Kubernetes中后,无需任何改动微服务的Pod即可通过Eureka注册后进行访问。除此之外还可以通过Ingress controller 基于80/http和443/https端口将用户的请求流量引入到集群服务中。

但在实际开发过程中,我们出现了如下需求:

  1. 办公网络和Kubernetes Pod网络不通,开发在电脑完成某个微服务模块开发后,希望在本地电脑能注册到Kubernetes中开发环境的注册中心(Nacos)进行调试,而不需要在本地起一堆的依赖服务。
  2. 办公网络和Kubernetes Svc网络不通,部分服务需要通过Service的NodePort代理访问,应用数量变多后导致维护量工作巨大。

二、环境介绍

Kubernetes网络环境说明
网段名称 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中的服务。

 

posted @   资深饮水机管理员  阅读(1510)  评论(0编辑  收藏  举报
编辑推荐:
· 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 让容器管理更轻松!
点击右上角即可分享
微信分享提示