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