K8S網絡NAT問題分析與處理

在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
K8S網絡NAT問題分析與處理

2、在node節點server11上可以看到,默認的nat表POSTROUTING規則鏈對pod ip這個網段進行了MASQUERADE
K8S網絡NAT問題分析與處理

3、exec方式進入pod內部,去訪問k8s集羣外部的mysql服務,發現pod ip被nat了
K8S網絡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%';

K8S網絡NAT問題分析與處理

將node節點nat表中的POSTROUTING規則鏈MASQUERADE規則刪除,通過測試發現能符合研發的需求,但帶來新的問題,無法訪問外部服務。

三、改進node節點防火牆規則

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

K8S網絡NAT問題分析與處理
K8S網絡NAT問題分析與處理

添加一條新的路由策略,將目的地址不是192.168.1.20的請求進行MASQUERADE,從而實現既能滿足研發需求,又能訪問互聯網的需求。

四、前提條件

因爲網絡是雙向的,所以需要在公共服務所在的主機上把路由規則添加好
K8S網絡NAT問題分析與處理

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章