背景
為什么選擇spark on k8s
Apache Spark 作為一站式平臺統(tǒng)一了批處理,實時處理,流分析饱苟，機器學習，以及交互式查詢.雖然說spark 提供了多樣的使用場景，但是也帶來了額外的復雜性以及集群管理的成本。讓我們來看一下為了賦能spark為一站式平臺所需要的底層資源編排：
- spark計算要提供不同的機器學習以及etl任務的資源共享
- 支持在共享k8s集群的spark多版本帆调，python多版本，以及版本控制的快讀迭代以及生產(chǎn)環(huán)境的穩(wěn)定
- 需要一個統(tǒng)一的批任務以及微服務的底層支持
- 在共享集群間的細粒度的控制
kubernetes 作為一個服務部署標準豆同，相對于其他的資源編排番刊，滿足以上所有的需求。kubernetes提供了一個管理基礎設施和應用的簡單方法影锈，能夠做到負載隔離,資源限制芹务，按需部署，按需擴容鸭廷。
spark on k8s的調度挑戰(zhàn)
kubernetes默認的調度器就在同一集群有效的部署批任務和長期運行的服務還是存在差距的锄禽。批任務大部分是需要一起調度，并且由于任務并行的需要是需要頻繁的調度,讓我們看一下具體的差距細節(jié):
缺少應用是第一成員的的概念
批任務經(jīng)常是需要以順序的方式進行調度靴姿。例如沃但，spark driver pods需要比work pod 早調度，而應用第一的概念能夠保證順序部署佛吓。而且宵晚，這種能夠讓管理員可視化任務的調度以便于進行debug。
缺少有效的資源配額管理能力
在多租戶的場景下運行spark维雇，kubernetes能夠使用namespace資源配額的方式來管理資源淤刃。然而這在實現(xiàn)上有挑戰(zhàn)的：
- spark任務在資源使用上是動態(tài)的,namespace的資源配額是固定的，并且在admission階段就確認下來的吱型。如果不滿足namespace的配額要求逸贾，請求是會被拒絕的。這就要求spark任務實現(xiàn)一個重試機制去請求pod津滞，而不是讓kubernetes本身去排隊請求運行铝侵。
- namespace資源配額是扁平的，并不支持繼承關系的資源配額管理触徐。
然而很多時候咪鲜，當kubernetes的namespace的資源配額不能滿足事先分配好的資源的時候，用戶可能會在批任務的時候存在饑餓撞鹉。一個彈性的繼承優(yōu)先級的任務管理目前是不存在的疟丙。
缺少用戶間的資源公平調度
在生產(chǎn)環(huán)境下颖侄，我們經(jīng)常會發(fā)現(xiàn) kubernetes默認的調度器不能夠有效的管理多種任務類型負載，不能提供公平的資源負載.這些關鍵的原因如下：
- 在生產(chǎn)環(huán)境下的批任務管理經(jīng)常會有大量的用戶在操作
- 在一些資源緊張的生產(chǎn)環(huán)境下享郊，多種任務負載在運行览祖，這很有可能spark driver pods會占用一個namespace的所有的資源。這種場景下給資源共享提供了一個很大的挑戰(zhàn)
- 失敗的任務很容易占用資源不釋放炊琉，這會影響生產(chǎn)環(huán)境的負載
嚴格的調度的延遲的SLA要求
大部分繁忙的生產(chǎn)環(huán)境下展蒂，對于批任務每天會運行上千個job和task。這些任務負載需要大量的并行容器部署并且這種容器的生命周期是比較短的（從分鐘到小時不等）温自。這就產(chǎn)生了對于成千上萬個pod和容器部署調度的需求玄货。使用kubernetes默認的調度器能夠帶來額外的延遲皇钞，這就導致了丟失了SLAs
Apache YuniKorn 怎么助力
Apache YuniKorn的總覽
YuniKorn是對kubernetes 服務和批任務負載的調度增強悼泌。YuniKorn能夠代替Kubernetes默認的調度器,當然也能兼容在部署場景下k8s默認的調度器。
YuniKorn 帶來了一個統(tǒng)一的夹界，跨平臺的混合部署無狀態(tài)的批任務和有轉臺的服務的調度經(jīng)驗
YuniKorn vs Kubernetes default scheduler：對比
| 特性 | 默認的調度器 | YuniKorn | 說明 |
|---|---|---|---|
| 應用的概念 | 不支持 | 支持 | 應用在YuniKorn是第一公民馆里。YuniKorn調度應用伴隨著提交順序，優(yōu)先級可柿，資源使用等 |
| 任務順序 | 不支持 | 支持 | YuniKorn支持FIFO/FAIR/Prioriry 任務順序優(yōu)先級 |
| 細粒度的資源管理 | 不支持 | 支持 | 以繼承性的隊列方式管理集群資源鸠踪。隊列提供了最大最小的資源保證 |
| 資源的公平性 | 不支持 | 支持 | 對所有的應用跨應用和隊列的資源公平競爭 |
| 本地支持大數(shù)據(jù)的任務 | 不支持 | 支持 | 默認的調度器關注于長服務。YuniKorn設計為大數(shù)據(jù)應用的負載調度复斥，原生支持運行spark/Flink/TensorFlow等等 |
| 擴展行和性能 | 不支持 | 支持 | YuniKorn對性能做了優(yōu)化营密，它適合大吞吐以及大規(guī)模的環(huán)境 |
YuniKorn怎么助力spark on k8s
YuniKorn 有豐富的特性去幫助spark更好的運行在kubernetes上。具體的步驟可以參考這里
YuniKorn賦能spark on k8s更多細節(jié)參考: Cloud-Native Spark Scheduling with YuniKorn Scheduler in Spark & AI summit 2020
讓我看一下使用場景目锭，以及YuniKorn怎么助力更好的資源調度spark
多用戶同時運行不同的spark任務
當更多的用戶一起運行任務的時候评汰，隔離任務和提供任務的資源公平和優(yōu)先級就會變得非常困難了。YuniKorn調度通過使用資源隊列提供了一種可選的解決方案痢虹。
在YuniKorn以上隊列的例子中被去，kubernetes中定義的namespaces被映射成了隊列。Test和DevDevelopment隊列有固定的資源限制奖唯。所有其他的隊列只是被集群的大小所限制惨缆。任務在production隊列以FIFO方式調度
優(yōu)點：
- one YuniKorn隊列會自動匹配到一個namespace下
- 隊列的資源是彈性的，可以配置為最大最小值
- 資源的公平性能夠避免資源饑餓
YuniKorn 能夠無縫的管理kubernetes的資源配額管理丰捷，它能夠替代namespace資源配額坯墨。YuniKorn的資源配額管理能夠讓pod的請求排隊，并且能夠基于可插拔的調度插件進行有限資源的共享病往。這些無需任何配置畅蹂，如重試spark pod提交，就能實現(xiàn)荣恐。
建立基于組織的資源分配模型
在大的生產(chǎn)環(huán)境中液斜，多個用戶將會同時運行多個任務負載累贤。而且大部分用戶的資源分配都是基于組織架構限制的。這種資源分配模型的建立有利于集群資源的使用邊界管理少漆。
YuniKorn提供了一種繼承的隊列的資源管理臼膏。在多用戶的環(huán)境下通過可繼承的隊列進行細粒度的資源管理是可以的。YuniKorn 隊列可以靜態(tài)的配置示损，也可以動態(tài)的通過資源管理進行管理渗磅。
在多用戶的集群下提供更好的spark job的SLA
一般來說在多用戶的集群下的ETL任務需要更加便捷的一中定義組織化的隊列。這種策略能夠幫助我們定義更加嚴格的SLA 任務的執(zhí)行检访。
YuniKorn能夠讓管理者讓任務以FIFO/FAIR的方式運行始鱼，這個StateAwarePolicy順序任務，以一個接一個的方式運行脆贵。這在提交大量批任務的時候避免的競爭医清，如在同一個集群的spark任務。通過指定任務的順序卖氨，也能提高任務調度的可預見性会烙。
對于spark任務的調度支持各種k8s特性
YuniKorn 完全兼容k8s的主特性，用戶可以無感知的替換調度器筒捺。YuniKorn 支持k8s所有調度原生的8s語義柏腻，如標簽選擇，pod的親和性系吭，pv/pvcs等五嫂，YuniKorn也兼容資源管理命令行和組件，像cordon nodes和通過kubectl獲取事件等肯尺。
本文翻譯自Apache Spark on Kubernetes:How Apache YuniKorn(Incubating) helps
