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

前三篇文章將焦點放在 qumun 誕生的歷程，今天就來談一下當初規劃 Gthulhu 這個專案時想到的設計要點：

• 直接利用 qumun 框架，打造一個面向雲端原生且穩定的排程器方案：
  • 這部分已經達成，目前 Gthulhu 透過 git submodule + go replace 的方式直接使用 qumun 提供的 eBPF program 與相對應的 APIs。
  • eBPF program 主要利用 scx_rustland，我們可以時時刻刻保持與 upstream 的聯繫，一邊發展自己的特色，同時也能站在巨人的肩膀上持續前進。
  • 主要戰場定位在 Kubernetes 生態系，使用者提供意圖（intent），讓 Gthulhu 幫你完成！
• Gthulhu 需要提供與使用者之間的橋樑：
  • 需要規劃一個 API Server，讓 Gthulhu 能夠與其溝通，取得使用者下達的排程器策略，實現 "Scheduling Policy As Configuration" 的概念。
  • 如果可以，整合 MCP，使 Gthulhu 能夠與 Coding Agent 互動。
• Gthulhu 在進入正式的 Release 之前，至少需要有一個足夠強力的 PoC 來向展示潛在用戶展示雲端原生排程器的魅力：
  • 選擇我熟悉的戰場，把 free5GC 與 Gthulhu 進行整合。
• 盡可能的容易安裝與部署：
  • 利用 eBPF CORE 的特性，以 container image 的方式發布軟體。
  • 提供 helm chart 讓用戶可以快速的部署 Gthulhu。
• 需考慮多節點叢集的架構
  • 除了 API Server，最後仍需要一個管理系統管理所有節點的排程器與 API server。
  • 需考慮權限問題。
  • 需提供一定的可觀測性。
• 提供足夠資訊的官方文件
  • 提供社群雙向交流的管道，在各大社群推廣，並且成立 Advisory Board。
  • 先埋好 Search Console 與 GA，觀察活躍用戶的變化。
  • 觀察 GitHub Traffic，觀察活躍用戶的變化。