SIG Scheduling 焦點報導
在本次 SIG 排程焦點報導中，我們與 SIG 排程的核准者 Kensei Nakada 進行了訪談。
簡介
Arvind： 您好，感謝您提供這次機會讓我們更深入了解 SIG 排程！您是否願意自我介紹，並談談您的職責，以及您如何參與 Kubernetes 的？
Kensei：嗨，感謝您提供這次機會！我是 Kensei Nakada（@sanposhiho），Tetrate.io 的軟體工程師。我貢獻 Kubernetes 專案已超過 3 年的業餘時間，現在我是 Kubernetes 中 SIG 排程的核准者。此外，我也是兩個 SIG 子專案 kube-scheduler-simulator 和 kube-scheduler-wasm-extension 的創始人/所有者。
關於 SIG 排程
AP：太棒了！您參與這個專案已經很久了。您是否可以簡要概述 SIG 排程，並說明其在 Kubernetes 生態系統中的角色？
KN：顧名思義，我們的職責是增強 Kubernetes 內的排程功能。具體來說，我們開發元件來決定哪個節點是每個 Pod 的最佳位置。在 Kubernetes 中，我們的主要重點是維護 kube-scheduler，以及其他與排程相關的元件，作為我們 SIG 子專案的一部分。
AP：我明白了，了解了！這讓我很好奇，SIG 排程最近為 Kubernetes 排程引入了哪些創新或發展？
KN：從功能角度來看，最近對 PodTopologySpread 進行了 幾項增強功能。PodTopologySpread 是排程器中相對較新的功能，我們仍在收集回饋並進行改進。
最近，我們一直專注於一項名為 QueueingHint 的全新內部增強功能，旨在提高排程吞吐量。吞吐量是我們排程中的關鍵指標之一。傳統上，我們主要關注最佳化每個排程週期的延遲。QueueingHint 採取不同的方法，最佳化重試排程的時間，從而降低浪費排程週期的可能性。
A：聽起來很有趣！您目前在 SIG 排程中還在處理哪些其他有趣的主題或專案？
KN：我正在領導 QueueingHint 的開發，這是我剛才分享的。鑑於這對我們來說是一項重大的新挑戰，我們遇到了許多意想不到的挑戰，尤其是在擴充性方面，我們正試圖解決每個挑戰，以便最終預設啟用它。
此外，我相信我去年啟動的 kube-scheduler-wasm-extension（一個 SIG 子專案）會讓很多人感興趣。Kubernetes 有來自許多元件的各種擴充功能。傳統上，擴充功能是透過 webhook（排程器中的 extender）或 Go SDK（排程器中的 Scheduling Framework）提供的。然而，這些都存在缺點 - webhook 的效能問題，以及使用 Go SDK 需要重建和替換排程器，這對那些希望擴充排程器但又不熟悉它的人造成了困難。該專案正試圖為這一普遍挑戰引入一個新的解決方案 - 基於 WebAssembly 的擴充功能。Wasm 讓使用者可以輕鬆建置外掛程式，而無需擔心重新編譯或替換他們的排程器，並迴避效能問題。
透過這個專案，SIG 排程一直在學習關於 WebAssembly 與大型 Kubernetes 物件互動的寶貴見解。我相信我們正在獲得的經驗應該在社群內廣泛適用，而不僅僅是在 SIG 排程內。
A：當然！現在，SIG 排程內部有 8 個子專案。您是否願意談談它們？您想重點介紹這些團隊的一些有趣貢獻嗎？
KN：讓我挑選三個子專案：Kueue、KWOK 和 descheduler。
- Kueue
- 最近，許多人一直在嘗試使用 Kubernetes 管理批次工作負載，在 2022 年，Kubernetes 社群成立了 WG-Batch，以更好地支援 Kubernetes 中的此類批次工作負載。Kueue 是一個在其中發揮關鍵作用的專案。它是一個工作佇列控制器，用於決定工作何時應等待、工作何時應被允許開始以及工作何時應被搶佔。Kueue 旨在安裝在 Vanilla Kubernetes 叢集上，同時與現有的成熟控制器（排程器、叢集自動擴展器、kube-controller-manager 等）協作。
- KWOK
- KWOK 是一個元件，您可以在其中於幾秒鐘內建立一個包含數千個節點的叢集。它主要用於模擬/測試，作為輕量級叢集，實際上另一個 SIG 子專案 kube-scheduler-simulator 使用 KWOK 背景。
- descheduler
- Descheduler 是一個重新建立在不想要的節點上執行的 Pod 的元件。在 Kubernetes 中，排程約束（
PodAffinity、NodeAffinity、PodTopologySpread等）僅在 Pod 排程時受到尊重，但不保證約束在之後會一直保持滿足。Descheduler 會逐出違反其排程約束（或其他不想要的條件）的 Pod，以便重新建立和重新排程它們。 - Descheduling Framework
- 一個非常有趣的進行中專案，類似於排程器中的 Scheduling Framework，旨在使 Descheduler 邏輯可擴充，並允許維護者專注於建置 Descheduler 的核心引擎。
AP：感謝您告知我們！我必須問，您最喜歡這個 SIG 的哪些方面？
KN：我真正喜歡這個 SIG 的地方是每個人的積極參與程度。我們來自不同的公司和產業，將不同的觀點帶到談判桌上。這些差異非但沒有造成分裂，反而產生了大量的意見。每個觀點都受到尊重，這使得我們的討論既豐富又富有成效。
我非常欣賞這種協作氛圍，我相信這是多年來不斷改進我們元件的關鍵。
貢獻 SIG 排程
AP：Kubernetes 是一個社群驅動的專案。對於希望參與並貢獻 SIG 排程的新貢獻者或初學者，您有任何建議嗎？他們應該從哪裡開始？
KN：讓我先從一個適用於貢獻任何 SIG 的一般建議開始：常見的方法是尋找 good-first-issue。但是，您很快就會意識到，世界各地有很多人試圖貢獻 Kubernetes 儲存庫。
我建議從檢查您感興趣的元件的實作開始。如果您對此有任何疑問，請在相應的 Slack 頻道中提問（例如，排程器的 #sig-scheduling、kubelet 的 #sig-node 等）。在您大致了解實作之後，請查看 SIG 內的問題（例如，sig-scheduling），您會在其中找到比 good-first-issue 問題更多未分配的問題。您可能還想使用 kind/cleanup 標籤篩選問題，該標籤通常表示較低優先順序的任務，並且可以作為起點。
特別是對於 SIG 排程，您應該首先了解 Scheduling Framework，這是 kube-scheduler 的基本架構。大多數實作都可以在 pkg/scheduler 中找到。我建議從 ScheduleOne 函數開始，然後從那裡更深入地探索。
此外，除了主要的 kubernetes/kubernetes 儲存庫之外，還可以考慮查看子專案。這些專案的維護者通常較少，並且提供更多機會來產生重大影響。儘管被稱為「子」專案，但許多專案都有大量使用者，並且對社群產生了相當大的影響。
最後但並非最不重要的一點是，請記住對社群的貢獻不僅僅是程式碼。雖然我談了很多關於實作貢獻的內容，但有很多種貢獻方式，每種方式都很有價值。對問題的一則評論、對現有功能的一則回饋、PR 中的一則審查評論、對文件的一則澄清；每一個小的貢獻都有助於推動 Kubernetes 生態系統向前發展。
AP：這些都是非常實用的技巧！如果我可以問一下，您如何協助新的貢獻者入門，以及貢獻者參與 SIG 排程可能會學到哪些技能？
KN：我們的維護者可以回答您在 #sig-scheduling Slack 頻道中的問題。透過參與，您將更深入地了解 Kubernetes 排程，並有機會與來自不同背景的維護者協作和交流。您不僅將學習如何編寫程式碼，還將學習如何維護大型專案、設計和討論新功能、解決錯誤等等。
未來方向
AP：在排程方面，Kubernetes 特有的挑戰有哪些？是否有任何特定的痛點？
KN：Kubernetes 中的排程可能非常具有挑戰性，因為不同組織的需求各異，業務需求也不同。在 kube-scheduler 中支援所有可能的用例是不可能的。因此，可擴充性是我們的重點。幾年前，我們使用 Scheduling Framework 重新架構了 kube-scheduler，它為使用者提供了靈活的可擴充性，可透過外掛程式實作各種排程需求。這允許維護者專注於核心排程功能和框架執行時間。
另一個主要問題是維持足夠的排程吞吐量。通常，一個 Kubernetes 叢集只有一個 kube-scheduler，因此它的吞吐量直接影響整體排程擴充性，進而影響叢集的擴充性。儘管我們有一個內部效能測試 (scheduler_perf)，但不幸的是，我們有時會忽略不太常見場景中的效能下降。這很困難，因為即使是很小的變更，看起來與效能無關，也可能導致效能下降。
AP：SIG 排程有哪些即將到來的目標或計畫？您如何設想 SIG 未來的發展？
KN：我們的主要目標始終是建置和維護可擴充且穩定的排程執行時間，我敢肯定這個目標將永遠不變。
如前所述，可擴充性是解決多樣化排程需求挑戰的關鍵。我們將繼續專注於增強可擴充性，以便它可以適應各種用例，而不是嘗試直接在 kube-scheduler 中支援每個不同的用例。我提到的 kube-scheduler-wasm-extension 也是此計畫的一部分。
關於穩定性，引入像 QueueHint 這樣的新最佳化是我們的策略之一。此外，維持吞吐量也是未來的一個關鍵目標。我們計劃增強我們的吞吐量監控 (ref)，以便我們可以在發布之前盡可能多地注意到效能下降。但是，實際上，我們無法涵蓋所有可能的場景。我們非常感謝社群對排程吞吐量的任何關注，並鼓勵就效能問題提供回饋和警報！
結語
AP：最後，您想對那些有興趣了解更多關於 SIG 排程的人傳達什麼訊息？
KN：排程是 Kubernetes 中最複雜的領域之一，您可能會覺得一開始很困難。但是，正如我之前分享的，您可以找到許多貢獻機會，並且許多維護者都願意幫助您理解事物。我們知道您獨特的觀點和技能使我們的開源如此強大 😊
隨時透過 Slack (#sig-scheduling) 或 會議 與我們聯繫。我希望這篇文章能引起大家的興趣，我們可以看到新的貢獻者！
AP：非常感謝您撥冗進行這次訪談！我確信許多人會發現這些資訊對於更深入了解 SIG 排程和為 SIG 做出貢獻非常有價值。