1 files changed, 4 insertions(+), 4 deletions(-)

M Sections/3.RelatedWorks.tex

@@ 31,14 31,14 @@
 
 \section{Kubernetes 的多租戶模型}
 
-CScloud 採用的基於 Namespace 的多租戶模型由於 Kubernetes 本身的設計，需要大量的額外加固開發成本以確保租戶間的獨立性。在 Kubernetes 下，由於功能面的廣泛，以及專注於單一租戶的歷史脈絡，導致實做多租戶有不同的方法與租戶隔離程度，其中依照使用場景又常分為軟、硬兩種多租戶層級\cite{k8smultitenancy}。
+雲端運算的一大要點為集結大量資源，予以集中管理，彈性分配給多個租戶使用以提高運用效率。然而 Kubernetes 因功能的廣泛，以及專注於單一租戶的歷史脈絡，導致實做多租戶有多個不同的方法與隔離程度，其中依照使用場景又常分為軟、硬兩種多租戶層級\cite{k8smultitenancy}。
 
 軟多租戶指的是租戶間擁有一定程度的信任，在租戶間的隔離與安全性上的需求較低，而專注於防止租戶間的意外狀況影響，常見於同個公司內部的不同團隊。硬多租戶則是指租戶間無法存在信任，任一租戶都必須視為可能的攻擊者，在設計上必須以隔離、安全性為優先考量。本研究欲達成的目標較偏向硬多租戶。
 
-Kubernetes Namespaces 由於只影響 API 上能描述的 resources 相互關係，並不隱含實際工作負載的隔離，常用來實做軟多租戶。然而，透過 admission control 我們仍能為 resource 內容加以把關，強制使用者開啟對工作負載的額外隔離措施，彌補 Namespaces 在此方面的不足，使其更為貼近硬多租戶的目標。
+Kubernetes Namespaces 由於只影響 API 上能描述的 resources 相互關係，並不隱含實際工作負載的隔離，常用來實做軟多租戶。然而，透過 admission control 我們仍可為 resource 內容加以把關，強制使用者開啟對工作負載的額外隔離措施，彌補 Namespaces 在此方面的不足，使其更為貼近硬多租戶的目標。CScloud 即是採用此類方案，但同時帶來的是大量的額外加固開發成本以確保租戶間的獨立性。
 
-在硬多租戶的議題下，另一個常見許多的手法是基於叢集的多租戶模型，透過給予每的租戶一個獨立的叢集，進而免除對叢集本身的大多數加固需求，以租戶的角度來看單純許多，並且能夠使用較完整的 Kubernetes 功能。
+在硬多租戶的議題下，另一個常見許多的手法則是基於叢集的多租戶模型，透過給予每個租戶獨立的叢集，進而免除對叢集內部的大多數加固需求，以高層次架構來看單純許多，並且租戶能夠使用較完整的 Kubernetes 功能。
 
-基於叢集的多租戶由於需要動態的配置多個獨立叢集與節點，因此經常透過大型虛擬機平台實做，加上 cluster API 達成相關的自動化。Cluster API 是 Kubernetes API 的延伸，透過自訂 resource 種類，將租戶叢集的管理以 controller 的方式實做，達成以一個管理用母叢集，管理多個租戶子叢集的形式，減少在維運上的負擔。有些手法另外會將叢集邏輯元件在部屬上盡可能與叢集本身抽離，以其他方式統一代管，避免租戶操作上的意外影響，提昇可靠度，並且降低多叢集在資源上的部份負擔。
+基於叢集的多租戶需要動態的配置多個獨立叢集與節點，因此經常透過大型虛擬機平台實做，加上 cluster API 達成相關的自動化。Cluster API 是 Kubernetes API 的延伸，透過自訂 resource 種類，將租戶叢集的管理以 controller 的方式實做，達成以一個管理用母叢集，控管多個租戶子叢集的形式，減少在維運上的負擔。有些手法另外會將叢集邏輯元件在部屬上盡可能與叢集本身抽離，以其他方式統一代管，避免租戶操作上的意外影響，提昇可靠度，並且降低多叢集在資源上的部份負擔。
 
 雖然基於叢集的多租戶具備功能完整、架構簡潔與高度隔離的優勢，並且已有較多完整的現成解決方案，然而資源開銷較大，本研究有上千個潛在的租戶，考量到系計中的硬體資源，此方法並不實際。本研究採取基於 Namespace 的多租戶設計，並且將其加固以貼近硬多租戶，使用較低的資源成本，但仍提供可接受的安全性。