Kubernetes1.2如何使用iptables

標籤：output   意圖   details   引入   路由   docker   目標   請求   lib   

轉：http://blog.csdn.net/horsefoot/article/details/51249161

本次分析的kubernetes版本號碼：v1.2.1-beta.0。 
Kubernetes中kube-proxy組件負責維護NODE節點上的防火牆規則和路由規則，Kube-proxy有兩種實現方式，一種是通過iptables，一種是通過userspace，在1.2中將使用iptables作為首選，可以大幅提升效能，下面看看kube-proxy組件是如何操作iptables的。 
kube-proxy要求NODE節點作業系統中要具備/sys/module/br_netfilter檔案，而且還要設定bridge-nf-call-iptables=1，如果不滿足要求，那麼kube-proxy只是將檢查資訊記錄到日誌中，kube-proxy仍然會正常運行，但是這樣通過Kube-proxy設定的某些iptables規則就不會工作。 
在原始碼中有檢查iptables版本是否低於1.4.11的校正，如果iptables版本低於1.4.11，那麼不能使用-C/–check這個參數，這樣可以保證kube-proxy對iptables版本的向下相容性。 
Iptables預設的資料包流向圖如所示： 

在iptables模式下，kube-proxy使用了iptables的filter表和nat表，並且對iptables的鏈進行了擴充，自訂了KUBE-SERVICES、KUBE-NODEPORTS、KUBE-POSTROUTING和KUBE-MARK-MASQ四個鏈，另外還新增了以“KUBE-SVC-”和“KUBE-SEP-”開頭的數個鏈。 
在iptables表中，通過iptables-save可以看到在filter表和nat表中建立好的這些鏈，下面是樣本： 
 
Kube-proxy配置iptables的過程通過syncProxyRules函數來執行的，首先在filter表和nat表中檢查並建立KUBE-SERVICES和KUBE-NODEPORTS兩個鏈，然後在filter表中插入一條iptables規則，將OUTPUT鏈的資料包匯入KUBE-SERVICES鏈，另外在nat表中插入兩條iptables規則，將OUTPUT鏈和PREROUTING鏈的資料包匯入KUBE-SERVICES鏈；接著在NAT表中建立KUBE-POSTROUTING鏈，然後再NAT表中插入一條iptables規則，將POSTROUTING鏈的資料包匯入KUBE-POSTROUTING鏈。 
在iptables表中，通過iptables-save可以看到在nat表中建立好的規則，下面是這些規則的樣本： 

syncProxyRules函數在建立完上面iptables自訂鏈和規則後，叫用作業系統命令iptables-save –t filter和iptables-save –t nat將filter表和nat表中內容儲存到程式緩衝中，在程式緩衝中添加KUBE-MARK-MASQ鏈。 
對於KUBE-MARK-MASQ鏈中所有規則設定了kubernetes專屬MARK標記，在KUBE-POSTROUTING鏈中對NODE節點上匹配kubernetes專屬MARK標記的資料包，進行SNAT處理。 
在iptables表中，通過iptables-save可以看到在nat表中建立好的規則，下面是規則樣本： 

Kube-proxy接著對每個服務建立“KUBE-SVC-”鏈，並在nat表中將KUBE-SERVICES鏈中每個目標地址是service的資料包匯入這個“KUBE-SVC-”鏈；如果service使用到了NODE節點連接埠，那麼將KUBE-NODEPORTS鏈中每個目的地址是NODE節點連接埠的資料包匯入這個“KUBE-SVC-”鏈；如果service沒有配置endpoint，那麼REJECT所有資料包,這意味著沒有endpoint的service是無法被訪問到的。如果service已經配置了endpoint，那麼對每個endpoint建立“KUBE-SEP-”開頭的鏈，並在“KUBE-SVC-”鏈中建立iptables規則，將所有“KUBE-SVC-”鏈中的資料包都匯入“KUBE-SEP-”開頭的鏈中，接著在每個“KUBE-SEP-”鏈中建立iptables規則，其中一條規則就是對所有由endpoint發出的資料包都匯入KUBE-MARK-MASQ鏈中，如果一個service有多個endpoint，那麼就採用隨機方法將資料包匯入不同的“KUBE-SEP-”開頭的鏈中，其實如果一個service對應多個endpoint(相當於一個service對應多個POD)，其實就意味著要實現負載平衡，預設情況下是採用隨機的方法從“KUBE-SVC-”鏈向“KUBE-SEP-”鏈轉寄資料包，但是如果service的sessionAffinity配置成了ClientIP，那麼在一定時間範圍內向“KUBE-SVC-”鏈請求的資料包都會發給固定的“KUBE-SEP-”鏈，通過這種方式實現業務應用的會話保持。 
接著刪除程式緩衝中已經不存在的“KUBE-SVC-”鏈和“KUBE-SEP-”鏈，最後添加一條iptables規則目的地址是本地的資料包匯入KUBE-NODEPORTS鏈中。 
在iptables表中，通過iptables-save可以看到在nat表中建立好的“KUBE-SVC-”鏈和“KUBE-SEP-”鏈，以及這些鏈中的規則，下面是這些規則樣本： 

