概念與角色¶

瞭解平台的租戶模型和權限系統，有助於您更有效地使用專案、群組和儲存。

租戶層級結構¶

平台上的資源以階層方式組織：

graph TD
    Admin[平台管理員] -->|建立| Group[群組\n例如：研究實驗室]
    Group -->|包含| Project[專案\n例如：LLM 微調]
    Project -->|啟動| Workspace[工作區 / IDE]
    Project -->|繫結| ProjStorage[專案儲存 PVC]
    Group -->|擁有| GroupStorage[群組儲存 PVC]
    GroupStorage -->|繼承至| ProjStorage

實體	說明
群組	團隊或部門。群組擁有共享儲存空間，可作為多個專案的成員。
專案	主要的資源分配單位。持有 GPU/CPU 配額、設定檔和部署。
工作區	互動式 IDE（JupyterLab / VSCode），在專案配額內運行。
儲存（PVC）	持久化磁區宣告；在工作區重啟後資料仍會保留。

配額生命週期¶

flowchart LR
    Admin["管理員定義\n資源計畫"] -->|指派給| Project[專案]
    Project -->|配額強制於| Launch[工作區啟動]
    Launch -->|建立| DRA["DRA ResourceClaim"]
    Launch -->|使用| Queue[平台佇列]
    DRA -->|配置| GPULimit["GPU / SM 比例"]
    Queue -->|套用| Priority["優先序 / 搶佔政策"]

每個專案由管理員指派一個 資源計畫。當您啟動工作區時，平台會先驗證專案配額與個別使用者配額，再為 Pod 建立 Kubernetes DRA 資源。

計畫同時帶有：

允許的 GPU 型號 清單——啟動表單中只會顯示這些型號。
選用的 排程窗口，限制計畫綁定佇列何時可用（見下方 計畫窗口）。
一個或多個 綁定佇列，附帶優先序、搶佔與 GPU 型號政策。

排程佇列、優先序與搶佔¶

工作負載會選擇一個 平台佇列。佇列紀錄仍會同步到 Volcano Queue CRD 作為政策相容層；DRA GPU Pod 則透過 Kubernetes default-scheduler 與 ResourceClaim 排程。每個佇列具備優先序、可選的搶佔旗標，以及可選的 deserved GPU 上限：

概念	意義
優先序	當 GPU 緊張時，優先序較高的佇列會先排程。
可被搶佔	此佇列中的 Pod 可以被驅逐，把 GPU 讓給更高優先序的佇列。
Deserved GPU	即使其他佇列競爭，也能保證的 GPU 底量。值為 `0` 表示「victim」佇列，會優先被排乾資源。

預設佇列永遠可用；計畫綁定的佇列會與預設佇列並列在工作區及部署表單中。

計畫窗口¶

計畫窗口 是計畫綁定佇列可使用的時間區段。窗口以外，計畫綁定佇列停止排程新的 Pod，且平台 plan-window reaper 可能會驅逐這些佇列中正在執行的 Pod；預設佇列不受影響。

儀表板會顯示距離下個邊界（開啟／關閉）的即時倒數，使用者可以選擇切到預設佇列或等下一個窗口開啟，避免被驅逐。

DRA Resource Claim¶

平台上的 GPU 透過 Kubernetes Dynamic Resource Allocation（DRA） ResourceClaim 配置。每個 claim 描述：

裝置類別（例如特定 GPU 型號）
SM 比例——描述要求的 GPU 計算時間比例
VRAM 模式——elastic 與其他 claim 共享 VRAM；hard_cap 強制使用上限

claim 有兩種建立方式：

inline claim——啟動工作區時自動建立、與 Pod 共生命週期，Pod 刪除時 claim 也跟著消失。
專案管理 claim——從專案的 GPU Claims 標籤建立，可被 Pod 或 Deployment 設定檔重複使用。它在 Kubernetes DRA 完成配置且 reservedFor 指向 live Pod 前都是 pending contract；只有 bound 狀態會計入配額與 resource-hours。

設定檔會透過具名部署時 slot 參照專案管理 claim，例如 platform-go/dra-claim-name: '{{ gpuClaimName "train-a" }}'。slot 名稱不是 claim 名稱；部署者會把每個 slot 對應到自己的 ResourceClaim。多 replica Deployment 會共用同一個 claim allocation，並以每個 claim 計算一次。單一 Kubernetes Deployment 無法讓不同 replica 使用不同 claim，因為所有 replica 共用同一份 PodTemplate；若只有部分 Pod 要使用 claim，請拆成多個 Deployment。

角色權限¶

系統角色¶

權限	使用者	管理者	管理員
在配額內使用工作區	✓	✓	✓
建立個人專案	✓	✓	✓
提交資源申請	✓	✓	✓
存取管理面板		✓	✓
管理所有使用者 / 群組			✓
定義資源計畫			✓
管理平台佇列			✓
查看稽核日誌		✓	✓
RBAC 策略管理			✓

專案角色¶

權限	成員	管理者	管理員
啟動工作區	✓	✓	✓
查看專案設定	✓	✓	✓
編輯設定檔		✓	✓
管理部署		✓	✓
新增/移除成員			✓
刪除專案			✓

群組角色¶

權限	成員	管理員
存取群組儲存	✓	✓
查看群組成員	✓	✓
新增/移除成員		✓
設定儲存權限		✓

儲存權限模型¶

儲存權限採用雙路徑繼承模型：

flowchart TD
    GroupAdmin["群組管理員\n設定權限"] -->|批次設定| GroupStorage["群組 PVC\n（權限來源）"]
    GroupStorage -->|繼承，唯讀| ProjectView["專案儲存頁面\n群組成員的檢視"]
    ProjectAdmin["專案管理員"] -->|直接管理| DirectPerms["專案儲存\n非群組成員的權限"]
    DirectPerms --> ProjectView

群組成員 的儲存權限永遠從群組層級繼承，無法在專案層級覆蓋。
非群組的專案成員 權限直接在專案層級管理。

關鍵術語¶

術語	定義
PVC	持久化磁區宣告——Kubernetes 儲存資源，Pod 重啟後資料仍保留
平台佇列	命名的排程政策，控制優先序、搶佔、計畫窗口與選用 GPU 型號親和性
計畫窗口	計畫綁定佇列可使用的時間區段
搶佔（Preemption）	驅逐可被搶佔佇列中的 Pod，把資源讓給更高優先序的工作
DRA	Dynamic Resource Allocation，Kubernetes 透過 ResourceClaim 物件配置 GPU 的 API
ResourceClaim	DRA 物件，用來請求 fractional 或整顆 GPU；平台管理的 standalone claim 只有綁定 live Pod 時才消耗配額
設定檔	版本化的 Kubernetes YAML/設定，以內容定址的不可變方式儲存
SM 比例	Streaming Multiprocessor share percentage，用於描述 fractional GPU compute allocation
資源計畫	命名範本，定義專案的 GPU、CPU、記憶體上限、允許的 GPU 型號與排程窗口
儲存通道（Storage Lane）	對應 PVC 配置方式的 profile（`shared-rwx`、`legacy-rwx`、`fast-rwo`）
內容定址儲存（CAS）	檔案以 SHA-256 雜湊值識別的儲存方式，確保不可變性
ltree	PostgreSQL 資料型別，用於階層式樹狀路徑（用於巢狀專案）
工作區	互動式雲端 IDE（JupyterLab、VSCode），運行於 Kubernetes Pod 中