\chapter{實驗與評估}
\label{ch:evaluation}
本章節敘述本研究設計之 CSKloud 平台在系計中內部的小規模實驗場景，以及對平台成效的評估。
\section{實驗環境}
\begin{table}[htb]
\centering
\caption{CSKloud v3 內部實驗環境}
\setlength{\tabcolsep}{5pt}
\begin{tabular}{l || c | c}
& Control plane & Worker nodes \\
\hline\hline
節點數量 & 3 & 3 \\ \hline
CPU & \makecell{Intel(R) Xeon(R) CPU E5-2630 v3 \\ @ 2.40GHz, 4 vCPUs} & \makecell{Intel(R) Xeon(R) CPU E5-2630 v3 \\ @ 2.40GHz, 4 vCPUs} \\ \hline
記憶體 & 8 GiB & 8 GiB \\ \hline
虛擬化平台 & \multicolumn{2}{c}{VMware ESXi 6.7} \\ \hline
作業系統版本 & \multicolumn{2}{c}{Debian GNU/Linux 12 (bookworm)} \\ \hline
Kubernetes 版本 & \multicolumn{2}{c}{1.30.3} \\ \hline
叢集建構方式 & \multicolumn{2}{c}{kubeadm, stacked etcd topology} \\
\end{tabular}
\end{table}
實驗採用系計中標準的測試環境，並且依照一般使用慣例配置虛擬機，由於硬體資源短少，並非比照正式環境規模建構。未來實際上線時需將 worker nodes 大幅擴建才得以滿足系上的需求，根據上線後的實際熱門程度也需持續調整，甚至可以考慮將 worker nodes 轉為實體機的方式建構。
\begin{table}[htb]
\centering
\caption{CSKloud v3 實驗身份組與配額初步規劃}
\label{tab:quota}
\begin{tabular}{l || c | c | c | c}
& CPU & 記憶體 & 永久儲存空間 & Ephemeral storage \\
\hline\hline
學生 & 0.5 / 1 & 1 / 2 GiB & 8 GiB & 1 / 10 GiB \\ \hline
教授、助理 & 1 / 2 & 2 / 4 GiB & 16 GiB & 1 / 10 GiB \\ \hline
單一容器預設佔有量 & 0.1 / 0.15 & 128 / 192 MiB & N/A & 50 / 256 MiB \\ \hline
kubectl shell 佔有量 & 0.05 / 0.1 & 64 / 128 MiB & N/A & 8 / 512 MiB \\
\end{tabular}
\end{table}
表 \ref{tab:quota} 內部份項目以 / 分隔的兩個數值分別代表 request 量與 limit 量。Kubernetes 在運算資源的分配分為 request 與 limit 兩種，代表排程主要的參考值以及實際運行的限制值，允許工作負載在資源的取用上有爆發的可能。我們的主要服務場景為網頁服務架設，網頁服務的運算資源消耗與當下的流量大小高度相關，屬於具備爆發性的工作負載，因此我們也採納 request 與 limit 機制使得資源運用更有彈性。而表中的 ephemeral storage 意指容器在永久儲存空間外的資料寫入，包含運行紀錄以及容器內的其餘檔案系統空間的使用，這個類型一般不太容易預估，因此我們給予較寬鬆的限制，另外因為其使用量典型為持續累積（如容器無法主動刪除其運行紀錄），超過 limit 時 Kubernetes 會將容器重啟，為減少對使用者的影響，通常 limit 相對之下特別高。
單一容器預設佔有量以及 \ref{sec:kubectl-shell} kubectl shell 的佔有量也將影響使用者體驗，其中尤其是 kubectl shell 的佔有量，為了避免影響使用者權益，我們希望將他壓低，但又不應降到令使用者感到卡頓。另外在使用者不自行估計限制的情況下，單一容器預設佔有量除了影響能同時運行的容器數量，也影響到能夠運行的工作負載種類，在此方面最敏感的是記憶體，部份使用較多記憶體的程式可能會因為不足而異常中止，導致無法順利運行。對於這兩組佔有量的評估也是實驗要點之一。
對於配額的規劃在實驗階段與正式上線也將有所誤差，尤其對於 CPU 在測試環境用的是系計中的二線老舊硬體，改為正式用的一線新硬體時，配合效能的改變，應能再減少其配額量至一半左右。
\section{使用者問卷調查}
對於一個通用的雲端運算平台，由於各個使用者的使用情境及習慣不盡相同，為了準確的評估平台的效用，需要實行問卷調查以了解實際使用狀況。我們將問卷分為兩大部分，第一部份以 Post Study System Usability Questionnaire (PSSUQ)\cite{lewis2002psychometric} 分析整體平台的使用體驗，而第二部份再對平台的特定功能設計予以評估，並且加上對 Kubernetes 熟悉程度的自評，以了解受試者特性。問卷項目見\ref{ch:survey-items}。
PSSUQ 是常見針對軟體系統的標準問卷調查，根據歷史發展分為三個版本\cite{lewis2019measuring}。本研究採取的是第三版，共十六個項目（問卷中的第一至十六項），其中除了整體滿意度外，可分為三大類：System Usefulness（SysUse，第一至六項）、Information Quality（InfoQual，第七至十二項） 與 Interface Quality（IntQual，第十三至十五項）。每個項目包含一個敘述，受試者評估敘述對自身體驗的符合程度，回答一到七分的指標，兩端分別代表 ``Strongly Agree" 與 ``Strongly Disagree"，並且附帶一 ``Not Applicable" (NA) 選項使受試者能夠選擇不參與特定項目的評比，減緩受試者的壓力。
第二部份（第十七至二十四項）沿用 PSSUQ 針對敘述賦予非強制性的一到七分指標形式，針對平台產品擴充，評估各項資源配額的設計，包含單一容器預設值以及 kubectl 頁面設定值，另外附加如局部功能與相似產品的比較敘述等的有效性評估。問卷採用 Google 表單，要求登入 Google 帳號以防止重複填寫，但不收集帳號資訊，以匿名方式進行。
\begin{table}[htb]
\centering
\small
\setlength{\tabcolsep}{1.97pt}
\caption{問卷調查結果}
\label{tab:survey-result}
% cat *.csv | grep 2024 | cut -d ',' -f 2-25 | tr -d '"' | sed 's/,/ \& /g;s/& &/\& \\scriptsize NA \&/g;s/$/ \\\\/;s/^/\& /;=' | wl-copy
\begin{tabular}{l || c c c c c c | c c c c c c | c c c | c | c c c c c c c c c}
& Q1 & Q2 & Q3 & Q4 & Q5 & Q6 & Q7 & Q8 & Q9 & 10 & 11 & 12 & 13 & 14 & 15 & 16 & 17 & 18 & 19 & 20 & 21 & 22 & 23 & 24 \\
\hline\hline
1 & 3 & 4 & 2 & 3 & 2 & 3 & 3 & 2 & 2 & 2 & 2 & 2 & 2 & 2 & 3 & 2 & 2 & 1 & 2 & 3 & 4 & 4 & 2 & 3 \\
2 & 2 & 3 & 2 & 2 & 2 & 2 & 3 & 3 & 3 & 4 & 3 & 3 & 2 & 4 & 5 & 3 & 3 & 5 & 3 & 2 & 5 & 6 & 3 & 4 \\
3 & 1 & 1 & \scriptsize NA & 1 & 1 & \scriptsize NA & 1 & 1 & 1 & 1 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 2 & 2 & 2 & 2 & 1 & 4 \\
4 & 2 & 2 & 1 & 2 & 2 & 3 & 2 & 2 & 2 & 2 & 1 & 2 & 2 & 1 & 2 & 2 & 2 & 1 & 2 & 2 & 3 & 3 & 2 & 3 \\
5 & 2 & 1 & 2 & 2 & 3 & 2 & 2 & 4 & 1 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 2 & 1 & 3 & 1 & 2 & 4 & 3 & 7 \\
\hline
\scriptsize 平均 & \scriptsize 2.00 & \scriptsize 2.20 & \scriptsize 1.75 & \scriptsize 2.00 & \scriptsize 2.00 & \scriptsize 2.50 & \scriptsize 2.20 & \scriptsize 2.40 & \scriptsize 1.80 & \scriptsize 2.20 & \scriptsize 1.80 & \scriptsize 1.80 & \scriptsize 1.60 & \scriptsize 1.80 & \scriptsize 2.40 & \scriptsize 1.80 & \scriptsize 2.00 & \scriptsize 1.80 & \scriptsize 2.40 & \scriptsize 2.00 & \scriptsize 3.20 & \scriptsize 3.80 & \scriptsize 2.20 & \scriptsize 4.20 \\ \hline
\scriptsize 類別 & \multicolumn{6}{c|}{\footnotesize SysUse 2.08} & \multicolumn{6}{c|}{\footnotesize InfoQual 2.03} & \multicolumn{3}{c|}{\footnotesize IntQual 1.93} & & & & & & & & & \\ \hline
\scriptsize 總體 & \multicolumn{16}{c|}{PSSUQ Overall 2.02} & & & & & & & &
\end{tabular}
\end{table}
表 \ref{tab:survey-result} 為本次問卷調查結果。七分指標中四分為中性，越低代表越同意項目敘述。除了第二十四項為受試者對自身於 Kubernetes 的熟悉程度自評外，其餘皆是對平台正面的敘述，由統計可得知，各項評比皆偏向正面，受試者對於平台大致是滿意的。若轉為百分制\footnote{轉換方式：由七分指標減一後，等比例放大至百分指標，再以一百減之改以高分為正向。}，PSSUQ 方面整體達到了約 83 分。 % TODO finalize 後補 PSSUQ 三類分析
在第二部份的分析，項目十七顯示受試者對於平台對容器的預設資源限制持正面態度。項目十八對於 kubectl 頁面的互動效能，雖然大部分受試者相當同意足夠使用，然而有一個受試者給予了負面的回饋。對此我們推測可能是使用時受到系統層面穩定性因素影響，例如叢集節點所使用的虛擬機，其所在的實體機器上其他虛擬機的行為影響，或者近期系計中測試環境有觀測到資料儲存系統效能的不穩定狀況，皆有可能突發影響到效能。由於環境硬體上的差異，我們規劃在往後硬體資源充足時，改用正式規格硬體再來深究此情況。
雖然對平台整體的評比皆為正向，項目二十一與二十二分別顯示出了網頁界面以及其 kubectl 功能，在有其他方案的情況下仍有改善的空間。對於網頁界面，未來我們可持續新增網頁平台擅長的視覺化與互動功能，例如在 Kubernetes 下多數 resources 間有所關聯，或許可以開發透過點擊等互動方式，讓使用者在 resources 的相互關係間探索。而對於 kubectl 頁面，推測主要是 shell 環境因素，導致使用者較傾向自行安裝 kubectl 以在自己熟悉、經過客製化的 shell 環境使用。雖然立場上 kubectl 頁面僅是輔助功能，但若要使其更受歡迎，可以從擴充其容器內的常用指令、shell 的功能性下手。
% 或許可以寫對 Kubernetes 熟悉度自評分群分析 但樣本太少
\section{質性分析}
\subsection{Sparkles}
本研究實做的 CSKloud 平台中，網頁界面除了針對平台的整合外，其核心 Sparkles 作為一個 Kubernetes 客戶端開發設計，並且適用於非 CSKloud 的場景。我們將 Sparkles 獨立討論，與其他常見的 Kubernetes 客戶端比較，結果如表 \ref{tab:sparkles-comparison}。
\begin{table}[htb]
\centering
\caption{Sparkles 與常見 Kubernetes 客戶端比較}
\label{tab:sparkles-comparison}
\begin{tabular}{l || c | c | c | c}
& Sparkles & kubectl & k9s & \hspace{1em}Lens\hspace{1em} \\
\hline\hline
界面形式 & 網頁 & CLI & TUI & GUI \\ \hline
使用者安裝設定 & 不需 & 需要 & 需要 & 需要 \\ \hline
配額細項追蹤 & 有 & 無 & 無 & 無 \\ \hline
\makecell[l]{ServiceAccount \\ tokens 管理} & 有 & 流程較手動 & 無 & 無 \\ \hline
\makecell[l]{YAML 編輯器 \\ 欄位提示補全} & 有 & 無 & 無 & 無 \\ \hline
內建 Helm 功能 & \makecell{限內建 \\ Repository} & 無 & 無安裝、更新 & 有 \\ \hline
Port forwarding & 無 & 有 & 有 & 有 \\ \hline
多叢集管理 & 無 & 有 & 有 & 有 \\ \hline
開放原始碼 & 是 (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 年九月時轉為專有軟體，不再提供原始碼存取。
\subsection{CSKloud v3}
\begin{table}[htb]
\centering
\caption{平台歷代架構比較}
\label{tab:comparison}
\begin{tabular}{l || c | c | c }
& CScloud & CScloud with PEKOS & CSKloud v3 \\
\hline\hline
多租戶模型 & \multicolumn{3}{c}{單叢集、Namespace-based} \\ \hline
租戶開通 & \makecell{Operator pattern、 \\ 手動觸發} & 網頁程式邏輯 & \makecell{Operator pattern、 \\ 自動觸發} \\ \hline
租戶資訊來源 & LDAP & OIDC & OIDC \\ \hline
租戶身份驗證 & \makecell{規劃為 \\ ServiceAccount} & OIDC & \makecell{OIDC、 \\ ServiceAccount} \\ \hline
\makecell[l]{租戶直接存取 \\ K8s API} & 規劃 & 無 & 有 \\ \hline
\makecell[l]{Admission \\ control 加固} & 無 & \makecell{Open Policy Agent \\ (webhooks)} & \makecell{標準 K8s 內建、 \\ CEL} \\ \hline
平台安全性 & 低 & 中 & 高 \\ \hline
網頁界面架構 & 未定 & 單體式、伺服器渲染 & SPA \\ \hline
界面功能性 & 未定 & 低 & 高 \\ \hline
產品定位 & PaaS、網頁代管 & PaaS、網頁代管 & KaaS、網頁代管為主 \\ \hline
原始碼模型 & 閉源 & 閉源 & Open-core \\
\end{tabular}
\end{table}
CSKloud 發展至今，包含其前身 CScloud 的歷史，已經是第三代。CSKloud 除了以現代技術重構系統，以及大規模地補足平台功能外，在架構面也有不少改良變更，除了融合 CScloud 一二代的優缺點以外，也有些自己的突破，整體統合比較如表 \ref{tab:comparison}。
對於租戶開通，CSKloud 採取一代的 operator pattern 概念，比起純粹由網頁界面登入時執行流程，多了些管理上的介入空間，使管理者可以透過修改 resources 達到例外處理。Operator pattern 也有助於未來將其通用化實做使用者以外的租戶形式。比起一代，CSKloud 進一步將資料來源與驗證手段統合，實做全自動開通流程，使其仍然具有二代簡便、自動的優勢。對於身份驗證，CSKloud 則是將二代 OIDC 的安全與易用性，輔以一代 ServiceAccount 在自動化情景的簡便，提供使用者兩個不同面向的選擇。
在平台加固的部份，CSKloud 透過 Kubernetes 內建的 admission controller 以降低開發成本，以及避免自行實做邏輯後續跟隨 Kubernetes 演變而需修改的維護成本。二代採用的基於 Open Policy Agent 的 webhooks admission control 邏輯開發雖然富有彈性，然而開發與維護成本太高，在 CSKloud 中被棄用。在少數無法避免需自訂邏輯的部份，CSKloud 引入了 CEL，雖然彈性不如 webhooks 但已經足夠，並且有架構單純的優勢。
最後，CSKloud 對於網頁界面的 open-core 策略則有助於進一步開發客群，獲得更廣泛的使用者回饋，並且也可以借助開源社群來降低部份維護成本。