如果覺得文章對你有所啟發，可以考慮用 🌟 支持 Gthulhu 專案，短期目標是集齊 300 個 🌟 藉此被 CNCF Landscape 採納 [ref]。

在前一篇文章中有提到：

• 需要規劃一個 API Server，讓 Gthulhu 能夠與其溝通，取得使用者下達的排程器策略，實現 "Scheduling Policy As Configuration" 的概念。
• 如果可以，整合 MCP，使 Gthulhu 能夠與 Coding Agent 互動。

其實都已經順利達成了，所以今天的文章不會包含密密麻麻的實作細節還有程式碼，而是會從幾個面向來討論我當初實作 API server 時在想什麼。

考慮到 User-Space Scheduler 被分配到的 cpu time 應該不能有不必要的浪費（決定 cpu 與資源應該越快越好，才能提高排程器的吞吐量），任何不參與決策的雜事應該由其他的服務完成，像是：

• 處理使用者的意圖
• 根據意圖尋找對應的 Pod，以及對應的 PID

所以我決定額外開發一個 API Server 來處理這些東西，讓 User-Space scheduler 只有在必要時才需要處理 api server 交給他的決策。並且，考慮到如果使用者頻繁改變它的意圖，User-Space scheduler 不應該每次都即時的給予響應，所以我將 scheduler 與 api server 的互動模式設計成由 scheduler 每隔一段時間向 api server 索取新規則，而非當 api server 處理完客戶端的請求就直接將規則送往 scheduler。

透過這樣解耦合的方式，雖然有效避免 scheduler 浪費寶貴的 cpu quota，但會需要考慮溝通方式的安全性。
目前實作的暫解是：

• api server 有一對 rsa 密鑰
• scheduler 有 public key
• scheduler 詢問 api server 規則時，需要先向 api server 取得 JWT token
• scheduler 取得 JWT token 的過程中需要在請求中帶入 public key，方便 api server 使用 private key 驗證
• 若驗證成功，使用 private key 發行 JWT Token，並且給予合理的使用時效

基本上就是很簡單的系統設計，但可以暫時保證溝通層面的安全。

有了 api server，其實我們就讓排程器本身有機會提供更豐富的功能，舉例來說：我可以使用 MCP，Coding Agent 或是語言模型跟 api server 溝通，透過聊天的方式把 scheduling policy 聊出來。而且我也已經做到：

然而，考慮到 Gthulhu 想解決的場景是「多節點叢集」，所以要讓 api server 如何優雅的在多節點叢集下工作，也是個需要耗費腦力的挑戰！這部分我們就在下回分曉：）