開始前

感謝評審的青睞，讓這份作品取得分組優選的好成績。在得獎的同時，Gthulhu 也成功收錄至 CNCF Landscape：

新的一年我將繼續努力，爭取讓 Gthulhu 成為 CNCF 第一個 MIT 的開源專案 [cncf/sandbox #426]。

進入正題

要讓 Gthulhu 能夠管理多個節點的工作負載，以原本 API Server 的架構有諸多困難：

• 取得每個節點上 Pod 與 Pid 的對應關係
• 傳播「正確的」策略至特定節點的 Gthulhu 排程器
• API Server 不具備無狀態的特性

因此，我們套用了 k8s 常見的 operator pattern + sidecar pattern 來解決這個問題：

API server 改為支援兩種模式，分別是 manager 與 decision maker：

• manger 只需要有一個（k8s deployment with replica = 1）。

• decision maker 每一個 node 都需要一個（k8s daemonset?）。

• manager 提供前端與使用者相關 API，接受使用者給的 intent（也就是 json 格式的資料，包含 prioriy、execution time 以及 label selector）。

• manger 是 k8s client，知道哪些 pod 運作在哪些 node 上。

• manager 會用 policy 找到對應的 pod，看這些 pod 位於哪些節點，將 intent 轉發給目標節點上的 decision maker。

• decision maker 與 host 共享 PID namespace，根據 manager 傳來的 intent 找出 match 的 PIDs，最後靜靜等待 Gthulhu 定期向它抓取策略。

• Manager 作為中央管理服務，負責：

  • 使用者認證與授權（JWT）
  • 角色與權限管理（RBAC）
  • 排程策略的 CRUD 操作
  • 通過 Kubernetes Informer 監控 Pod 狀態
  • 將排程意圖分發到各節點的 Decision Maker
  • 資料持久化至 MongoDB：避免 single point of failure 造成策略的遺失。

• Decision Maker（節點代理）以 sidecar 形式部署在每個 Kubernetes 節點上的 scheduler pod，負責：

  • 接收來自 Manager 的排程意圖
  • 掃描 /proc 檔案系統以發現 Pod 進程
  • 將排程策略（基於標籤）轉換為具體的 PID 級別排程決策
  • 向本地 Gthulhu 排程器提供 PID 級別的策略
  • 收集 eBPF 排程器指標並通過 Prometheus 暴露

總結

如果 Decision Maker 使用 DaemonSet 部署，乍看之下也會讓每個節點都存在一個 Decision Maker，但我們無法讓 Gthulhu scheduler 透過 K8s 的 Service 機制找到自身所處節點上的 Decision Maker，故我們只能採用 Sidecar 的形式來解決這個問題。

• 如果你對於 Gthulhu 感興趣，歡迎參考文件：使用 Gthulhu 管理多節點策略
  ，一步步了解如何調整你在 K8s 上的工作負載。
• 如果你對成為 Gthulhu 專案的維護者感興趣，歡迎寄信至 gthulhu.scheduler@gmail.com 詢問。