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

為了方便 Kubernetes 部署所需要的文件（yaml），普遍的做法都是利用 helm 或是 kustomize 將不同 vendor 的設定給獨立出來。Gthulhu 則是使用筆者較為熟悉的 helm 來管理 k8s 部署，方便使用者快速的將 Gthulhu 運作在 k8s 上。

考慮到 Gthulhu 想解決的場景是「多節點叢集」環境，每一個節點其實都需要運作單獨的 Gthulhu 排程器，以及各自的 API Server。

每一個節點都需要運作單獨的 Gthulhu 排程器很好理解，就是每一個節點自己處理本身需要排程的任務們。至於 API Server 為何也需要這樣，則是受限於 PID 的關係。因此我們可以預期，如果要讓 Gthulhu 轉變成能夠運作在多節點叢集的解決方案，我們至少需要：

1. 考慮 Pod Generator 的類型：常見的 Pod Generator 有 ReplicaSet / DaemonSet / StatefulSet，它們有各自不同的特性。對於「每一個節點都需要運作單獨的排程器與 API server」這個需求來說，DaemonSet 就是最佳人選。
2. [TODO] 考慮 K8s 的 service discovery 機制：要讓 Gthulhu 永遠向同節點的 API server 溝通，這樣 Gthulhu 才能拿到正確的 Scheduling Policy（因為有 PID）。
3. [TODO] 需要有一個 Operator 能夠管理每一個節點的 API Server，由它接受使用者的真正意圖，最後再向每一個節點的 API Server 更新規則。

第二點問題可以靠 Operator 來解決，只要：

1. API server 啟動時透過 k8s service 向 Operator 進行註冊，並且於註冊時提供自己的 Cluster IP 以及 K8s Node Name
2. Gthulhu Scheduler 嘗試向 API Server 抓取 scheduling policy 之前，向 Operator 詢問自己節點下的 API Server 的 Cluster IP 為何
3. 如此一來，Scheduler 就能準確的找到位於同個節點下的 API Server。