貝寶如何將Kubernetes擴充套件到超過4k個節點和200k個Pod？

在 PayPal，我們最近開始使用 Kubernetes 試水。我們的大部分工作負載都在 Apache Mesos 上執行，作為遷移的一部分，我們需要了解執行 Kubernetes 和 PayPal 特定控制平面的叢集的幾個效能方面。這些方面的主要內容是瞭解平臺的可擴充套件性以及通過調整叢集來確定改進的機會。

與 Apache Mesos 可以開箱即用地擴充套件至 10,000 個節點不同，擴充套件 Kubernetes 具有挑戰性。Kubernetes 的可擴充套件性不僅限於節點和 pod 的數量，還包括建立的資源數量、每個 pod 的容器數量、服務總數和 pod 部署吞吐量等幾個方面。這篇文章描述了我們在擴充套件時面臨的一些挑戰以及我們如何解決這些挑戰。

API 伺服器

當與 API 伺服器的多個連線返回 504 閘道器超時以及本地客戶端級別限制（指數退避）時，API 伺服器被證明是一個瓶頸。

通過max-mutating-requests-inflight和max-requests-inflight更新了管理API伺服器上速率限制的佇列大小。這兩個標誌在API伺服器上控制著1.20版本中作為測試版引入的優先順序和公平性功能如何在其佇列類別中劃分總佇列大小。例如，領導選舉的請求比pod請求更優先。在每個優先順序中，都有可配置的佇列的公平性。在未來，通過PriorityLevelConfiguration和FlowSchema API物件，還有進一步微調的空間。

控制器管理器

控制器管理器負責為本地資源提供控制器，如複製集、名稱空間等，其部署數量較多（由複製集管理）。控制器管理器與API伺服器同步其狀態的速度是有限的。多個旋鈕被用來調整這一行為。

• kube-api-qps —控制器管理器在給定秒內可以對 API 伺服器進行的查詢數。
• kube-api-burst —控制器管理器突發，這是kube-api-qps之上的額外併發呼叫。
• concurrent-deployment-syncs併發部署同步 — 同步呼叫中的併發呼叫物件，如部署、副本集等。

排程器

當作為一個獨立的元件進行測試時，排程器可以支援每秒高達1000個pod的高吞吐率。然而，在將排程器部署到一個實時叢集中時，我們注意到實際的吞吐量減少。一個緩慢的etcd例項導致排程器的繫結延遲增加，導致待處理佇列的大小增加到數千個pod的程度。我們的想法是在測試執行期間將這個數字保持在100以下，因為更多的計數會影響到pod的啟動延遲。我們也最終調整了領導者選舉引數，以適應短暫的網路分割槽或網路擁堵時的虛假重啟。

etcd

etcd是Kubernetes叢集中最關鍵的一個部分。這一點從etcd在整個叢集中以不同方式表現出來的大量問題可以看出。我們需要仔細調查，找出根本原因，並擴大etcd的規模，以處理我們的預期規模。

通過調查和分析，我們確定GCP將PD-SSD的磁碟吞吐量扼殺在每秒100MB左右，我們的磁碟大小為100G。GCP沒有提供增加吞吐量限制的方法--它只隨著磁碟的大小增加。

儘管etcd節點只需要<10G的空間，我們首先嚐試使用1TB的PD-SSD。然而，當所有4k節點同時加入Kubernetes控制平面時，即使是更大的磁碟也成為了一個瓶頸。我們決定使用本地SSD，它的吞吐量非常高，代價是在故障情況下資料丟失的機率略高，因為它不是持久的。

在轉移到本地SSD後，我們沒有看到最快的SSD的預期效能。一些基準測試是直接在磁碟上用FIO完成的，這些數字是預期的。然而，etcd基準測試顯示了一個不同的故事，即併發的所有成員寫入。

本地固態硬碟的表現更差!

經過深入調查，這歸因於ext4檔案系統的寫屏障快取提交。由於etcd使用寫前日誌，並在每次提交到raft日誌時呼叫fsync，所以禁用寫屏障是可以的。此外，我們在檔案系統級和用於DR應用程式級都有DB備份工作，。

在這個改變之後，使用本地SSD的數字提高了，與PD-SSD相當。這一改進的效果體現在etcd的WAL同步持續時間和後端提交延遲上，在15:55左右的時間點上，WAL同步持續時間和後端提交延遲減少了90%以上。

etcd中預設的MVCC資料庫大小為2GB。在觸發DB空間不足的警報後，這個大小被增加到最大8GB。由於這個資料庫的利用率約為60%，我們能夠擴充套件到20萬個無狀態莢。

通過上述所有的優化，叢集在我們的預期規模下更加穩定，然而，我們在API延遲的SLI方面遠遠落後。

etcd伺服器仍然會偶爾重啟，僅僅一次重啟就會破壞基準測試結果，特別是P99的數字。仔細觀察發現，在v1.20版的etcd YAML中存在一個失效探測的錯誤。為了解決這個問題，我們採用了一個變通辦法，即增加失敗閾值的數量。

在用盡所有途徑垂直擴充套件etcd後，主要是在資源方面（CPU、記憶體、磁碟），我們發現etcd的效能受到範圍查詢的影響。

當有很多範圍查詢時，etcd的表現並不好，對Raft日誌的寫入受到影響，從而減慢了叢集的延遲。

由於這些耗時的查詢，etcd的後端延遲受到了很大影響。

在事件資源上的etcd伺服器分片後，我們看到在pod高度競爭的情況下，叢集的穩定性有所提高。

在未來，還有進一步將etcd叢集分片到pods資源上的空間。配置API伺服器來聯絡相關的etcd以與分片的資源進行互動是很容易的。

結論

Kubernetes 是一個複雜的系統，必須深入瞭解控制平面才能知道如何擴充套件每個元件。我們通過這次練習學到了很多東西，並將繼續優化我們的叢集。