Categories
程式開發

Yelp開源集群工具Clusterman ,支持 Kubernetes


今年早些時候,我曾寫過一篇博文,展示了Yelp內部計算集群自動伸縮器(Cluster autoscaler,CA)、Clusterman(我們的集群管理器)的一些特性。過去幾個月,我們為 Clusterman 添加了另一個可支持的選擇——Kubernetes 集群。與此同時,Clusterman 現在已在 GitHub 上開源。

Yelp開源集群工具Clusterman ,支持 Kubernetes 1

從 Mesos 到 Kubernetes

在過去五年,我們在 Yelp 上討論撰寫了很多關於計算堆棧的內容,我們已經從單一的 yelp_main repo 轉變為一個完全分佈式、面向服務的架構,運行在 Apache Mesos 和我們的內部平台即服務(PaaSTA)之上的雲端中。說實話,如果沒有這一舉措,我們就不可能會發展成現在這樣的規模。今年,我們一直在努力為基礎架構的進一步增長做準備,並意識到實現這一目標的最佳途徑是從 Mesos 遷移到 Kubernetes。

Kubernetes 允許我們運行在 Mesos(由於本地狀態需求)下難於管理的工作負載(如 Flink、Cassandra、Spark 和 Kafka 等)。我們堅信,在一個公共平台(PaaSTA)下管理這些工作負載將會使我們的基礎架構工程師的產出提高一個數量級,比如僅用幾行 YAML 就能構建一個新的 Cassandra 集群。

此外,我們正在將所有微服務和批處理工作負載遷移到 Kubernetes。這是 Yelp 上討論的一個問題,但我們最終決定採用這種方法,因為可以減少維護兩個相互競爭的調度器(Mesos 和 Kubernetes)的開銷,又可以利用快速發展的 Kubernetes 生態系統。借助 PaaSTA 提供的抽象,我們已經能夠無縫地進行遷移,我們的部分開發人員並不知道他們的服務是在一個完全不同的計算平台上運行的。

當然,為了使這種遷移成為可能,我們需要在計算集群的所有工具中構建對 Kubernetes 的支持,包括非常重要的自動伸縮器 Clusterman。由於 Clusterman 的模塊化設計,使得事情變得容易。我們只是定義了一個新的連接器類,符合自動伸縮器期望的接口。該連接器知道如何與 Kubernetes API 服務器進行通訊,以檢索正在伸縮的 Kubernetes 集群狀態的指標和統計信息。然後,這些指標將被保存在指標數據存儲中,這些數據存儲被發送到信號和自動伸縮引擎,以確定如何添加或刪除計算資源。

為什麼是 Clusterman?

我們是 Yelp 上開源軟件的主要支持者;我們從其他許多開源項目的努力中受益,並將能夠回饋社區的東西發佈出去。自 Clusterman 項目創立以來,我們就一直想將其開源,現在,它已經支持 Kubernetes 了,沒有比這更好的發布開源時機了。

每當這樣的項目發佈時,人們會問的第一個問題是:“我為什麼要用你們的產品,而不是另一個已構建好的產品呢?”兩個這樣的產品是適用於 Spot Fleet 的 AWS Auto ScalingKubernetes Cluster Autoscaler。那麼讓我們將 Clusterman 與它們進行比較:

Clusterman Auto Scaling for Spot Fleet Kubernetes Cluster Autoscaler
支持任何類型的雲資源 (ASG、spot fleet 等) 僅適用於 Spot Fleets 僅支持同構雲資源 (所有計算資源必須相同)
可插拔信號架構 三種不同的伸縮選擇:目標跟踪、階躍函數或基於時間 在 Pod 等待調度時伸縮集群
可主動自動伸縮以解決節點自舉時間的延遲 沒有主動伸縮功能 等待節點接入集群,然後繼續
基本的 Kubernetes 支持 不具備 Kubernetes 的知識 支持節點和 Pod 親和性等高級功能
可以在生產數據上模擬自動伸縮決策 沒有模擬器 沒有模擬器
可伸縮(開源) 閉源 API 可伸縮(開源)

我們想強調幾點:首先,請注意 Clusterman 是唯一可以支持混合雲資源(Spot Fleet、Auto-Scaling Group 等)的自動伸縮器,它甚至可以在同一個集群中處理這個問題!這就允許非常靈活的基礎架構設計。

此外,Clusterman 的可插拔信號架構允許你編寫你可以想像得到的任何類型的伸縮信號(並編寫代碼)。在Yelp 中,我們通常認為Kubernetes Cluster Autoscaler 方法(當Pod 在等待時進行伸縮)對於大多數用例來說是適用的,但是具有創建更複雜的自動伸縮行為的靈活性對我們來說真的非常重要。我們如何從這種能力中受益的一個例子就是 Jolt,它是一個用於運行單元測試和集成測試的內部工具。 Jolt 集群每天運行數以百萬計的測試,並且工作負載具有非常高的可預測性;因此,我們編寫了一個自定義信號,允許我們在Pod 處於“等待”狀態排隊之前進行伸縮,這為開發人員節省了大量運行測試的時間!換句話說,Kubernetes Cluster Autoscaler 是被動的,但是 Clusterman 有足夠的靈活性,可以在需要資源之前採取主動並進行伸縮。

公平地說,並不是每個人都需要做出複雜的自動伸縮決策的能力;許多用戶使用 AWS Spot Fleet Autoscaler 或 Kubernetes Clusterman Autoscaler 等就可以了。幸運的是,對於這些用戶來說,Clusterman 可以根據需要輕鬆地進行交換。例如,可以將其配置為讀取 Kubernetes Cluster Autoscaler 所執行的所有相同的節點標籤,並適當地執行操作。還要注意的是,Kubernetes Cluster Autoscaler 確實支持一些 Clusterman 還不知道的 Kubernetes 特性,比如 Pod 親和力和反親和力。但是,我們不斷地為 Clusterman 添加新功能,當然,我們永遠歡迎 Pull 請求。

作者介紹:

David R. Morrison,供職於 Yelp 的科學家和軟件工程師。同時也是優化專家、數學家和攝影師。美國伊利諾伊大學香檳分校計算機科學博士。

原文鏈接:

https://engineeringblog.yelp.com/2019/11/open-source-clusterman.html