歡迎訪問網易雲社群，瞭解更多網易技術產品運營經驗。

五、K8s 1.8 新特性——ipvs

ipvs與iptables的效能差異

隨著服務的數量增長，IPTables 規則則會成倍增長，這樣帶來的問題是路由延遲帶來的服務訪問延遲，同時新增或刪除一條規則也有較大延遲。不同規模下，kube-proxy新增一條規則所需時間如下所示： 

可以看出當叢集中服務數量達到5千個時，路由延遲成倍增加。新增 IPTables 規則的延遲，有多種產生的原因，如：

新增規則不是增量的，而是先把當前所有規則都拷貝出來，再做修改然後再把修改後的規則儲存回去，這樣一個過程的結果就是 IPTables 在更新一條規則時會把 IPTables 鎖住，這樣的後果在服務數量達到一定量級的時候，效能基本不可接受：在有5千個服務（4萬條規則）時，新增一條規則耗時11分鐘；在右2萬個服務（16萬條規則）時，新增一條規則需要5個小時。

這樣的延遲時間，對生產環境是不可以的，那該效能問題有哪些解決方案呢？從根本上解決的話，可以使用 “IP Virtual Server”(IPVS )來替換當前 kube-proxy 中的 IPTables 實現，這樣能帶來顯著的效能提升以及更智慧的負載均衡功能如支援權重、支援重試等等。

那什麼是 “IP Virtual Server”(IPVS ) 呢？

ipvs 簡介

k8s 1.8 版本中，社群 SIG Network 增強了 NetworkPolicy API，以支援 Pod 出口流量策略，以及允許策略規則匹配源或目標 CIDR 的匹配條件。這兩個增強特性都被設計為 beta 版本。 SIG Network 還專注於改進 kube-proxy，除了當前的 iptables 和 userspace 模式，kube-proxy 還引入了一個 alpha 版本的 IPVS 模式。

作為 Linux Virtual Server(LVS) 專案的一部分，IPVS 是建立於 Netfilter之上的高效四層負載均衡器，支援 TCP 和 UDP 協議，支援3種負載均衡模式：NAT、直接路由（通過 MAC 重寫實現二層路由）和IP 隧道。ipvs(IP Virtual Server)安裝在LVS(Linux Virtual Server)叢集作為負載均衡主節點上，通過虛擬出一個IP地址和埠對外提供服務。客戶端通過訪問虛擬IP+埠訪問該虛擬服務，之後訪問請求由負載均衡器排程到後端真實伺服器上。

ipvs相當於工作在netfilter中的input鏈。 

配置方法：IPVS 負載均衡模式在 kube-proxy 處於測試階段還未正式釋出，完全相容當前 Kubernetes 的行為，通過修改 kube-proxy 啟動引數，在 mode=userspace 和 mode=iptables 的基礎上，增加 mode=IPVS 即可啟用該功能。

ipvs轉發模式

● DR模式（Direct Routing）

特點：

<1> 資料包在LB轉發過程中，源/目的IP和埠都不會變化。LB只修改資料包的MAC地址為RS的MAC地址

<2> RS須在環回網絡卡上繫結LB的虛擬機器服務IP

<3> RS處理完請求後，響應包直接回給客戶端，不再經過LB

缺點：

<1> LB和RS必須位於同一子網

● NAT模式（Network Address Translation）

特點：

<1> LB會修改資料包地址：對於請求包，進行DNAT；對於響應包，進行SNAT

<2> 需要將RS的預設閘道器地址配置為LB的虛擬IP地址

缺點：

<1> LB和RS必須位於同一子網，且客戶端和LB不能位於同一子網

● FULLNAT模式

特點：

<1> LB會對請求包和響應包都做SNAT+DNAT

<2> LB和RS對於組網結構沒有要求

<3> LB和RS必須位於同一子網，且客戶端和LB不能位於同一子網

● 三種轉發模式效能從高到低：DR > NAT >FULLNAT

ipvs 負載均衡器常用排程演算法

● 輪詢（Round Robin）

LB認為叢集內每臺RS都是相同的，會輪流進行排程分發。從資料統計上看，RR模式是排程最均衡的。

● 加權輪詢（Weighted Round Robin）

LB會根據RS上配置的權重，將訊息按權重比分發到不同的RS上。可以給效能更好的RS節點配置更高的權重，提升叢集整體的效能。

● 最少連線排程

LB會根據和叢集內每臺RS的連線數統計情況，將訊息排程到連線數最少的RS節點上。在長連線業務場景下，LC演算法對於系統整體負載均衡的情況較好；但是在短連線業務場景下，由於連線會迅速釋放，可能會導致訊息每次都排程到同一個RS節點，造成嚴重的負載不均衡。

● 加權最少連線排程

最小連線數演算法的加權版。

● 原地址雜湊，鎖定請求的使用者

根據請求的源IP，作為雜湊鍵（Hash Key）從靜態分配的散列表中找出對應的伺服器。若該伺服器是可用的且未超載，將請求傳送到該伺服器。

相關閱讀：淺談 kubernetes service 那些事 （上篇）

本文來自網易實踐者社群，經作者張文娟授權釋出。

相關文章：
【推薦】 用雙十一的故事串起碎片的網路協議（上）