Airbnb 基礎設施的一個重要作用是保證我們的云能夠根據需求上升或下降進行自動擴縮容。我們每天的流量波動都非常大，需要依靠動態擴縮容來保證服務的正常運行。

　　為了支持擴縮容，Airbnb 使用了 Kubernetes 編排系統，并且使用了一種基于 Kubernetes 的服務配置接口[1]。

　　本文我們將討論如何使用 Kubernetes Cluster Autoscaler 來動態調整集群的大小，并著重介紹了我們為 Sig-Autoscalsing 社區[2]做出的貢獻。這些改進增加了可定制性和靈活性，以滿足 Airbnb 獨特的業務需求。

　　Airbnb 的 Kubernetes 集群

　　過去幾年中，Airbnb 已經將幾乎所有的在線服務從手動編排的 EC2 實例遷移到了 Kubernetes。如今，我們在近百個集群中運行了上千個節點來適應這些工作負載。然而，這些變化并不是一蹴而就的。在遷移過程中，隨著新技術棧上的工作負載和流量越來越多，我們底層的 Kubernetes 集群也隨之變得越來越復雜。這些演變可以劃分為如下三個階段：

　　階段 1：同質集群，手動擴縮容

　　在使用 Kubernetes 之前，每個服務實例都運行在其所在的機器上，通過手動分配足夠的容量來滿足流量增加的場景。每個團隊的容量管理方式都不盡相同，且一旦負載下降，很少會取消配置。

　　一開始我們的 Kubernetes 集群的配置相對比較簡單。我們有幾個集群，每個集群都有單獨的底層節點類型和配置，它們只運行無狀態的在線服務。隨著服務開始遷移到 Kubernetes，我們開始在多租戶環境中運行容器化的服務。這種聚合方式減少了資源浪費，并且將這些服務的容量管理整合到 Kuberentes 控制平面上。在這個階段，我們手動擴展我們的集群，但相比之前仍然有著顯著的提升。

　　階段 2：多集群類型，獨立擴縮容

　　我們集群配置的第二個階段是因為更多樣化的工作負載而出現的，每個試圖在 Kubernetes 上運行的工作負載都有著不同的需求。為了滿足這些需求，我們創建了一個抽象的集群類型。集群類型定義了集群的底層配置，這意味著集群類型的所有集群都是相同的，從節點類型到集群組件設置都是相同的。

　　越來越多的集群類型導致出現了越來越多的集群，我們最初通過手動方式來調節每個集群容量的方式，很快就變得崩潰了。為了解決這個問題，我們為每個集群添加了 Kubernetes Cluster Autoscaler[3] 組件。該組件會基于pod requests來動態調節集群的大小。如果一個集群的容量被耗盡，則 Cluster Autoscaler 會添加一個新的節點來滿足pending狀態的pods。同樣，如果在一段時間內集群的某些節點的利用率偏低，則Cluster Autoscaler會移除這些節點。這種方式非常適合我們的場景，為我們節省了大約5%的總的云開銷，以及手動擴展集群的運維開銷。

　　階段 3：異構集群，自動擴縮容

　　當 Airbnb 的幾乎所有在線計算都轉移到 Kubernetes 時，集群類型的數量已經增長到 30 多個了，集群的數量也增加到了 100 多個。這種擴展使得 Kubernetes 集群管理相當乏味。例如，在集群升級時需要單獨對每種類型的集群進行單獨測試。

　　在第三個階段，我們會通過創建異構集群來整合我們的集群類型，這些集群可以通過單個 Kubernetes 控制平面來容納許多不同的工作負載。首先，這種方式極大降低了集群管理的開銷，因為擁有更少、更通用的集群會減少需要測試的配置數量。其次，現在大多數 Airbnb 的服務已經運行在了 Kubernetes 集群上，每個集群的效率可以為成本優化提供一個很大的杠桿。整合集群類型允許我們在每個集群中運行不同的工作負載。這種工作負載類型的聚合(有些大，有些小)可以帶來更好的封裝和效率，從而提高利用率。通過這種額外的工作負載靈活性，我們可以有更多的空間來實施復雜的擴展策略，而不是默認的 Cluster Autoscaler 擴展邏輯。具體來說就是我們計劃實現與 Airbnb 特定業務邏輯相關的擴縮容邏輯。

　　隨著對集群的擴展和整合，我們實現了異構(每個集群有多種實例類型)，我們開始在擴展期間實現特定的業務邏輯，并且意識到有必要對擴縮容的行為進行某些變更。下一節將描述我們是如何修改 Cluster Autoscaler，使其變得更加靈活。

　　Cluster Autoscaler 的改進

　　自定義 gRPC 擴展器

　　我們對 Cluster Autoscaler 所做的最重要的改進是提供了一種新方法來確定要擴展的節點組。在內部，Cluster Autoscaler 會維護一系列映射到不同候選擴容對象的節點組，它會針對當前 Pending 狀態的 pods 執行模擬調度，然后過濾掉不滿足調度要求的節點組。如果存在 Pending 的 pods，Cluster Autoscaler 會嘗試通過擴展集群來滿足這些 pods。所有滿足 pod 要求的節點組都會被傳遞給一個名為 Expander 的組件。

