在K8S大規模場景下Service性能該如何優化

本篇文章為大家展示了在K8S大規模場景下Service性能該如何優化，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

Kubernetes 原生的 Service 負載均衡基于 Iptables 實現，其規則鏈會隨 Service 的數量呈線性增長，在大規模場景下對 Service 性能影響嚴重。本文分享了華為云在 Kubernetes service 性能優化方面的探索與實踐。

在企業業務推進過程中，不同業務領域的流量高峰通常都是在不同時間段來臨，而應對這些不同時間到來的業務流量往往都需要大量的額外網絡資源做保障。今天給大家帶來我們在 Kubernetes Service 上的一些優化實踐，這是一個網絡相關的話題。

Kubernetes的Service機制

先看一下 Kubernetes 里面的 Service。在用 Kubernetes 之前，當我們有了容器網絡之后，訪問一個應用最直接的做法，就是客戶端直接去訪問一個 Backend Container。這種做法最直觀和容易，同時問題也是顯而易見的。當應用有多個后端容器的時候，怎么做負載均衡，會話保持怎么做，某個容器遷了之后 IP 跟著變怎么辦，還有對應的健康檢查怎么配，如果想用域名來做訪問入口要怎么處理……這些其實就是 Kubernetes 的 Service 引入所要解決的問題。

01 Kubernetes Service 與 Endpoints

這張圖表現了 Service 與其它幾個對象的對應關系。首先是 Service，它保存的是服務的訪問入口信息（如 IP、端口），可以簡單理解為 Kubernetes 內置的一個 LoadBalancer，它的作用就是給多個 Pod 提供負載均衡。

圖中是一個 Replication Controller 部署出來 2 個 pod 所對應的 Service。我們知道 RC 和 pod 的關系是通過 label-selector 來關聯的，service 也是一樣，通過 Selector 來匹配它所要做負載均衡的 Pod。實際上這中間還有一個對象，叫做 Endpoint，為什么要有這個對象呢？因為在實際應用中，一個 pod 被創建，并不代表它馬上就能對外提供服務，而這個 pod 如果將被刪除，或處于其他不良狀態，我們都希望客戶端的請求不被分發到這個無法提供服務的 pod 上。Endpoint 的引入，就是用來映射那些能對外提供服務的 pod。每個 Endpoints 對象的 IP 對應一個 Kubernetes 的內部域名，可以通過這個域名直接訪問到具體的 pod。

再看 Service 和 Endpoint 的定義。這里注意 Service 有一個 ClusterIP 的屬性字段，可以簡單理解為是虛 IP。Service 的域名解析通常得到的就是這個 ClusterIP。另外值得注意的是 Service 支持端口映射，即 Service 暴露的端口不必和容器端口一致。

02 Service 內部邏輯

剛才介紹了 Service、Pods 跟 Endpoint 三者的關系，再來看 Service 的內部邏輯。這里主要看下 Endpoint Controller，它會 watch Service 對象、還有 pod 的變化情況，維護對應的 Endpoint 信息。然后在每一個節點上，KubeProxy 根據 Service 和 Endpoint 來維護本地的路由規則。

實際上，每當一個 Endpoint 發生變化（即 Service 以及它關聯的 Pod 狀態發生變化），Kubeproxy 都會在每個節點上做對應的規則刷新，所以這個其實更像是一個靠近客戶端的負載均衡——一個 Pod 訪問其他服務的 Pod 時，請求在出節點之前，就已經通過本地的路由規則選好了它的目的 Pod。

Iptables實現負載均衡

好，我們來看一下 Iptables 模式是怎么實現的。

Iptables 主要分兩部分，一個是它的命令行工具，在用戶態；然后它也有內核模塊，但本質上還是通過 Netfilter 這個內核模塊來封裝實現的，Iptables 的特點是支持的操作比較多。

這是 IPtables 處理網絡包的一個流程圖，可以看到，每個包進來都會按順序經過幾個點。首先是 PREROUTING，它會判斷接收到的這個請求包，是訪問本地進程還是其他機器的，如果是訪問其他機器的，就要走 FORWARD 這個 chain，然后再會做一次 Routing desicion，確定它要 FORWARD 到哪里，最后經 POSTROUTING 出去。如果是訪問本地，就會進來到 INPUT 這條線，找到對應要訪問哪個本地請求，然后就在本地處理了。處理完之后，其實會生成一個新的數據包，這個時候又會走 OUTPUT，然后經 POSTROUTING 出去。