如果一個service後端有多個POD，那麼在iptables表中通過iptables-save可以看到，下面是使用負載平衡後的規則樣本： 

通過上面規則樣本可以看到service如何向後端POD負載平衡分發資料包。 
在負載平衡實際使用中，最常用的還有會話保持功能，也就是說一個用戶端同伺服器端建立會話串連之後，要保證這個會話串連，通過iptables來實現就需要使用recent模組，kube-proxy會使用“-m recent –rcheck –seconds 180 –reap”命令來實現會話保持，目前還無法配置會話保持的期間，因為kube-proxy在代碼中寫成了180秒，期待以後可以作為參數傳入。 
Kube-proxy將程式緩衝中的iptables規則通過iptables-restore命令更新到NODE節點作業系統中。 
Kube-proxy配置後的Iptables資料包流入圖如下： 

從這張圖上可以看到，從主機網卡上得到的資料包在經過PREROUTING鏈的nat表時，被匯入kube-proxy的KUBE-SERVICES鏈，然後被匯入KUBE-SVC-XXX鏈，這裡的XXX表示十六位字元，是由SHA256 演算法產生雜湊值後通過base32進行編碼，然後取16位，最後資料包被匯入KUBE-SEP-XXX，資料包被DDAT到一個POD上，然後返回到PREROUTING鏈中，如果不需要路由，那麼發送給本地上層協議棧，否則路由出主機網卡。 
下面是kubernetes環境下NODE節點、service、POD和Docker容器的，用於形象的展現這四者之間的關係。 

在這個kubernetes環境下有兩個NODE節點，IP分別是192.168.1.100和192.168.1.101，有兩個ClusterIP模式的service，IP分別是172.16.100.238和172.19.216.162，每個service對應一個POD，在每個POD中。 
從中可以看到在每個NODE節點上都會存在service，service在物理上是不存在的，只是在iptables中，POD在物理上也是不存在的，只是一個概念，這個概念是由POD中POD容器來實現的，POD容器是物理存在的。在ClusterIP模式下，POD容器採用HOST模式建立，使用者容器採用Container模式建立，也就是說使用者容器同POD容器共用網路命名空間、IPC命名空間和檔案系統命名空間，通過引入POD容器來實現邏輯上POD概念。 
在名稱是nginx的POD上，使用者容器如果要訪問名稱是nginx2的service，經過NODE節點192.168.1.100上的iptables表路由到了NODE節點192.168.1.101上，在NODE節點192.168.1.101上通過iptables裡面kube-proxy建立的規則就會目標重新導向給名稱是nginx2的POD，最後這個POD上面的使用者容器收到訪問請求。 
下面是使用NodePort模式的service： 

如果service使用ClusterIP模式，由於service是個虛擬概念，所以service對應的IP其實也是個虛擬IP，在真是的外部物理網路中是無法訪問的，所以只能在kubernetes叢集中使用，在這張圖上service使用了NodePost模式，就可以清楚的看到kube-proxy在NODE節點上建立連接埠，kubernetes預設在30000-32767之間選擇連接埠號碼給service，並且建立從NODE節點上物理連接埠到service的iptables規則，這樣kubernetes外部應用就可以通過訪問NODE節點IP和連接埠來實現訪問service的目的。

Kubernetes1.2如何使用iptables