~xdavidwu/cskloudv3-thesis

e1d307c3ebd79c8b7bd984d2aa400abba77c5dbc — Pinghao Wu 2 months ago 51d13dd
Evaluation: qualitative analysis of sparkles

TODO a small conclusion here, or leave it to total conclusion?
2 files changed, 16 insertions(+), 1 deletions(-)

M Sections/4.Architecture.tex
M Sections/5.Evaluation.tex
M Sections/4.Architecture.tex => Sections/4.Architecture.tex +1 -0
@@ 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

M Sections/5.Evaluation.tex => Sections/5.Evaluation.tex +15 -1
@@ 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 年九月時轉為專有軟體,不再提供原始碼存取。