# 【閱讀紀錄】Next Level Spark on Kubernetes with Apache YuniKorn (Incubating) - Weiwei Yang, Chaoran Yu <iframe width="560" height="315" src="https://www.youtube.com/embed/gOST-iT-hj8?si=s2bLVfRX7q4_iMfK" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> > https://youtu.be/gOST-iT-hj8?si=AFvmL_wk8oAi6U47 ## YuniKorn 簡介 YuniKorn 是一個 standalone 的 K8s 排程器，可以取代預設排程器（default scheduler） 主要目標是為了加強 **Large Scale Batch Jobs** 以及 **Multi-Tenancy** 這兩種情境下的問題以及效率 ## 沒有 YuniKorn 時的挑戰 ### Resource Quota Hard Limit 原生的 K8s 雖然可以透過設定 `ResourceQuota` 來限制資源的使用上限 但這個上限屬於 hard limit 當資源不足時，發出的請求只會立即得到拒絕的結果 想像若在一個資源有限的環境當中 一直有新的請求不斷從各個來源產生，並且資源占用率總是瀕臨上限 可以想見請求的失敗率會很高 各個呼叫方需要自己實作 retry 的邏輯 更糟的是，各個資源請求者之間還會變成互相競爭資源的狀態 沒有一個公平的機制能將資源分配給不同使用者 也無法根據任務的重要程度來優先分配資源 期望有個排隊（queue）的機制，讓請求可以排隊等待資源 而不是直接被拒絕 同時，還能根據任務的優先度，聰明地分配資源給不同需求 ### 潛在的 Deadlock 可能 以 Spark 為例 一個 Spark Job 由一個 Driver Pod 及多個 Executor Pods 組成： - Driver Pod 負責管理 Spark Job 的狀態，並協調底下的 Executor Pods - Executor Pods 負責執行具體任務 在部署時，希望一個 Spark Job 的所有 Pods（Driver 和 Executors）都能同時部署成功 不要因為資源不足，而出現部分成功部分失敗的情形 希望全有或全無（All-or-Nothing） 假設一次部署 100 個 Spark Jobs 的情境下 預設的 K8s scheduler 行為，可能都只有 Driver Pod 被部署成功 但由於資源不足，Executor Pods 完全無法部署 結果是資源都被 Driver Pod 佔盡，卻沒辦法執行任何 Spark Job，導致 deadlock 的發生 期望可以視一個 Spark Job 為一個 App 的概念 一次部署整個 App，而不是單獨處理每個 Pod ### Large Pod Could Be Starving Forever 假設有個 cluster 有 10 個單位的 quota： - A Job 需要整整 10 個單位才能運行 - B Job 只需要 1 個單位 假設 B Job 先被發出，且 B Job 源源不絕的出現 也就是 cluster 中的 quota 永遠不足 10 個單位 這將導致 A Job 永遠無法成功被部署 若有一個排隊（queue）的機制 讓請求可以按照時間的順序被處理，或者是設定 priority 則 A Job 便有機會等到資源被部署 不會因為 B Job 不斷搶占資源而永遠無法被部署 ### Multi-Tenancy 想像有多個 team 要共享同一個 cluster 的資源 現在 K8s 缺乏一個簡單的方法，針對不同 team 做彈性的 quota 設定 ## Spark 的運作流程 High-level 介紹 [13:43](https://youtu.be/gOST-iT-hj8?t=823&si=Ir2U0VGoOxML6Cib) ![image](https://hackmd.io/_uploads/rkFlO6kukx.png) 1. 提交 spark job 給 K8s，建立 driver pod 2. （driver pod 處於 pending 狀態） 3. 根據預先的設定，該 driver pod 配置在特定的 queue 之下 4. ==YK 對 queue 和 app 進行排序篩選，找出要先被處理的 request，並且分配相應的 node== 5. （假設要來處理該 driver pod，且有合適對應的 node） 6. YK 向 K8s 發出請求，將 driver pod bind 至 node 7. （driver pod 進入 running 狀態） 8. driver pod 向 K8s 請求建立 executor pods 9. （複數個 executor pods 進入 pending 狀態） 10. YK 偵測到這些新的請求後，放入 queue 當中，重複以上步驟 和 default scheduler 的關鍵差異在於 YK 多了 queue 及 app 的抽象概念 ## Apple 使用 YuniKorn 的情境 - 平台上有 large scale 的 batch processing 需要處理，大約需要跑數個小時 - 同時平台上也有其他的 user 和 team，因此需要分配資源的運用，multi-tenancy ## 使用的情形 ![image](https://hackmd.io/_uploads/rkTreJg_1g.png) ![image](https://hackmd.io/_uploads/SyGQZxWdke.png) ![image](https://hackmd.io/_uploads/rkhbLebd1g.png) - 目前 Apple 內部用於處理 spark batch processing 的 cluster 已完全使用 YuniKorn 進行取代 - 每個 team 都有指定的 queue 以及相應的 resource quota - YK 提供介面監控 resource 的使用情形 - 運行在 AWS EKS 上 --- ## Demo（編輯中） ### Spark SparkOperator?