　　Expander 負責根據需求進一步過濾節點組。Cluster Autoscaler 有大量內置的擴展器選項，每個選型都有不同的處理邏輯。例如，默認是隨機擴展器，它會隨機選擇可用的節點組。另一個是 Airbnb 曾經使用過的 優先級擴展器[4]，它會根據用戶指定的分級優先級列表來選擇需要擴展的節點組。

　　當我們使用異構集群邏輯的同時，我們發現默認的擴展器無法在成本和實例類型選擇方面滿足我們復雜的業務需求。

　　假設，我們想要實現一個基于權重的優先級擴展器。目前的優先級擴展器僅允許用戶為節點組設置不同的等級，這意味著它會始終以確定的順序來擴展節點組。如果某個等級有多個節點組，則會隨機選擇一個節點組�；�于權重的優先級策略可以支持在同一個等級下設置兩個節點組，其中 80% 的時間會擴展一個節點組，另外 20% 的時間會擴展另一個節點組。但默認并不支持基于權重的擴展器。

　　除了當前支持的擴展器的某些限制外，還有一些操作上的問題：

　　Cluster Autoscaler 的發布流水線比較嚴格，在合并到上游之前，需要花大量時間來審核變更。但我們的業務邏輯和所需的擴展策略是在不斷變化的。能夠滿足當前需求的擴展器并不一定能夠滿足未來的需求。

　　我們的業務邏輯是與 Airbnb 關聯的，其他用戶則沒有這種業務邏輯。因此我們實現的特定邏輯并不一定對上游用戶有用。

　　所以我們對 Cluster Autoscaler 中的新擴展器類型提出了一些要求：

　　我們希望擴展器是可擴展的，能夠被其他用戶使用。其他用戶在使用默認的 Expanders 可能會遇到類似的限制，我們希望提供一個通用的解決方案，并回饋上游。

　　我們的解決方案應該能夠獨立于 Cluster Autoscaler 部署，這樣可以讓我們能夠響應快速變更的業務需求。

　　我們的解決方案應該能夠融入 Kubernetes Cluster Autoscaler 生態系統，這樣就無需一直維護一個 Cluster Autoscale 的分支。

　　鑒于這些需求，我們提出了一種設計，將擴展職責從 Cluster Autoscaler 的核心邏輯中分離出來。我們設計了一種可插拔的 自定義擴展器[5]，它實現了gRPC客戶端(類似 custom cloud provider[6] )，該自定義擴展器分為兩個組件。

　　第一個組件是內置到 Cluster Autoscaler 中的 gRPC 客戶端，這個 Expander 與 Cluster Autoscaler 中的其他擴展器遵循相同的接口，負責將 Cluster Autoscaler 中的有效節點組信息轉換為定義好的 protobuf 格式(見下文)，并接收來自gRPC 服務端的輸出，將其轉換回 Cluster Autoscaler 要擴展的最終的可選列表。

　　第二個組件是 gRPC 服務端，這需要由用戶實現，該服務端作為一個獨立的應用或服務運行。通過客戶端傳遞的信息以及復雜的擴展邏輯來選擇需要擴容的節點組。當前通過 gRPC 傳遞的 protobuf 消息是 Cluster Autoscaler 中傳遞給 Expander 的內容的(略微)轉換版本。

　　在前面的例子中，可以非常容易地實現加權隨機優先級擴展器，方法是讓服務器從優先級列表中讀取，并通過 confimap 讀取權重百分比，然后進行相應的選擇。

　　我們的實現還包含一個故障保護選項。建議使用該選項將 多個擴展器[7] 作為參數傳遞給 Cluster Autoscaler。使用該選擇后，如果服務端出現故障，Cluster Autoscaler 仍然能夠使用一個備用的擴展器進行擴展。

　　由于服務端作為一個獨立的應用運行，因此可以在 Cluster Autoscaler 外開發擴展邏輯，且 gRPC 服務端可以根據用戶需求實現自定義，因此這種方案對整個社區來說也非常有用。

　　在內部，從 2022 年開始，Airbnb 就一直在使用這種方案來擴縮容所有的集群，期間一直沒有出現任何問題。它允許我們動態地選擇何時去擴展特定的節點組來滿足 Airbnb 的業務需求，從而實現了我們開發一個可擴展的自定義擴展器。

　　我們的自定義擴展器在今年早些時候被上游 Cluster Autoscaler 接受，并將在下一個版本 (v1.24.0) 版本中可以使用。

　　總結

　　在過去的四年里，Airbnb 在我們的 Kubernetes 集群配置中取得了長足的進步。通過在 Cluster Autoscaler 中開發和引入更加成熟的擴展器，我們已經能夠實現圍繞成本和多實例類型開發復雜的、特定業務的擴展策略目標，同時還向社區貢獻了一些有用的功能。