码迷,mamicode.com
首页 > 其他好文 > 详细

K8S网络NAT问题分析与处理

时间:2018-11-19 16:16:21      阅读:381      评论:0      收藏:0      [点我收藏+]

标签:exec   log   反馈   火墙   客户端   lock   2.3   form   添加   

在K8S环境中(集群环境为自建),node节点上的pod网络互联互通是采用网络插件结合etcd实现的。 默认情况下pod访问集群外部的网络(例如:访问百度)走的是对应node节点的nat规则。

最近收到研发反馈的需求,由于我们mysql这种公共服务并没有放到k8s集群内(对照生产环境使用的也是RDS这种云服务),所以从mysql的information_schema.processlist这张表查询到的客户端连接地址全部都是node节点的ip,而一个node节点上又跑了许多的微服务,这就给研发人员排查客户端连接问题带来了一定的困扰,希望运维将pod连接这些外部公共服务的IP地址改成pod ip

一、需求分析

1、Oprman服务运行在server11这个node节点上,pod ip地址为172.35.69.12
技术分享图片

2、在node节点server11上可以看到,默认的nat表POSTROUTING规则链对pod ip这个网段进行了MASQUERADE
技术分享图片

3、exec方式进入pod内部,去访问k8s集群外部的mysql服务,发现pod ip被nat了
技术分享图片

二、修改node节点防火墙规则

# iptables -t nat -D POSTROUTING 1
# kubectl exec -it oprman-test2-tomcat-8477bfdb59-gshzp   /bin/sh
# mysql -h 192.168.1.20 -u root -p123456
MySQL [(none)]> select * from information_schema.processlist where host like ‘%172.35%‘;

技术分享图片

将node节点nat表中的POSTROUTING规则链MASQUERADE规则删除,通过测试发现能符合研发的需求,但带来新的问题,无法访问外部服务。

三、改进node节点防火墙规则

# iptables -t nat -I POSTROUTING -s 172.35.69.0/24  ! -d  192.168.1.20/32  -j MASQUERADE 

技术分享图片
技术分享图片

添加一条新的路由策略,将目的地址不是192.168.1.20的请求进行MASQUERADE,从而实现既能满足研发需求,又能访问互联网的需求。

四、前提条件

因为网络是双向的,所以需要在公共服务所在的主机上把路由规则添加好
技术分享图片

K8S网络NAT问题分析与处理

标签:exec   log   反馈   火墙   客户端   lock   2.3   form   添加   

原文地址:http://blog.51cto.com/ylw6006/2318872

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!