<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">\chapter{實驗與評估}
\label{ch:evaluation}

本章節敘述本研究設計之 CSKloud 平台在系計中內部的小規模實驗場景，以及對平台成效的評估。

\section{實驗環境}

\begin{table}[htb]
    \centering
    \caption{CSKloud v3 內部實驗環境}
    \setlength{\tabcolsep}{5pt}
    \begin{tabular}{l || c | c}
        &amp; Control plane &amp; Worker nodes \\
        \hline\hline
        節點數量 &amp; 3 &amp; 3 \\ \hline
        CPU &amp; \makecell{Intel(R) Xeon(R) CPU E5-2630 v3 \\ @ 2.40GHz, 4 vCPUs} &amp; \makecell{Intel(R) Xeon(R) CPU E5-2630 v3 \\ @ 2.40GHz, 4 vCPUs} \\ \hline
        記憶體 &amp; 8 GiB &amp; 8 GiB \\ \hline
        虛擬化平台 &amp; \multicolumn{2}{c}{VMware ESXi 6.7} \\ \hline
        作業系統版本 &amp; \multicolumn{2}{c}{Debian GNU/Linux 12 (bookworm)} \\ \hline
        Kubernetes 版本 &amp; \multicolumn{2}{c}{1.30.3} \\ \hline
        叢集建構方式 &amp; \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}
         &amp; CPU &amp; 記憶體 &amp; 永久儲存空間 &amp; Ephemeral storage \\
        \hline\hline
        學生 &amp; 0.5 / 1 &amp; 1 / 2 GiB &amp; 8 GiB &amp; 1 / 10 GiB \\ \hline
        教授、助理 &amp; 1 / 2 &amp; 2 / 4 GiB &amp; 16 GiB &amp; 1 / 10 GiB \\ \hline
        單一容器預設佔有量 &amp; 0.1 / 0.15 &amp; 128 / 192 MiB &amp; N/A &amp; 50 / 256 MiB \\ \hline
        kubectl shell 佔有量 &amp; 0.05 / 0.1 &amp; 64 / 128 MiB &amp; N/A &amp; 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/,/ \&amp; /g;s/&amp;  &amp;/\&amp; \\scriptsize NA \&amp;/g;s/$/ \\\\/;s/^/\&amp; /;=' | 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}
        &amp; Q1 &amp; Q2 &amp; Q3 &amp; Q4 &amp; Q5 &amp; Q6 &amp; Q7 &amp; Q8 &amp; Q9 &amp; 10 &amp; 11 &amp; 12 &amp; 13 &amp; 14 &amp; 15 &amp; 16 &amp; 17 &amp; 18 &amp; 19 &amp; 20 &amp; 21 &amp; 22 &amp; 23 &amp; 24 \\
        \hline\hline
