當 K8s 叢集達到萬級規模，阿里巴巴如何解決系統各元件效能問題？
作者 | 阿里雲容器平臺高階技術專家 曾凡鬆（逐靈）
本文主要介紹阿里巴巴在大規模生產環境中落地 Kubernetes 的過程中，在叢集規模上遇到的典型問題以及對應的解決方案，內容包含對 etcd、kube-apiserver、kube-controller 的若干效能及穩定性增強，這些關鍵的增強是阿里巴巴內部上萬節點的 Kubernetes 叢集能夠平穩支撐 2019 年天貓 618 大促的關鍵所在。
背景
從阿里巴巴最早期的 AI 系統（2013）開始，叢集管理系統經歷了多輪的架構演進，到 2018 年全面的應用 Kubernetes ，這期間的故事是非常精彩的，有機會可以單獨給大家做一個分享。這裡忽略系統演進的過程，不去討論為什麼 Kubernetes 能夠在社群和公司內部全面的勝出，而是將焦點關注到應用 Kubernetes 中會遇到什麼樣的問題，以及我們做了哪些關鍵的優化。
在阿里巴巴的生產環境中，容器化的應用超過了 10k 個，全網的容器在百萬的級別，執行在十幾萬臺宿主機上。支撐阿里巴巴核心電商業務的叢集有十幾個，最大的叢集有幾萬的節點。在落地 Kubernetes 的過程中，在規模上面臨了很大的挑戰，比如如何將 Kubernetes 應用到超大規模的生產級別。
羅馬不是一天就建成的，為了瞭解 Kubernetes 的效能瓶頸，我們結合阿里的生產叢集現狀，估算了在 10k 個節點的叢集中，預計會達到的規模：
- 20w pods
- 100w objects
我們基於 Kubemark 搭建了大規模叢集模擬的平臺，通過一個容器啟動多個（50個）Kubemark 程序的方式，使用了 200 個 4c 的容器模擬了 10k 節點的 kubelet。在模擬叢集中執行常見的負載時，我們發現一些基本的操作比如 Pod 排程延遲非常高，達到了驚人的 10s 這一級別，並且叢集處在非常不穩定的狀態。
當 Kubernetes 叢集規模達到 10k 節點時，系統的各個元件均出現相應的效能問題，比如：
- etcd 中出現了大量的讀寫延遲，並且產生了拒絕服務的情形，同時因其空間的限制也無法承載 Kubernetes 儲存大量的物件；
- API Server 查詢 pods/nodes 延遲非常的高，併發查詢請求可能地址後端 etcd oom；
- Controller 不能及時從 API Server 感知到在最新的變化，處理的延時較高；當發生異常重啟時，服務的恢復時間需要幾分鐘；
- Scheduler 延遲高、吞吐低，無法適應阿里業務日常運維的需求，更無法支援大促態的極端場景。
etcd improvements
為了解決這些問題，阿里雲容器平臺在各方面都做了很大的努力，改進 Kubernetes 在大規模場景下的效能。
首先是 etcd 層面，作為 Kubernetes 儲存物件的資料庫，其對 Kubernetes 叢集的效能影響至關重要。
第一版本的改進，我們通過將 etcd 的資料轉存到 tair 叢集中，提高了 etcd 儲存的資料總量。但這個方式有一個顯著的弊端是額外增加的 tair 叢集，增加的運維複雜性對叢集中的資料安全性帶來了很大的挑戰，同時其資料一致性模型也並非基於 raft 複製組，犧牲了資料的安全性。
第二版本的改進，我們通過將 API Server 中不同型別的物件儲存到不同的 etcd 叢集中。從 etcd 內部看，也就對應了不同的資料目錄，通過將不同目錄的資料路由到不同的後端 etcd 中，從而降低了單個 etcd 叢集中儲存的資料總量，提高了擴充套件性。
第三版本的改進，我們深入研究了 etcd 內部的實現原理，並發現了影響 etcd 擴充套件性的一個關鍵問題在底層 bbolt db 的 page 頁面分配演算法上：隨著 etcd 中儲存的資料量的增長，bbolt db 中線性查詢“連續長度為 n 的 page 儲存頁面”的效能顯著下降。
為了解決該問題，我們設計了基於 segregrated hashmap 的空閒頁面管理演算法，hashmap 以連續 page 大小為 key, 連續頁面起始 page id 為 value。通過查這個 segregrated hashmap 實現 O(1) 的空閒 page 查詢，極大地提高了效能。在釋放塊時，新演算法嘗試和地址相鄰的 page 合併，並更新 segregrated hashmap。更詳細的演算法分析可以見已發表在 CNCF 部落格的博文：
https://www.cncf.io/blog/2019/05/09/performance-optimization-of-etcd-in-web-scale-data-scenario/
通過這個演算法改進，我們可以將 etcd 的儲存空間從推薦的 2GB 擴充套件到 100GB，極大的提高了 etcd 儲存資料的規模，並且讀寫無顯著延遲增長。除此之外，我們也和谷歌工程師協作開發了 etcd raft learner（類 zookeeper observer）/fully concurrent read 等特性，在資料的安全性和讀寫效能上進行增強。這些改進已貢獻開源，將在社群 etcd 3.4 版本中釋出。
API Server improvements
Efficient node heartbeats
在 Kubernetes 叢集中，影響其擴充套件到更大規模的一個核心問題是如何有效的處理節點的心跳。在一個典型的生產環境中 (non-trival)，kubelet 每 10s 彙報一次心跳，每次心跳請求的內容達到 15kb（包含節點上數十計的映象，和若干的卷資訊），這會帶來兩大問題：
- 心跳請求觸發 etcd 中 node 物件的更新，在 10k nodes 的叢集中，這些更新將產生近 1GB/min 的 transaction logs（etcd 會記錄變更歷史）；
- API Server 很高的 CPU 消耗，node 節點非常龐大，序列化/反序列化開銷很大，處理心跳請求的 CPU 開銷超過 API Server CPU 時間佔用的 80%。
為了解決這個問題，Kubernetes 引入了一個新的 build-in Lease API ，將與心跳密切相關的資訊從 node 物件中剝離出來，也就是上圖中的 Lease 。原本 kubelet 每 10s 更新一次 node 物件升級為：
- 每 10s 更新一次 Lease 物件，表明該節點的存活狀態，Node Controller 根據該 Lease 物件的狀態來判斷節點是否存活；
- 處於相容性的考慮，降低為每 60s 更新一次 node 物件，使得 Eviction_ _Manager 等可以繼續按照原有的邏輯工作。
因為 Lease 物件非常小，因此其更新的代價遠小於更新 node 物件。kubernetes 通過這個機制，顯著的降低了 API Server 的 CPU 開銷，同時也大幅減小了 etcd 中大量的 transaction logs，成功將其規模從 1000 擴充套件到了幾千個節點的規模，該功能在社群 Kubernetes-1.14 中已經預設啟用。
API Server load balancing
在生產叢集中，出於效能和可用性的考慮，通常會部署多個節點組成高可用 Kubernetes 叢集。但在高可用叢集實際的執行中，可能會出現多個 API Server 之間的負載不均衡，尤其是在叢集升級或部分節點發生故障重啟的時候。這給叢集的穩定性帶來了很大的壓力，原本計劃通過高可用的方式分攤 API Server 面臨的壓力，但在極端情況下所有壓力又回到了一個節點，導致系統響應時間變長，甚至擊垮該節點繼而導致雪崩。
下圖為壓測叢集中模擬的一個 case，在三個節點的叢集，API Server 升級後所有的壓力均打到了其中一個 API Server 上，其 CPU 開銷遠高於其他兩個節點。
解決負載均衡問題，一個自然的思路就是增加 load balancer。前文的描述中提到，叢集中主要的負載是處理節點的心跳，那我們就在 API Server 與 kubelet 中間增加 lb，有兩個典型的思路：
- API Server 測增加 lb，所有的 kubelets 連線 lb，典型的雲廠商交付的 Kubernetes 叢集，就是這一模式；
- kubelet 測增加 lb，由 lb 來選擇 API Server。
通過壓測環境驗證發現，增加 lb 並不能很好的解決上面提到的問題，我們必須要深入理解 Kubernetes 內部的通訊機制。深入到 Kubernetes 中研究發現，為了解決 tls 連線認證的開銷，Kubernetes 客戶端做了很多的努力確保“儘量複用同樣的 tls 連線”，大多數情況下客戶端 watcher 均工作在下層的同一個 tls 連線上，僅當這個連線發生異常時，才可能會觸發重連繼而發生 API Server 的切換。其結果就是我們看到的，當 kubelet 連線到其中一個 API Server 後，基本上是不會發生負載切換。為了解決這個問題，我們進行了三個方面的優化：
- API Server：認為客戶端是不可信的，需要保護自己不被過載的請求擊潰。當自身負載超過一個閾值時，傳送
409 - too many requests提醒客戶端退避；當自身負載超過一個更高的閾值時，通過關閉客戶端連線拒絕請求； - Client：在一個時間段內頻繁的收到
409時，嘗試重建連線切換 API Server；定期地重建連線切換 API Server 完成洗牌； - 運維層面，我們通過設定 maxSurge=3 的方式升級 API Server，避免升級過程帶來的效能抖動。
如上圖左下角監控圖所示，增強後的版本可以做到 API Server 負載基本均衡，同時在顯示重啟兩個節點（圖中抖動）時，能夠快速的自動恢復到均衡狀態。
List-Watch & Cacher
List-Watch 是 Kubernetes 中 Server 與 Client 通訊最核心一個機制，etcd 中所有物件及其更新的資訊，API Server 內部通過 Reflector 去 watch etcd 的資料變化並存儲到記憶體中，controller/kubelets 中的客戶端也通過類似的機制去訂閱資料的變化。
在 List-Watch 機制中面臨的一個核心問題是，當 Client 與 Server 之間的通訊斷開時，如何確保重連期間的資料不丟，這在 Kubernetes 中通過了一個全域性遞增的版本號 resourceVersion 來實現。如下圖所示 Reflector 中儲存這當前已經同步到的資料版本，重連時 Reflector 告知 Server 自己當前的版本（5），Server 根據記憶體中記錄的最近變更歷史計算客戶端需要的資料起始位置（7）。
這一切看起來十分簡單可靠，但是...
在 API Server 內部，每個型別的物件會儲存在一個叫做 storage 的物件中，比如會有:
- Pod Storage
- Node Storage
- Configmap Storage
- ...
每個型別的 storage 會有一個有限的佇列，儲存物件最近的變更，用於支援 watcher 一定的滯後（重試等場景）。一般來說，所有型別的型別共享一個遞增版本號空間（1, 2, 3, ..., n)，也就是如上圖所示，pod 物件的版本號僅保證遞增不保證連續。Client 使用 List-Watch 機制同步資料時，可能僅關注 pods 中的一部分，最典型的 kubelet 僅關注和自己節點相關的 pods，如上圖所示，某個 kubelet 僅關注綠色的 pods (2, 5）。
因為 storage 佇列是有限的（FIFO），當 pods 的更新時佇列，舊的變更就會從佇列中淘汰。如上圖所示，當佇列中的更新與某個 Client 無關時，Client 進度仍然保持在 rv=5，如果 Client 在 5 被淘汰後重連，這時候 API Server 無法判斷 5 與當前佇列最小值（7）之間是否存在客戶端需要感知的變更，因此返回 Client too old version err 觸發 Client 重新 list 所有的資料。為了解決這個問題，Kubernetes 引入 Watch bookmark 機制：
bookmark 的核心思想概括起來就是在 Client 與 Server 之間保持一個“心跳”，即使佇列中無 Client 需要感知的更新，Reflector 內部的版本號也需要及時的更新。如上圖所示，Server 會在合適的適合推送當前最新的 rv=12 版本號給 Client，使得 Client 版本號跟上 Server 的進展。bookmark 可以將 API Server 重啟時需要重新同步的事件降低為原來的 3%（效能提高了幾十倍），該功能有阿里雲容器平臺開發，已經發布到社群 Kubernetes-1.15 版本中。
Cacher & Indexing
除 List-Watch 之外，另外一種客戶端的訪問模式是直接查詢 API Server，如下圖所示。為了保證客戶端在多個 API Server 節點間讀到一致的資料，API Server 會通過獲取 etcd 中的資料來支援 Client 的查詢請求。從效能角度看，這帶來了幾個問題：
- 無法支援索引，查詢節點的 pod 需要先獲取叢集中所有的 pod，這個開銷是巨大的；
- 因為 etcd 的 request-response 模型，單次請求查詢過大的資料會消耗大量的記憶體，通常情況下 API Server 與 etcd 之間的查詢會限制請求的資料量，並通過分頁的方式來完成大量的資料查詢，分頁帶來的多次的 round trip 顯著降低了效能；
- 為了確保一致性，API Server 查詢 etcd 均採用了
Quorum read，這個查詢開銷是叢集級別，無法擴充套件的。
為了解決這個問題，我們設計了 API Server 與 etcd 的資料協同機制，確保 Client 能夠通過 API Server 的 cache 獲取到一致的資料，其原理如下圖所示，整體工作流程如下：
- t0 時刻 Client 查詢 API Server；
- API Server 請求 etcd 獲取當前的資料版本 rv@t0；
- API Server 請求進度的更新，並等待 Reflector 資料版本達到 rv@t0；
- 通過 cache 響應使用者的請求。
這個方式並未打破 Client 的一致性模型（感興趣的可以自己論證一下），同時通過 cache 響應使用者請求時我們可以靈活的增強查詢能力，比如支援 namespace nodename/labels 索引。該增強大幅提高了 API Server 的讀請求處理能力，在萬臺規模叢集中典型的 describe node 的時間從原來的 5s 降低到 0.3s（觸發了 node name 索引），其他如 get nodes 等查詢操作的效率也獲得了成倍的增長。
Controller failover
在 10k node 的生產叢集中，Controller 中儲存著近百萬的物件，從 API Server 獲取這些物件並反序列化的開銷是無法忽略的，重啟 Controller 恢復時可能需要花費幾分鐘才能完成這項工作，這對於阿里巴巴規模的企業來說是不可接受的。為了減小元件升級對系統可用性的影響，我們需要儘量的減小 controller 單次升級對系統的中斷時間，這裡通過如下圖所示的方案來解決這個問題：
- 預啟動備 controller informer ，提前載入 controller 需要的資料；
- 主 controller 升級時，會主動釋放 Leader Lease，觸發備立即接管工作。
通過這個方案，我們將 controller 中斷時間降低到秒級別（升級時 < 2s），即使在異常宕機時，備僅需等待 leader lease 的過期（預設 15s），無需要花費幾分鐘重新同步資料。通過這個增強，顯著的降低了 controller MTTR，同時降低了 controller 恢復時對 API Server 的效能衝擊。該方案同樣適用於 scheduler。
Customized scheduler
由於歷史原因，阿里巴巴的排程器採用了自研的架構，因時間的關係本次分享並未展開排程器部分的增強。這裡僅分享兩個基本的思路，如下圖所示：
- Equivalence classes：典型的使用者擴容請求為一次擴容多個容器，因此我們通過將 pending 佇列中的請求劃分等價類的方式，實現批處理，顯著的降低 Predicates/Priorities 的次數；
- Relaxed randomization：對於單次的排程請求，當叢集中的候選節點非常多時，我們並不需要評估叢集中全部節點，在挑選到足夠的節點後即可進入排程的後續處理（通過犧牲求解的精確性來提高排程效能）。
總結
阿里巴巴通過一系列的增強與優化，成功將 Kubernetes 應用到生產環境並達到了單叢集 10000 節點的超大規模，具體包括：
- 通過將索引和資料分離、資料 shard 等方式提高 etcd 儲存容量，並最終通過改進 etcd 底層 bbolt db 儲存引擎的塊分配演算法，大幅提高了 etcd 在儲存大資料量場景下的效能，通過單 etcd 叢集支援大規模 Kubernetes 叢集，大幅簡化了整個系統架構的複雜性；
- 通過落地 Kubernetes 輕量級心跳、改進 HA 叢集下多個 API Server 節點的負載均衡、ListWatch 機制中增加 bookmark、通過索引與 Cache 的方式改進了 Kubernetes 大規模叢集中最頭疼的 List 效能瓶頸，使得穩定的執行萬節點叢集成為可能；
- 通過熱備的方式大幅縮短了 controller/scheduler 在主備切換時的服務中斷時間，提高了整個叢集的可用性；
- 阿里巴巴自研排程器在效能優化上最有效的兩個思路：等價類處理以及隨機鬆弛演算法。
通過這一系列功能增強，阿里巴巴成功將內部最核心的業務執行在上萬節點的 Kubernetes 叢集之上，並經歷了 2019 年天貓 618 大促的考驗。
作者簡介：
曾凡鬆（花名：逐靈），阿里云云原生應用平臺高階技術專家。
有豐富的分散式系統設計研發經驗。在叢集資源排程這一領域，曾負責的自研排程系統管理了數十萬規模的節點，在叢集資源排程、容器資源隔離、不同工作負載混部等方面有豐富的實踐經驗。當前主要負責 Kubernetes 在阿里內部的規模化落地，將 Kubernetes 應用於阿里內部的最核心電商業務，提高了應用釋出效率及叢集資源利用率，並穩定支撐了 2018 雙十一 及 2019 618 大促。
** “ 阿里巴巴雲原生微信公眾號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公眾號。”**