From 9f856f217f989642dee7e1dc3b3b045eeea2535a Mon Sep 17 00:00:00 2001 From: Pinghao Wu Date: Sun, 22 Sep 2024 20:57:01 +0800 Subject: [PATCH] Architecture: LimitRange --- Sections/4.Architecture.tex | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/Sections/4.Architecture.tex b/Sections/4.Architecture.tex index 553b14e..70c515d 100644 --- a/Sections/4.Architecture.tex +++ b/Sections/4.Architecture.tex @@ -100,7 +100,7 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使 \section{權限開通實做} \label{sec:provisioner} -使用者權限開通的主要流程為：建立一個 Namespace，對其設定配額，增加 admission controllers 政策相關標記，最終調整 RBAC 授予使用者此 Namespace 下的權限。為了將其自動化，我們規劃為拓展 Kubernetes API，使用自訂 resource 種類進行實做，此種類稱為 User。使用者登入網頁界面時會自動嘗試創立代表自身的 User，若已存在代表已開通完成不須另外動作。面對新創立的 User，我們撰寫的 controller 會實行上述的開通流程。 +使用者權限開通的主要流程為：建立一個 Namespace，增加 admission controllers 政策相關標記，對其設定配額，最終調整 RBAC 授予使用者此 Namespace 下的權限。為了將其自動化，我們規劃為拓展 Kubernetes API，使用自訂 resource 種類進行實做，此種類稱為 User。使用者登入網頁界面時會自動嘗試創立代表自身的 User，若已存在代表已開通完成不須另外動作。面對新創立的 User，我們撰寫的 controller 會實行上述的開通流程。 \begin{figure}[htb] \centering @@ -127,7 +127,7 @@ Namespace 上 \verb|u-| 以及平台提供域名中 \verb|u.| 的命名切分設 \subsection{ResourceQuota} -ResourceQuota 是 Kubernetes 的一個 resource 種類，用來實做資源配額，其運作邏輯大致分兩大塊：admission controller 與一般的 controller。ResourceQuota 的 admission controller 屬於 validating，負責在創立或更新 resource 時推算其資源用量的變化值，並且拒絕用量會超出配額的請求。一般的 controller 端則是以更為全面的觀點，監控整體 resources 的變更，並且統計資源用量總額。 +ResourceQuota 是 Kubernetes 的一個 resource 種類，用來實做單一 Namespace 下的資源配額，其運作邏輯大致分兩大塊：admission controller 與一般的 controller。ResourceQuota 的 admission controller 屬於 validating，負責在創立或更新 resource 時推算其資源用量的變化值，並且拒絕用量會超出配額的請求。一般的 controller 端則是以更為全面的觀點，監控整體 resources 的變更，並且統計資源用量總額。 ResourceQuota 所能管控的資源大致有兩種：運算資源以及 resources 的數量。運算資源具有量值，例如部屬容器時設定的 CPU 或者記憶體用量限制，以及 PersistentVolumeClaim (PVC)\footnote{PVC: Resources 種類，表示儲存空間請求，需自動或手動與 PersistentVolume（PV，分配實體）耦合。} 中的儲存用量請求。Resources 的數量則是滿足特定條件的 resources 的個數，例如正在運行的 Pods。 @@ -135,6 +135,12 @@ ResourceQuota 所能管控的資源大致有兩種：運算資源以及 resource 除了運算資源，以及上述針對 resource 內容的管控，我們也對所有使用者能夠創立的 resources 種類進行總量限制，避免濫用。在其限額設計上，我們仍盡量保持讓使用者可以在運算資源限制合理地自由運用。 +\subsection{LimitRange} + +在有使用 ResourceQuota 限制總運算資源用量的情況，所有的 Pods 必須設定容器的相關資源限制。這點十分容易影響使用者體驗，資源限制在 API 上並非必填，以 Kubernetes 通常經由高層次 resources （如 Deployment）去控管 Pods 的方式，如果在高層次 resources 中的 Pod 模板並未填寫資源限制，創立當下並沒有影響，而是在相關 controller 創立 Pod 時才發生錯誤，對使用者來說較難除錯。另外，部份常用代為呼叫 API 的手段如 \verb|kubectl create deployment| 也沒有途徑可以填寫限制。 + +對於這個場景，我們可以使用 LimitRange resource 種類。LimitRange 透過 LimitRanger admission controller 限制使用者能夠填寫的資源限制大小範圍，同時也能夠在未填寫的狀況下套用預設值協助補足。LimitRange 如同 ResourceQuota，以單一 Namespace 為作用範圍。我們使用 LimitRange 實做資源限制預設值，以提昇有總量限制下的使用者體驗。 + \section{網頁界面實做} 進一步對網頁界面的需求分析，可以將網頁界面切分為兩大塊：支援 Helm 的通用 Kubernetes 網頁型客戶端，以及 CSKloud 特定的部份，包含權限開通元件的整合以及 CSKloud 平台面向使用者的文件等。其中 Kubernetes 客戶端很容易的就可以利用於其他場景，我們採取 open core 的策略，將其 Kubernetes 客戶端開放原始碼，以 MIT 授權條款\footnote{MIT license: 一個在網頁技術場域廣受歡迎的寬鬆型開放原始碼條款。}釋出，命名為 Sparkles\footnote{Sparkles 釋出於 \url{https://github.com/xdavidwu/sparkles} 。}，回饋於社會，使得非平台使用者也能受益，同時可以也利用開放原始碼社群的力量來茁壯平台的發展。 -- 2.45.2