@@ 47,6 47,8 @@
\section{質性分析}
+\subsection{Sparkles}
+
本研究實做的 CSKloud 平台中，網頁界面除了針對平台的整合外，其核心 Sparkles 作為一個 Kubernetes 客戶端開發設計，並且適用於非 CSKloud 的場景。我們將 Sparkles 獨立討論，與其他常見的 Kubernetes 客戶端比較，結果如表 \ref{tab:sparkles-comparison}。
\begin{table}[htb]
@@ 80,6 82,8 @@ Port forwarding 是指將容器或者 Service 的網路存取點，透過 Kubern
在開放原始碼方面，Lens 原本採取 MIT 授權條款釋出，但約 2023 年九月時轉為專有軟體，不再提供原始碼存取。
+\subsection{CSKloud v3}
+
\begin{table}[htb]
\centering
\caption{平台歷代架構比較}
@@ 100,3 104,11 @@ Port forwarding 是指將容器或者 Service 的網路存取點，透過 Kubern
原始碼模型 & 閉源 & 閉源 & 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 策略則有助於進一步開發客群，獲得更廣泛的使用者回饋，並且也可以借助開源社群來降低部份維護成本。