3 files changed, 44 insertions(+), 0 deletions(-)

M Sections/4.Architecture.tex
M Sections/5.Evaluation.tex
M covers/load_env.tex

@@ 301,6 301,7 @@ Resources 的列舉採用 Kubernetes 內建的製表功能，可以產出基本
 這個頁面功能可以涵蓋 Kubernetes 上的大多數操作，但仍然有限制，主要為不支援 subresources。Subresources 為單一 resource 實例下的額外 API endpoints，使 Kubernetes 得以跳脫 resource 讀寫操作的框架，並且不具有固定的形式，其中較為代表的有：Pod 的 log subresource，用以查看 Pod 下容器的運行紀錄；Pod 的 exec subresources，用以在 Pod 下容器執行指令；ServiceAccount 的 tokens subresource，用以簽發 tokens。由於 subresources 的形式、用途皆不固定，我們無法直接提供通用的操作界面，而是經由如 \ref{sec:web-terminal} Pod 頁面等，針對不同場景另外實做。
 
 \subsection{kubectl shell}
+\label{sec:kubectl-shell}
 
 隨著 Kubernetes 的更迭，即使我們盡力擴增網頁界面對應的功能，難免還是會有跟不上的時候。就算是現在，雖然我們已經實做了通用型的 Resource Explorer，仍然有少數 Kubernetes 功能無法直接透過網頁界面使用。對此，我們提供一個逃生口 (escape hatch)：在網頁界面直接使用 kubectl 指令。雖然使用者可以自行安裝設定 kubectl，在網頁界面直接提供這個功能還是有免安裝、隨時帶著走的優勢。
 

@@ 1,2 1,44 @@
 \chapter{實驗與評估}
 \label{ch:evaluation}
+
+本章節敘述本研究設計之 CSKloud 平台在系計中內部的小規模實驗場景，以及對平台成效的評估。
+
+\section{實驗環境}
+
+\begin{table}[htb]
+    \centering
+    \caption{CSKloud v3 內部實驗環境}
+    \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
+        Memory & 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 & Memory & Storage & Ephemeral storage \\
+        \hline\hline
+        學生 & 0.5 / 1 & 1 GiB / 2 GiB & 8 GiB & 1 GiB / 10 GiB \\ \hline
+        教授、助理 & 1 / 2 & 2 GiB / 4 GiB & 16 GiB & 1 GiB / 10 GiB \\ \hline
+        單一容器預設佔有量 & 0.1 / 0.15 & 128 MiB / 192 MiB & N/A & 50 MiB / 256 MiB \\ \hline
+        kubectl shell 佔有量 & 0.05 / 0.1 & 64 MiB / 128 MiB & N/A & 8 MiB / 64 MiB \\
+    \end{tabular}
+\end{table}
+
+表 \ref{tab:quota} 內部份項目以 / 分隔的兩個數值分別代表 request 量與 limit 量。Kubernetes 在運算資源的分配分為 request 與 limit 兩種，代表排程主要的參考值以及實際運行的限制值，允許工作負載在資源的取用上有爆發的可能。我們的主要服務場景為網頁服務架設，網頁服務的運算資源消耗與當下的流量大小高度相關，屬於具備爆發性的工作負載，因此我們也採納 request 與 limit 機制使得資源運用更有彈性。而表中的 ephemeral storage 意指容器在一般 storage 外的資料寫入，包含運行紀錄以及容器內的其餘檔案系統空間的使用，這個類型一般不太容易預估，因此我們給予較寬鬆的限制，另外因為其使用量典型為持續累積（如容器無法主動刪除其運行紀錄），超過 limit 時 Kubernetes 會將容器重啟，為減少對使用者的影響，通常 limit 相對之下特別高。
+
+單一容器預設佔有量以及 \ref{sec:kubectl-shell} kubectl shell 的佔有量也將影響使用者體驗，其中尤其是 kubectl shell 的佔有量，為了避免影響使用者權益，我們希望將他壓低，但又不應降到令使用者感到卡頓。另外在使用者不自行估計限制的情況下，單一容器預設佔有量除了影響能同時運行的容器數量，也影響到能夠運行的工作負載種類，在此方面最敏感的是 memory，部份使用較多 memory 的程式可能會因為不足而異常中止，無法順利運行。對於這兩組佔有量的評估也是實驗要點之一。
+
+對於配額的規劃在實驗階段與正式上線也將有所誤差，尤其對於 CPU 在測試環境用的是系計中的二線老舊硬體，改為正式用的一線新硬體時，配合效能的改變，應能再減少其配額量至一半左右。

@@ 5,6 5,7 @@
 
 \usepackage{subcaption}
 \usepackage{caption}
+\usepackage{makecell}
 
 \usepackage[no-math]{fontspec}   %加這個就可以設定字體 
 \usepackage{xeCJK}       %讓中英文字體分開設置