~xdavidwu/cskloudv3-thesis

9f856f217f989642dee7e1dc3b3b045eeea2535a — Pinghao Wu 3 months ago 23db55f
Architecture: LimitRange
1 files changed, 8 insertions(+), 2 deletions(-)

M Sections/4.Architecture.tex
M Sections/4.Architecture.tex => Sections/4.Architecture.tex +8 -2
@@ 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} 。},回饋於社會,使得非平台使用者也能受益,同時可以也利用開放原始碼社群的力量來茁壯平台的發展。