1 &amp; 3 &amp; 4 &amp; 2 &amp; 3 &amp; 2 &amp; 3 &amp; 3 &amp; 2 &amp; 2 &amp; 2 &amp; 2 &amp; 2 &amp; 2 &amp; 2 &amp; 3 &amp; 2 &amp; 2 &amp; 1 &amp; 2 &amp; 3 &amp; 4 &amp; 4 &amp; 2 &amp; 3 \\
2 &amp; 2 &amp; 3 &amp; 2 &amp; 2 &amp; 2 &amp; 2 &amp; 3 &amp; 3 &amp; 3 &amp; 4 &amp; 3 &amp; 3 &amp; 2 &amp; 4 &amp; 5 &amp; 3 &amp; 3 &amp; 5 &amp; 3 &amp; 2 &amp; 5 &amp; 6 &amp; 3 &amp; 4 \\
3 &amp; 1 &amp; 1 &amp; \scriptsize NA &amp; 1 &amp; 1 &amp; \scriptsize NA &amp; 1 &amp; 1 &amp; 1 &amp; 1 &amp; 2 &amp; 1 &amp; 1 &amp; 1 &amp; 1 &amp; 1 &amp; 1 &amp; 1 &amp; 2 &amp; 2 &amp; 2 &amp; 2 &amp; 1 &amp; 4 \\
4 &amp; 2 &amp; 2 &amp; 1 &amp; 2 &amp; 2 &amp; 3 &amp; 2 &amp; 2 &amp; 2 &amp; 2 &amp; 1 &amp; 2 &amp; 2 &amp; 1 &amp; 2 &amp; 2 &amp; 2 &amp; 1 &amp; 2 &amp; 2 &amp; 3 &amp; 3 &amp; 2 &amp; 3 \\
5 &amp; 2 &amp; 1 &amp; 2 &amp; 2 &amp; 3 &amp; 2 &amp; 2 &amp; 4 &amp; 1 &amp; 2 &amp; 1 &amp; 1 &amp; 1 &amp; 1 &amp; 1 &amp; 1 &amp; 2 &amp; 1 &amp; 3 &amp; 1 &amp; 2 &amp; 4 &amp; 3 &amp; 7 \\
        \hline
        \scriptsize 平均 &amp; \scriptsize 2.00 &amp; \scriptsize 2.20 &amp; \scriptsize 1.75 &amp; \scriptsize 2.00 &amp; \scriptsize 2.00 &amp; \scriptsize 2.50 &amp; \scriptsize 2.20 &amp; \scriptsize 2.40 &amp; \scriptsize 1.80 &amp; \scriptsize 2.20 &amp; \scriptsize 1.80 &amp; \scriptsize 1.80 &amp; \scriptsize 1.60 &amp; \scriptsize 1.80 &amp; \scriptsize 2.40 &amp; \scriptsize 1.80 &amp; \scriptsize 2.00 &amp; \scriptsize 1.80 &amp; \scriptsize 2.40 &amp; \scriptsize 2.00 &amp; \scriptsize 3.20 &amp; \scriptsize 3.80 &amp; \scriptsize 2.20 &amp; \scriptsize 4.20 \\ \hline
        \scriptsize 類別 &amp; \multicolumn{6}{c|}{\footnotesize SysUse 2.08} &amp; \multicolumn{6}{c|}{\footnotesize InfoQual 2.03} &amp; \multicolumn{3}{c|}{\footnotesize IntQual 1.93} &amp; &amp; &amp; &amp; &amp; &amp; &amp; &amp; &amp; \\ \hline
        \scriptsize 總體 &amp; \multicolumn{16}{c|}{PSSUQ Overall 2.02} &amp; &amp; &amp; &amp; &amp; &amp; &amp; &amp;
    \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}
        &amp; Sparkles &amp; kubectl &amp; k9s &amp; \hspace{1em}Lens\hspace{1em} \\
        \hline\hline
        界面形式 &amp; 網頁 &amp; CLI &amp; TUI &amp; GUI \\ \hline
        使用者安裝設定 &amp; 不需 &amp; 需要 &amp; 需要 &amp; 需要 \\ \hline
        配額細項追蹤 &amp; 有 &amp; 無 &amp; 無 &amp; 無 \\ \hline
        \makecell[l]{ServiceAccount \\ tokens 管理} &amp; 有 &amp; 流程較手動 &amp; 無 &amp; 無 \\ \hline
        \makecell[l]{YAML 編輯器 \\ 欄位提示補全} &amp; 有 &amp; 無 &amp; 無 &amp; 無 \\ \hline
        內建 Helm 功能 &amp; \makecell{限內建 \\ Repository} &amp; 無 &amp; 無安裝、更新 &amp; 有 \\ \hline
        Port forwarding &amp; 無 &amp; 有 &amp; 有 &amp; 有 \\ \hline
        多叢集管理 &amp; 無 &amp; 有 &amp; 有 &amp; 有 \\ \hline
        開放原始碼 &amp; 是 (MIT) &amp; 是 (Apache-2.0) &amp; 是 (Apache-2.0) &amp; 否 \\
    \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 }
        &amp; CScloud &amp; CScloud with PEKOS &amp; CSKloud v3 \\
        \hline\hline
        多租戶模型 &amp; \multicolumn{3}{c}{單叢集、Namespace-based} \\ \hline
        租戶開通 &amp; \makecell{Operator pattern、 \\ 手動觸發} &amp; 網頁程式邏輯 &amp; \makecell{Operator pattern、 \\ 自動觸發} \\ \hline
        租戶資訊來源 &amp; LDAP &amp; OIDC &amp; OIDC \\ \hline
        租戶身份驗證 &amp; \makecell{規劃為 \\ ServiceAccount} &amp; OIDC &amp; \makecell{OIDC、 \\ ServiceAccount} \\ \hline
        \makecell[l]{租戶直接存取 \\ K8s API} &amp; 規劃 &amp; 無 &amp; 有 \\ \hline
        \makecell[l]{Admission \\ control 加固} &amp; 無 &amp; \makecell{Open Policy Agent \\ (webhooks)} &amp; \makecell{標準 K8s 內建、 \\ CEL} \\ \hline
        平台安全性 &amp; 低 &amp; 中 &amp; 高 \\ \hline
        網頁界面架構 &amp; 未定 &amp; 單體式、伺服器渲染 &amp; SPA \\ \hline
        界面功能性 &amp; 未定 &amp; 低 &amp; 高 \\ \hline
        產品定位 &amp; PaaS、網頁代管 &amp; PaaS、網頁代管 &amp; KaaS、網頁代管為主 \\ \hline
        原始碼模型 &amp; 閉源 &amp; 閉源 &amp; 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 策略則有助於進一步開發客群，獲得更廣泛的使用者回饋，並且也可以借助開源社群來降低部份維護成本。
</pre></body></html>