M Sections/4.Architecture.tex => Sections/4.Architecture.tex +1 -1
@@ 127,7 127,7 @@ Namespace 上 \verb|u-| 以及平台提供域名中 \verb|u.| 的命名切分設
ResourceQuota 是 Kubernetes 的一個 resource 種類，用來實做單一 Namespace 下的資源配額，其運作邏輯大致分兩大塊：admission controller 與一般的 controller。ResourceQuota 的 admission controller 屬於 validating，負責在創立或更新 resource 時推算其資源用量的變化值，並且拒絕用量將超出配額的請求。一般的 controller 端則是以更為全面的觀點，監控整體 resources 的變更，並且統計資源用量總額。
-ResourceQuota 所能管控的資源大致有兩種：運算資源以及 resources 的數量。運算資源具有量值，例如部屬容器時設定的 CPU 或者記憶體用量限制，以及 PersistentVolumeClaim (PVC)\footnote{PVC: Resource 種類，表示儲存空間請求，需自動或手動與 PersistentVolume（PV，分配實體）耦合。} 中的儲存用量請求。Resources 的數量則是滿足特定條件的 resources 的個數，例如正在運行的 Pods。
+ResourceQuota 所能管控的資源大致有兩種：運算資源以及 resources 的數量。運算資源具有量值，例如部屬容器時設定的 CPU 或者記憶體用量限制，以及 PersistentVolumeClaim (PVC)\footnote{PVC: Resource 種類，空間請求，需自動或手動與 PersistentVolume（PV，空間分配實體）耦合使用。} 中的永久儲存空間請求。Resources 的數量則是滿足特定條件的 resources 的個數，例如正在運行的 Pods。
除了使用 ResourceQuota 來限制運算資源用量，我們運用個數特定條件邏輯來限制 resource 內容，其中最為代表性的是 Service。Service 作為具備負載均衡的網路存取點，根據其 \verb|spec| 的 \verb|type| 欄位，主要又分為 \verb|ClusterIP|、\verb|NodePort|、\verb|LoadBalancer| 三大型別。\verb|ClusterIP| 為最基本、最常見的叢集內部存取點，\verb|NodePort| 額外在每個節點宿主端的網路環境提供存取點，\verb|LoadBalancer| 則是進一步串接叢集外部的負載均衡器。在我們的叢集規劃下，節點架設於內部網路，使用者無法直接存取節點，\verb|NodePort| 對使用者來說並無用途，同時 \verb|NodePort| 使用節點的有限網路資源，不適合對使用者開放。\verb|LoadBalancer| 則是需佔用外部負載均衡器的 IP 位址分配池，其大小非常有限，也不適合開放給使用者。ResourceQuota 正有根據型別分開統計 Service 數量的邏輯，我們利用此特性，設置對應配額為零，防止使用者使用 \verb|NodePort| 與 \verb|LoadBalancer|。
M Sections/5.Evaluation.tex => Sections/5.Evaluation.tex +8 -8
@@ 13,7 13,7 @@
\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
+ 記憶體 & 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
@@ 28,17 28,17 @@
\caption{CSKloud v3 實驗身份組與配額初步規劃}
\label{tab:quota}
\begin{tabular}{l || c | c | c | c}
- & CPU & Memory & Storage & Ephemeral storage \\
+ & CPU & 記憶體 & 永久儲存空間 & 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 \\
+ 學生 & 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 / 64 MiB \\
\end{tabular}
\end{table}
-表 \ref{tab:quota} 內部份項目以 / 分隔的兩個數值分別代表 request 量與 limit 量。Kubernetes 在運算資源的分配分為 request 與 limit 兩種，代表排程主要的參考值以及實際運行的限制值，允許工作負載在資源的取用上有爆發的可能。我們的主要服務場景為網頁服務架設，網頁服務的運算資源消耗與當下的流量大小高度相關，屬於具備爆發性的工作負載，因此我們也採納 request 與 limit 機制使得資源運用更有彈性。而表中的 ephemeral storage 意指容器在一般 storage 外的資料寫入，包含運行紀錄以及容器內的其餘檔案系統空間的使用，這個類型一般不太容易預估，因此我們給予較寬鬆的限制，另外因為其使用量典型為持續累積（如容器無法主動刪除其運行紀錄），超過 limit 時 Kubernetes 會將容器重啟，為減少對使用者的影響，通常 limit 相對之下特別高。
+表 \ref{tab:quota} 內部份項目以 / 分隔的兩個數值分別代表 request 量與 limit 量。Kubernetes 在運算資源的分配分為 request 與 limit 兩種，代表排程主要的參考值以及實際運行的限制值，允許工作負載在資源的取用上有爆發的可能。我們的主要服務場景為網頁服務架設，網頁服務的運算資源消耗與當下的流量大小高度相關，屬於具備爆發性的工作負載，因此我們也採納 request 與 limit 機制使得資源運用更有彈性。而表中的 ephemeral storage 意指容器在永久儲存空間外的資料寫入，包含運行紀錄以及容器內的其餘檔案系統空間的使用，這個類型一般不太容易預估，因此我們給予較寬鬆的限制，另外因為其使用量典型為持續累積（如容器無法主動刪除其運行紀錄），超過 limit 時 Kubernetes 會將容器重啟，為減少對使用者的影響，通常 limit 相對之下特別高。
-單一容器預設佔有量以及 \ref{sec:kubectl-shell} kubectl shell 的佔有量也將影響使用者體驗，其中尤其是 kubectl shell 的佔有量，為了避免影響使用者權益，我們希望將他壓低，但又不應降到令使用者感到卡頓。另外在使用者不自行估計限制的情況下，單一容器預設佔有量除了影響能同時運行的容器數量，也影響到能夠運行的工作負載種類，在此方面最敏感的是 memory，部份使用較多 memory 的程式可能會因為不足而異常中止，無法順利運行。對於這兩組佔有量的評估也是實驗要點之一。
+單一容器預設佔有量以及 \ref{sec:kubectl-shell} kubectl shell 的佔有量也將影響使用者體驗，其中尤其是 kubectl shell 的佔有量，為了避免影響使用者權益，我們希望將他壓低，但又不應降到令使用者感到卡頓。另外在使用者不自行估計限制的情況下，單一容器預設佔有量除了影響能同時運行的容器數量，也影響到能夠運行的工作負載種類，在此方面最敏感的是記憶體，部份使用較多記憶體的程式可能會因為不足而異常中止，導致無法順利運行。對於這兩組佔有量的評估也是實驗要點之一。
對於配額的規劃在實驗階段與正式上線也將有所誤差，尤其對於 CPU 在測試環境用的是系計中的二線老舊硬體，改為正式用的一線新硬體時，配合效能的改變，應能再減少其配額量至一半左右。