3 files changed, 20 insertions(+), 2 deletions(-)

M Sections/4.Architecture.tex
M Sections/6.Conclusion.tex
M ref.bib

@@ 195,7 195,7 @@ Pods 作為 Kubernetes 中的重要角色之一，表示叢集上運行的容器
 
 對於 Helm 功能，我們希望保持 SPA 架構中，將部份邏輯推往瀏覽器端在運行成本上的優勢，規劃將其在瀏覽器內實做。起初我們將 Helm 的函式庫直接透過 WebAssembly 包裝，並提供其以指令操作為切分單位的函式接口與 TypeScript 串接，但我們發現以此方式實做效能不佳，於列出已安裝的 Helm Releases 等基本操作，在低資料量下已產生足以影響使用者體驗的延遲。
 
-Helm Release 預設的 Secret 儲存方式需要經過 Base64\footnote{Base64: 一個編碼格式，可將任何形式資料轉為文字表示。} 與 gzip\footnote{gzip: 一個被廣泛利用的資料壓縮演算法。} 等操作，如果將 Helm Release 的解讀透過 WebAssembly 處理，在不經調整的情況下，呼叫的是來自 Go 語言基本函式庫的 Base64 與 gzip 實做。WebAssembly 雖然設計上已經較為接近硬體，但仍是虛擬機架構，在運算上仍然有額外負擔。而 Base64 與 gzip 作為常用的算法，瀏覽器本身有提供高效能的實做，卻未被利用。另外將資料傳送進出 WebAssembly 環境也有一定的執行成本。
+Helm Release 預設的 Secret 儲存方式需要經過 Base64\footnote{Base64: 一個編碼格式，可將任何形式資料轉為文字表示。} 與 gzip\footnote{gzip: 一個被廣泛利用的資料壓縮演算法。} 等操作，如果將 Helm Release 的解讀透過 WebAssembly 處理，在不經調整的情況下，呼叫的是來自 Go 語言基本函式庫的 Base64 與 gzip 實做。WebAssembly 雖然已經較為接近硬體，但設計上仍有些許限制，以及於瀏覽器場景即時編譯成原生指令迫於時間壓力無法進行較耗時的最佳化，導致效能與原生程式還是有落差\cite{jangda2019not}。而 Base64 與 gzip 作為常用的算法，瀏覽器本身有提供高效能的原生實做，在此情景卻未被利用。另外將資料傳送進出 WebAssembly 環境也有一定的執行成本。
 
 關於這個情景，我們面臨兩個可能的解法：抽換相關演算法改為呼叫瀏覽器的實做，或者將容易影響使用者體驗的區塊以 TypeScript 重新實做。抽換的方法不但無法避免資料傳輸的負擔，反而會增加傳送的次數，不甚理想。而分析 Helm 架構可發現，除了模板引擎因基於 Go 基本函式庫的模板框架，設計容易牽涉語言特性而不易重新實做外，剩餘的區塊皆為一般的資料處理與 Kubernetes API 的串接。其中需要模板引擎的操作只有安裝、升級等使用者傾向預期需要時間的情景，不包含對使用者體驗影響重大的列出 Helm Releases。綜上考量，我們將 Helm 模板引擎外的部份抽離，由 TypeScript 重新實做。
 

@@ 19,7 19,7 @@ Kubernetes 定義了 NetworkPolicy 種類，以設定 Pod 的防火牆規則，
 
 這類型的方法大多牽涉調整 Container Runtime Interface (CRI)\footnote{CRI: Kubernetes 對於 Pod 與容器的實際執行實做提供的界面定義。}，修改其實做或者對其額外加固。修改 CRI 實做的方案有：將容器運行在獨立的虛擬機內（如：Kata Containers、Edera krata）、攔截部份系統呼叫於 user space\footnote{User space: 作業系統供程式運行的環境，相對於核心的 kernel space，user space 具有較低的權限。} 重新實做（如：gVisor）。而對 CRI 進行加固的方法主要是透過 mandatory access control（MAC，如：SELinux、AppArmor），Kubernetes 在 API 設計上允許 CRI 層自行提供 MAC 的政策定義，我們可以針對平台需求修改為更加嚴格的政策。
 
-修改 CRI 實做的方案對於實際容器運行皆會增加運算負擔，甚至牽涉虛擬化技術，一定程度的降低容器在資源運用上的優勢\cite{espe2020performance}。而對於 CRI 額外加固則是需要對系統運作與典型工作負載有相當深入的理解，在開發上的負擔不容小覷。面對如此多元的解決方案，我們需要進一步實驗進行權衡，在成本與安全性中找尋平衡點。將系統正式上線、對平台需求規模有更明確深入的認知也將有助於這方面的分析。
+修改 CRI 實做的方案對於實際容器運行皆會增加運算負擔，甚至牽涉虛擬化技術，一定程度的降低容器在資源運用上的優勢\cite{espe2020performance}\cite{viktorsson2020security}。而對於 CRI 額外加固則是需要對系統運作與典型工作負載有相當深入的理解，在開發上的負擔不容小覷。面對如此多元的解決方案，我們需要進一步實驗進行權衡，在成本與安全性中找尋平衡點。將系統正式上線、對平台需求規模有更明確深入的認知也將有助於這方面的分析。
 
 \subsection{Control plane 虛擬化}
 

@@ 239,3 239,21 @@
     year	= {2023},
     publisher	= {River Publishers},
 }
+
+@inproceedings{viktorsson2020security,
+    title	= {Security-performance trade-offs of kubernetes container runtimes},
+    author	= {Viktorsson, William and Klein, Cristian and Tordsson, Johan},
+    booktitle	= {2020 28th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS)},
+    pages	= {1--4},
+    year	= {2020},
+    organization	= {IEEE},
+}
+
+@inproceedings{jangda2019not,
+    title	= {Not so fast: Analyzing the performance of {WebAssembly} vs. native code},
+    author	= {Jangda, Abhinav and Powers, Bobby and Berger, Emery D and Guha, Arjun},
+    booktitle	= {2019 USENIX Annual Technical Conference (USENIX ATC 19)},
+    pages	= {107--120},
+    year	= {2019},
+}
+