01 Iptables 實現流量轉發與負載均衡

我們知道，Iptables 做防火墻是專業的，那么它是如何做流量轉發、負載均衡甚至會話保持的呢？如下圖所示：

02 Iptables 在 Kubernetes 的應用舉例

那么，在 Kubernetes 里面是怎么用 Iptables 來實現負載均衡呢？來看一個實際的例子。在 Kubernetes 中，從VIP到RIP，中間經過的Iptables鏈路包括：PREROUTING/OUTPUT（取決于流量是從本機還是外機過來的）-> KUBE-SERVICES（所有 Kubernetes 自定義鏈的入口）->KUBE-SVC-XXX（后面那串 hash 值由 Service 的虛 IP 生成）->KUBE-SEP->XXX（后面那串 hash 值由后端 Pod 實際 IP 生成）。

當前Iptables實現存在的問題

01 Iptables 做負載均衡的問題

那么 Iptables 做負載均衡主要有什么缺陷呢？起初我們只是分析了原理，后來在大規模場景下實測，發現問題其實非常明顯。

• 首先是時延，匹配時延和規則更新時延。我們從剛剛的例子就能看出，每個 Kubernetes Service 的虛 IP 都會在 kube-services 下對應一條鏈。Iptables 的規則匹配是線性的，匹配的時間復雜度是 O(N)。規則更新是非增量式的，哪怕增加/刪除一條規則，也是整體修改 Netfilter 規則表。

• 其次是可擴展性。我們知道當系統中的 Iptables 數量很大時，更新會非常慢。同時因為全量提交的過程中做了保護，所以會出現 kernel lock，這時只能等待。

• 最后是可用性。服務擴容/縮容時，Iptables 規則的刷新會導致連接斷開，服務不可用。

02 Iptables 規則匹配時延

上圖說明了 Service 訪問時延隨著規則數的增加而增長。但其實也還能接受，因為時延最高也就 8000us（8ms），這說明真正的性能瓶頸并不在這里。

03 Iptables 規則更新時延

那么 Iptables 的規則更新，究竟慢在哪里呢

首先，Iptables 的規則更新是全量更新，即使 --no--flush 也不行（--no--flush 只保證 iptables-restore 時不刪除舊的規則鏈）。

再者，kube-proxy 會周期性的刷新 Iptables 狀態：先 iptables-save 拷貝系統 Iptables 狀態，然后再更新部分規則，最后再通過 iptables-restore 寫入到內核。當規則數到達一定程度時，這個過程就會變得非常緩慢。

出現如此高時延的原因有很多，在不同的內核版本下也有一定的差異。另外，時延還和系統當前內存使用量密切相關。因為 Iptables 會整體更新 Netfilter 的規則表，而一下子分配較大的內核內存（>128MB）就會出現較大的時延。

04 Iptables 周期性刷新導致 TPS 抖動

上圖就說明了在高并發的 loadrunner 壓力測試下，kube-proxy 周期性刷新 Iptables 導致后端服務連接斷開，TPS 的周期性波動。

K8S Scalability

所以這個就給 Kubernetes 的數據面的性能帶來一個非常大的限制，我們知道社區管理面的規模，其實在去年就已經支持到了 5000 節點，而數據面由于缺乏一個權威的定義，沒有給出規格。

我們在多個場景下評估發現 Service 個數其實很容易達到成千上萬，所以優化還是很有必要的。當時先到的優化方案主要有兩個：

• 用樹形結構來組織 Iptables 的規則，讓匹配和規則更新過程變成樹的操作，從而優化兩個時延。

• 使用 IPVS，后面會講它的好處。

使用樹形結構組織 Iptables 規則的一個例子如下所示:

在這個例子中，樹根是 16 位地址，根的兩個子節點是 24 位地址，虛 IP 作為葉子節點，根據不同的網段，分別掛在不同的樹節點下。這樣，規則匹配的時延就從 O(N) 降低到 O(N 的 M 次方根)，M 即樹的高度。但這么做帶來的代價是 Iptables 規則變得更加復雜。

IPVS實現Service負載均衡

01 什么是 IPVS

• 傳輸層 Load Balancer，LVS 負載均衡器的實現；

• 同樣基于 Netfilter，但使用的是 hash 表；

• 支持 TCP, UDP，SCTP 協議，IPV4，IPV6；

