From e1d307c3ebd79c8b7bd984d2aa400abba77c5dbc Mon Sep 17 00:00:00 2001 From: Pinghao Wu Date: Wed, 2 Oct 2024 17:51:50 +0800 Subject: [PATCH] Evaluation: qualitative analysis of sparkles TODO a small conclusion here, or leave it to total conclusion? --- Sections/4.Architecture.tex | 1 + Sections/5.Evaluation.tex | 16 +++++++++++++++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/Sections/4.Architecture.tex b/Sections/4.Architecture.tex index 6164b5f..e180745 100644 --- a/Sections/4.Architecture.tex +++ b/Sections/4.Architecture.tex @@ -243,6 +243,7 @@ Helm Release 預設的 Secret 儲存方式需要經過 Base64\footnote{Base64: 調整 Helm Values 的編輯器採用 CodeMirror 開源編輯器專案，除了 YAML 的基本語法高亮以外，我們採用 codemirror-json-schema 擴充元件提供進一步的資料驗證、欄位說明與名稱自動補全。codemirror-json-schema 收取 JSON Schema 作為欄位定義，JSON Schema\cite{pezoa2016foundations} 是一個描述 JSON\cite{rfc8259}\footnote{JSON: 資料序列化語言，語法比 YAML 容易以程式解析。} 資料的定義框架，但由於大多數 YAML 應用場景描述的資料也都可以由 JSON 的形式表達，也常用來描述 YAML 資料。部份 Helm Chart 會提供對其 Helm Values 的 JSON Schema 定義檔。 \subsection{Quotas 視覺化} +\label{sec:quota} \begin{figure}[htb] \centering diff --git a/Sections/5.Evaluation.tex b/Sections/5.Evaluation.tex index 19432b6..2386ddf 100644 --- a/Sections/5.Evaluation.tex +++ b/Sections/5.Evaluation.tex @@ -47,10 +47,12 @@ \section{質性分析} +本研究實做的 CSKloud 平台中，網頁界面除了針對平台的整合外，其核心 Sparkles 作為一個 Kubernetes 客戶端開發設計，並且適用於非 CSKloud 的場景。我們將 Sparkles 獨立討論，與其他常見的 Kubernetes 客戶端比較，結果如表 \ref{tab:sparkles-comparison}。 + \begin{table}[htb] \centering \caption{Sparkles 與常見 Kubernetes 客戶端比較} - \label{tab:quota} + \label{tab:sparkles-comparison} \begin{tabular}{l || c | c | c | c} & Sparkles & kubectl & k9s & \hspace{1em}Lens\hspace{1em} \\ \hline\hline @@ -65,3 +67,15 @@ 開放原始碼 & 是 (MIT) & 是 (Apache-2.0) & 是 (Apache-2.0) & 否 \\ \end{tabular} \end{table} + +表 \ref{tab:sparkles-comparison} 中的配額細項追蹤如 \ref{sec:quota} 所述，Kubernetes API 設計上只帶有總用量資訊，對於其中如每個容器的分別用量細項並沒有額外紀錄。為了讓使用者了解細項用量分佈，Sparkles 重現了 Kubernetes 內部計算用量的部份邏輯，以補足這些資訊。調查中的其他客戶端皆沒有類似功能，只有顯示 Kubernetes API 紀錄的總用量。 + +ServiceAccount tokens 功能管理則是指 \ref{sec:tokens-mgmt} 中，綁定 Secret 作為 tokens 撤銷手段以及效期、註記功能。kubectl 的界面較接近 Kubernetes API 設計，流程步驟需要分開處理，先以一個指令創立 Secret，再由另一個指令自 ServiceAccount 簽發綁定該 Secret 的 tokens，而 ServiceAccount 本身的創立以及授權也是另外處理。Lens 尚未整合上述 Kubernetes 1.22 後的簽發流程，但與此相似的是先前的單一無效期 token 機制。在 Kubernetes 1.22 前，創立 ServiceAccount 會自動產生一個對應的 Secret，內含一個無效期的永久 token。Lens 在 ServiceAccount 本身的呈現頁面可以自動產生含該 token 的連線設定檔。舊的無效期機制在現今的 Kubernetes 版本雖然留有手段能夠手動觸發，但因資訊安全因素已不建議使用。 + +Helm 功能在 Sparkles 上如 \ref{sec:helm} 所述，因技術限制僅能使用自行建立的單一 Helm Repository。k9s 沒有實做需要執行 Helm 模板的功能，只有達成顯示歷史、回滾、解除安裝等操作。Lens 則是有完整的功能。 + +Port forwarding 是指將容器或者 Service 的網路存取點，透過 Kubernetes API 內的代理功能轉發，在本地端提供存取，常用在除錯場景。Sparkles 由於網頁技術無法進行底層網路操作，無法達成，CSKloud 使用者需改用其他客戶端。未來若衍生出對此功能的強烈需求，可以考慮透過瀏覽器擴充程式，跳脫網頁技術框架另外實做。 + +多叢集管理意指在同個實例下，能夠切換連線設定組操作多個叢集。Sparkles 並未實做此功能，但能夠對不同叢集部屬專屬的實例，在不同網址下同時運作。CSKloud 的單一叢集設計場景則是沒有此需求。 + +在開放原始碼方面，Lens 原本採取 MIT 授權條款釋出，但約 2023 年九月時轉為專有軟體，不再提供原始碼存取。 -- 2.45.2