@@ 33,12 33,30 @@
雲端運算的一大要點為集結大量資源，予以集中管理，彈性分配給多個租戶使用以提高運用效率。然而 Kubernetes 因功能的廣泛，以及專注於單一租戶的歷史脈絡，導致實做多租戶有多個不同的方法與隔離程度，其中依照使用場景又常分為軟、硬兩種多租戶層級\cite{k8smultitenancy}。
-軟多租戶指的是租戶間擁有一定程度的信任，在租戶間的隔離與安全性上的需求較低，而專注於防止租戶間的意外狀況影響，常見於同個公司內部的不同團隊。硬多租戶則是指租戶間無法存在信任，任一租戶都必須視為可能的攻擊者，在設計上必須以隔離、安全性為優先考量。本研究欲達成的目標較偏向硬多租戶。
+軟多租戶指的是租戶間擁有一定程度的信任，在租戶間的隔離與安全性上的需求較低，而專注於防止租戶間的操作意外影響，常見於同個公司內部的不同團隊。硬多租戶則是指租戶間無法存在信任，任一租戶都必須視為可能的攻擊者，在設計上必須以隔離、安全性為優先考量，常見於公有服務。本研究欲達成的目標為硬多租戶。
-Kubernetes Namespaces 由於只影響 API 上能描述的 resources 相互關係，並不隱含實際工作負載的隔離，常用來實做軟多租戶。然而，透過 admission control 我們仍可為 resource 內容加以把關，確保使用者在其他層面啟用對工作負載的隔離措施，防止在共用叢集的架構下影響其他租戶，彌補 Namespaces 在此方面的不足，使整體更為貼近硬多租戶的目標。CScloud 即是採用此類方案，但同時帶來的是大量的 admission control 加固開發成本。
+Kubernetes Namespaces 由於只影響 API 上能描述的 resources 相互關係，並不隱含實際工作負載的隔離，常用來實做軟多租戶。然而，透過 admission control 我們仍可為 resource 內容加以把關，確保使用者在其他層面啟用對工作負載的隔離措施，防止在共用叢集的架構下影響其他租戶，彌補 Namespaces 在此方面的不足，以達成硬多租戶的目標。CScloud 即是採用此類方案，但同時帶來的是大量的 admission control 加固開發成本。另外由於 Namespaces 設計上無法管控 cluster-scoped 的 resource 種類，在此方案下租戶無法使用相關功能。
在硬多租戶的議題下，另一個常見許多的手法則是基於叢集的多租戶模型，透過給予每個租戶獨立的叢集，進而免除對叢集內部的大多數加固需求，以高層次架構來看單純許多，並且租戶能夠使用較完整的 Kubernetes 功能。
-基於叢集的多租戶需要動態的配置多個獨立叢集與節點，因此經常透過大型虛擬機平台實做，加上 cluster API 達成相關的自動化。Cluster API 是 Kubernetes API 的延伸，透過自訂 resource 種類，將租戶叢集的管理以 controller 的方式實做，達成以一個管理用母叢集，控管多個租戶子叢集的形式，減少在維運上的負擔。有些手法另外會將叢集邏輯元件在部屬上盡可能與叢集本身抽離，以其他方式統一代管，避免租戶操作上的意外影響，提昇可靠度，並且降低多叢集在資源上的部份負擔。
+基於叢集的多租戶需要動態的配置多個獨立叢集與節點，因此經常透過大型虛擬機平台實做，加上 Cluster API 達成相關的自動化。Cluster API\cite{clusterapi} 是 Kubernetes API 的延伸，透過自訂 resource 種類，將租戶叢集的管理以 controller 的方式實做，達成以一個管理用母叢集，控管多個租戶子叢集的形式，減少在維運上的負擔。Cluster API 在實做上具有擴充性設計，將節點運算資源環境與加入叢集方式分離，定義提供者界面，使虛擬化平台以及 Kubernetes 發行版供應商的支援皆可擴充開發，並且兩者可以自由搭配使用，目前已經支援大多數常見的公、私有雲虛擬機平台。
+
+將大量叢集管理的想法再進一步延伸，有些手法另外會將叢集控制邏輯元件在部屬上與運算節點抽離，以其他方式統一代管。一方面避免租戶直接存取叢集關鍵元件，減少操作上的意外影響，提昇叢集整體可靠度，另一方面也降低多叢集在資源上的部份負擔。此類做法常見於直接提供 Kubernetes 服務的公有雲。
+
+雖然基於叢集的多租戶具備功能完整、架構簡潔與高度隔離的優勢，並且已有 Cluster API 自動化以輔助管理。然而多叢集運算資源與管理開銷較大，本研究有上千個潛在的租戶，即使我們將控制邏輯元件集中管理，並且每個叢集只提供一個節點，犧牲節點層面的高可用性，仍然可能需要上千個虛擬機，考量到系計中的硬體資源，此方法並不實際。相較於上千個小型叢集，一個大型叢集較易於管理，也能大幅減少虛擬機數量，避免重複運行相同系統元件帶來的資源浪費。本研究沿襲 CScloud，採取單一叢集、基於 Namespace 的多租戶設計，並且將其加固以實踐硬多租戶，使用較低的資源成本，但仍提供可接受的安全性。另外我們將加固實做重新整理，以更低的開發維護成本與更新的技術實現。
+
+\begin{table}[htb]
+ \centering
+ \caption{Kubernetes 硬多租戶實做形式彙整}
+ \begin{tabular}{l || c | c }
+ 租戶切分方式 & 叢集 & Namespace \\
+ \hline\hline
+ 實做主要議題 & 大量叢集管理自動化 & 單一叢集內部加固 \\ \hline
+ 典型的租戶隔離形式 & 虛擬機（叢集環境） & 容器 \\ \hline
+ 額外資源負擔 & 大 & 小 \\ \hline
+ 可用 Kubernetes 功能 & 完整 & 足以部屬網頁服務 \\ \hline
+ 開發負擔 & 小 & 大 \\ \hline
+ 管理負擔 & 大 & 小 \\
+ \end{tabular}
+\end{table}
-雖然基於叢集的多租戶具備功能完整、架構簡潔與高度隔離的優勢，並且已有較多完整的現成解決方案，然而資源開銷較大，本研究有上千個潛在的租戶，考量到系計中的硬體資源，此方法並不實際。本研究沿襲 CScloud，採取基於 Namespace 的多租戶設計，並且將其加固以貼近硬多租戶，使用較低的資源成本，但仍提供可接受的安全性。另外我們將加固實做重新整理，以更低的開發維護成本與更新的技術實現。
@@ 16,7 16,7 @@
type = {Master's thesis},
}
-% TODO dot position, urldate, unify rfcs
+% TODO urldate
@misc{kubernetes,
title = {{Kubernetes}},
@@ 274,3 274,12 @@
url = {https://docs.google.com/document/d/1PjlsBmZw6Jb3XZeVyZ0781m6PV7-nSUvQrwObkvz7jg},
urldate = {2024-09-25},
}
+
+@misc{clusterapi,
+ title = {Introduction - The {Cluster API} Book},
+ author = {{The Kubernetes Authors}},
+ year = {2024},
+ url = {https://cluster-api.sigs.k8s.io/introduction},
+ urldate = {2024-10-15},
+}
+