标签：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