iT邦幫忙

2025 iThome 鐵人賽

DAY 19
0

如果覺得文章對你有所啟發,可以考慮用 🌟 支持 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,觀察活躍用戶的變化。

上一篇
scx_goland_core 移植與挑戰(三):data unsync
下一篇
Gthulhu API Server Design
系列文
30 篇文帶你用 eBPF 與 Golang 打造 Linux Scheduler21
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言