• 支持多種負載均衡策略，如 rr, wrr, lc, wlc, sh,dh, lblc…

• 支持會話保持， persistent connection 調度算法。

02 IPVS 的三種轉發模式

IPVS 有三種轉發模式，分別是：DR，隧道和 NAT。

• DR 模式工作在 L2，使用的 MAC 地址，速度最快。請求報文經過 IPVS director，轉發給后端服務器，響應報文直接回給客戶端。缺點是不支持端口映射，于是這種模式就很可惜地 PASS 掉了。

• 隧道模式，使用 IP 包封裝 IP 包。后端服務器接收到隧道包后，首先會拆掉封裝的 IP 地址頭，然后響應報文也會直接回給客戶端。IP 模式同樣不支持端口映射，于是這種模式也被 PASS 掉了。

• NAT 模式支持端口映射，與前面兩種模式不同的是，NAT 模式要求回程報文經過 IPVS 的 director。內核原生版本 IPVS 只做 DNAT，不做 SNAT。

03 使用 IPVS 實現流量轉發

使用 IPVS 做流量轉發只需經過以下幾個簡單的步驟。

• 綁定 VIP

由于 IPVS 的 DNAT 鉤子掛在 INPUT 鏈上，因此必須要讓內核識別 VIP 是本機的 IP。綁定 VIP 至少有三種方式：

1.創建一塊 dummy 網卡，然后綁定，如下所示。
# ip link add dev dummy0 type dummy # ip addr add 192.168.2.2/32 dev dummy0

2.直接在本地路由表中加上 VIP 這個 IP 地址。
# ip route add to local 192.168.2.2/32 dev eth0proto kernel

3.在本地網卡上增加一個網卡別名。
# ifconfig eth0:1 192.168.2.2netmask255.255.255.255 up

• 為這個虛 IP 創建一個 IPVS 的 virtual server

# ipvsadm -A -t 192.168.60.200:80 -s rr -p 600
這上面的例子中，IPVS virtual server 的虛 IP 是 192.168.60.200:80，會話保持時間 600s。

• 為這個 IPVS service 創建相應的 real server

# ipvsadm -a -t 192.168.60.200:80 -r 172.17.1.2:80–m
# ipvsadm -a -t 192.168.60.200:80 -r 172.17.2.3:80–m

這上面的例子中，為 192.168.60.200:80 這個 IPVS 的 virtual server 創建了兩個 real server：172.17.1.2:80 和 172.17.2.3:80。

Iptables vs. IPVS

01 Iptables vs. IPVS 規則增加時延

通過觀察上圖很容易發現：

• 增加 Iptables 規則的時延，隨著規則數的增加呈“指數”級上升；

• 當集群中的 Service 達到 2 萬個時，新增規則的時延從 50us 變成了 5 小時；

• 而增加 IPVS 規則的時延始終保持在 100us 以內，幾乎不受規則基數影響。這中間的微小差異甚至可以認為是系統誤差。

02 Iptables vs. IPVS 網絡帶寬

這是我們用 iperf 實測得到兩種模式下的網絡帶寬。可以看到 Iptables 模式下第一個 Service 和最后一個 Service 的帶寬有差異。最后一個 Service 帶寬明顯小于第一個，而且隨著 Service 基數的上升，差異越來越明顯。

而 IPVS 模式下，整體帶寬表現高于 Iptables。當集群中的 Service 數量達到 2.5 萬時，Iptables 模式下的帶寬已基本為零，而 IPVS 模式的服務依然能夠保持在先前一半左右的水平，提供正常訪問。

03 Iptables vs. IPVS CPU/內存消耗

很明顯，IPVS 在 CPU/內存兩個維度的指標都要遠遠低于 Iptables。

特性社區狀態

這個特性從 1.8 版本引入 Alpha，到 1.9 版本發布 Beta，修復了大部分的問題，目前已經比較穩定，強烈推薦大家使用。另外這個特性目前主要是我們華為云 K8S 開源團隊在維護，大家在使用中如果發現問題，歡迎反映到社區，或者我們這邊。

云原生時代已經到來，華為云通過 Kubernetes 邁出了云原生基礎設施建設的第一步。雖然當前在實踐中仍然有許多挑戰在等著我們去應對，但相信隨著我們在技術上持續的投入，這些問題會一一得到解決。

上述內容就是在K8S大規模場景下Service性能該如何優化，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。