From cde04e104d42415691f752c725b84fad117d42e7 Mon Sep 17 00:00:00 2001 From: Pinghao Wu Date: Sat, 21 Sep 2024 17:24:37 +0800 Subject: [PATCH] make namespace casing consistent --- Sections/0.2.Abstract_chinese.tex | 2 +- Sections/4.Architecture.tex | 14 +++++++------- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/Sections/0.2.Abstract_chinese.tex b/Sections/0.2.Abstract_chinese.tex index 256a9df..4c7fbfd 100644 --- a/Sections/0.2.Abstract_chinese.tex +++ b/Sections/0.2.Abstract_chinese.tex @@ -23,7 +23,7 @@ 國立陽明交通大學資工系資訊中心基於輔助系上發展的立場，同時為了減輕教授與實驗室架設伺服器上的軟硬體負擔，希望提供一個可以快速建置動態內容網頁的代管平台。考量到平台通用性與運行成本，在此方面容器技術具有相當優勢，其中又以 Kubernetes 最為代表，具備各式高擴展性功能，並提供一標準 API 界面，使應用部屬流程更為廣泛通用。 -本篇論文將探討如何基於 Kubernetes namespace 設計多租戶架構，建構出具有資源配額的 Kubernetes-as-a-Service (KaaS) 平台，充分運用 Kubernetes 內建及自訂 admission controllers 邏輯以改善其安全性；同時為其設計易用的網頁界面，並將網頁界面的核心功能以通用型 Kubernetes 客戶端開放原始碼釋出。 +本篇論文將探討如何基於 Kubernetes Namespace 設計多租戶架構，建構出具有資源配額的 Kubernetes-as-a-Service (KaaS) 平台，充分運用 Kubernetes 內建及自訂 admission controllers 邏輯以改善其安全性；同時為其設計易用的網頁界面，並將網頁界面的核心功能以通用型 Kubernetes 客戶端開放原始碼釋出。 \vspace{1cm} diff --git a/Sections/4.Architecture.tex b/Sections/4.Architecture.tex index ab4f6ce..91b7c9f 100644 --- a/Sections/4.Architecture.tex +++ b/Sections/4.Architecture.tex @@ -5,7 +5,7 @@ \section{設計需求} -本研究目標設想的 Kubernetes-as-a-Service 可以藉由 CScloud 的想法衍生改良，保留其共用叢集、基於 Kubernetes namespace 的多租戶設計以及透過串接既有單一登入服務簡化身份驗證實做的特色，重新設計架構並著重於改善下列兩點： +本研究目標設想的 Kubernetes-as-a-Service 可以藉由 CScloud 的想法衍生改良，保留其共用叢集、基於 Kubernetes Namespace 的多租戶設計以及透過串接既有單一登入服務簡化身份驗證實做的特色，重新設計架構並著重於改善下列兩點： \begin{onehalfspacing} \begin{itemize} @@ -63,7 +63,7 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使 面對如此多元的安全性相關設定，以及其產生的無數組合，我們需要一個標準評判 Pod 的安全性。Kubernetes 提出了 Pod Security Standards，並且將可能的設定分為三個政策層級：privileged、baseline 與 restricted。Privileged 可以放寬隔離機制，baseline 包含未特別指定任何設定的場景，restricted 則是進一步要求提升安全性設定。對於執行這些政策檢查，Kubernetes 提供了 PodSecurity admission controller。 -大多數政策類型的 admission controllers，包含 PodSecurity，設計上皆能夠以 namespace 為單位設定政策，為了確保平台安全性，我們針對使用者的 namespaces 實施 restricted 政策。 +大多數政策類型的 admission controllers，包含 PodSecurity，設計上皆能夠以 Namespace 為單位設定政策，為了確保平台安全性，我們針對使用者的 namespaces 實施 restricted 政策。 \subsection{PodTolerationRestriction} @@ -71,7 +71,7 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使 與 taints 相對，Pod 可以設定 tolerations 來抑制 taints 的效果。例如在擴充 Kubernetes API 的場景，我們需要部屬實做自訂 resource 種類邏輯的 controller，這個 controller 屬於叢集控制邏輯的一部分，我們會希望規劃在 control plane 運行。在部屬此 controller 時，我們便會設定前述 taints 相對的 tolerations 解除限制，並且搭配其他排程設定強制排程至 control plane。 -為了避免一般使用者濫用這個機制，我們採用 PodTolerationRestriction 來限制使用者能填寫的 tolerations。PodTolerationRestriction 可以針對 namespace 設定其中 Pods 可使用的 tolerations 白名單，我們將其限制為只允許系統內部會預設填入的項目。 +為了避免一般使用者濫用這個機制，我們採用 PodTolerationRestriction 來限制使用者能填寫的 tolerations。PodTolerationRestriction 可以針對 Namespace 設定其中 Pods 可使用的 tolerations 白名單，我們將其限制為只允許系統內部會預設填入的項目。 \section{權限開通實做} @@ -96,7 +96,7 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使 \caption{CSKloud V3 網頁界面導覽設計} \end{figure} -網頁界面設計以單一 Kubernetes namespace 為主軸，符合 CSKloud 對使用者提供獨立 namespace 使用的場景。網頁的導覽透過頁面左方的導覽列達成，由此存取各個子功能，並且顯示目前所操作的 namespace。在 Sparkles 上，namespace 可由可搜尋的下拉式選單選擇，在 CSKloud 上，則是固定為使用者對應的 namespace 而停用選單，保留在界面上是為了往後開發出使用者群組功能後，切換至群組所對應的 namespace 使用。 +網頁界面設計以單一 Kubernetes Namespace 為主軸，符合 CSKloud 對使用者提供獨立 Namespace 使用的場景。網頁的導覽透過頁面左方的導覽列達成，由此存取各個子功能，並且顯示目前所操作的 namespace。在 Sparkles 上，Namespace 可由可搜尋的下拉式選單選擇，在 CSKloud 上，則是固定為使用者對應的 Namespace 而停用選單，保留在界面上是為了往後開發出使用者群組功能後，切換至群組所對應的 Namespace 使用。 \subsection{Pods 頁面與 Web Terminal 功能實做} \label{sec:web-terminal} @@ -181,7 +181,7 @@ Helm Release 一般的儲存格式需要經過 Base64\footnote{Base64: 一個編 \caption{CSKloud V3 網頁界面 Quotas 頁面} \end{figure} -此頁面針對平台透過 ResourceQuota 對 namespace 下實行的資源配額進行視覺化，使用圓餅圖顯示每個取用單位（如 Pod 下的一個容器）在相關資源（如記憶體）允許配額下所佔用的比例。使用者可以透過將游標移動到圓餅區塊上，查看取用單位的名稱以及佔用量，方便使用者了解何處取用最多。在總取用比例高到一定程度時，會改以黃色或紅色顯示提醒使用者注意。 +此頁面針對平台透過 ResourceQuota 對 Namespace 下實行的資源配額進行視覺化，使用圓餅圖顯示每個取用單位（如 Pod 下的一個容器）在相關資源（如記憶體）允許配額下所佔用的比例。使用者可以透過將游標移動到圓餅區塊上，查看取用單位的名稱以及佔用量，方便使用者了解何處取用最多。在總取用比例高到一定程度時，會改以黃色或紅色顯示提醒使用者注意。 在實做上，由於 ResourceQuota 只帶有配額與佔用總量資訊，須以程式邏輯另外獲取相關取用單位資訊才能自行判斷細項。另外，圓餅圖的繪製透過 Chart.js 開源函式庫實做。 @@ -190,7 +190,7 @@ Helm Release 一般的儲存格式需要經過 Base64\footnote{Base64: 一個編 CSKloud 開放使用者直接存取 API，並且提供 kubectl 連線設定檔。因為叢集本身使用 OIDC 驗證方式，客戶端需要有相關 OIDC 流程邏輯，在網頁界面我們可以直接實做，而對於 kubectl 的場景，我們則是使用 kubelogin 擴充程式，在 kubectl 發出 Kubernetes API 請求時，kubelogin 會檢查是否持有有效的 token，並且在有必要時執行 OIDC 流程。OIDC 需要透過瀏覽器進行網頁登入，導致這個驗證方式雖然在使用者的互動使用時可行且較為安全，在自動化場景卻相當不方便。 -對此，我們採用 ServiceAccount tokens 彌補對自動化場景的不足。Tokens 管理頁面幫助使用者設定一個具有當下 namespace 權限的 ServiceAccount，再經由此 ServiceAccount，簽發綁定 Secret 的 token。使用者在簽發 token 時需指定效期，並且可以紀錄相關的用途筆記，存放在對應的 Secret 內。這些 Secrets 使得網頁界面可以紀錄簽發的 tokens，同時作為撤銷 tokens 的手段。 +對此，我們採用 ServiceAccount tokens 彌補對自動化場景的不足。Tokens 管理頁面幫助使用者設定一個具有當下 Namespace 權限的 ServiceAccount，再經由此 ServiceAccount，簽發綁定 Secret 的 token。使用者在簽發 token 時需指定效期，並且可以紀錄相關的用途筆記，存放在對應的 Secret 內。這些 Secrets 使得網頁界面可以紀錄簽發的 tokens，同時作為撤銷 tokens 的手段。 \subsection{Resource Explorer} @@ -237,7 +237,7 @@ Resource Explorer 提供對 Kubernetes resource 的基本列出、創立、編 實做這個功能有兩個可行方向：使用 WebAssembly 將 kubectl 移植到瀏覽器，或者在叢集內執行 kubectl。前者實際上除了移植 kubectl 指令外，還需提供一個 shell 環境以便使用，在需將環境內各種工具一一移植的前提下，容易產生缺漏使用者想要的項目的窘境，開發成本相當高，於是我們選擇了後者。 -kubectl shell 頁面類似於 \ref{sec:tokens-mgmt} Tokens 管理頁面，都會先產生一個具有當下 namespace 權限的 ServiceAccount，但取用的方式不同。接著會採用 Kubernetes 設計上將 ServiceAccount 對 Pod 做的特殊整合，創立一個使用該 ServiceAccount 的 Pod 時，Kubernetes 會自動簽發綁定此 Pod 的 token，並且將 token 與相關連線資訊放置至 Pod 內容器的檔案系統中。容器內具備的 kubectl 指令會自動採用檔案系統內的這些資訊進行連線。再來只須重複利用 \ref{sec:web-terminal} 所述的虛擬終端機連線機制，便可以讓使用者操作容器內的 kubectl 指令。 +kubectl shell 頁面類似於 \ref{sec:tokens-mgmt} Tokens 管理頁面，都會先產生一個具有當下 Namespace 權限的 ServiceAccount，但取用的方式不同。接著會採用 Kubernetes 設計上將 ServiceAccount 對 Pod 做的特殊整合，創立一個使用該 ServiceAccount 的 Pod 時，Kubernetes 會自動簽發綁定此 Pod 的 token，並且將 token 與相關連線資訊放置至 Pod 內容器的檔案系統中。容器內具備的 kubectl 指令會自動採用檔案系統內的這些資訊進行連線。再來只須重複利用 \ref{sec:web-terminal} 所述的虛擬終端機連線機制，便可以讓使用者操作容器內的 kubectl 指令。 這個方式雖然因為在叢集內執行容器，會佔用到使用者的資源配額，但實際此場景預期的資源使用極小，對於使用者權益的影響不大。運作機制主要又是基於其他既有的功能做組合，實際開發成本極低，卻十分有效。圖 \ref{fig:kubectl-get-pods} 即是來自於此功能。 -- 2.45.2