1 files changed, 6 insertions(+), 0 deletions(-)

M Sections/6.Conclusion.tex

@@ 23,6 23,12 @@ Kubernetes 定義了 NetworkPolicy 種類，以設定 Pod 的防火牆規則，
 
 \subsection{Control plane 虛擬化}
 
+本研究設計的平台在通用性的侷限來自於共用叢集的架構設計，需透過權限切分容納多個租戶，導致租戶無法存取叢集的完整功能，其中最大的影響是使用者無法自行註冊對 Kubernetes API 的拓展。近期除了以 Helm Charts 交付軟體產品外，也逐漸流行以 operator pattern 另外開發 operator，自動化更為複雜的軟體部屬場景。無法自行拓展 Kubernetes API 也導致了使用者無法安裝這類型的產品。
+
+一個可能的解法是管理員先行安裝常見的 operators，搭配設定 RBAC 使得使用者仍然可以由其部屬軟體，但 operators 採取能夠控制整個叢集相關 resources 的權限運行，需要嚴格審視其設計實做的安全性，避免使用者經由 operators 達成提權，在管理上潛藏著不小的負擔。若管理員不熟悉單叢集多租戶設計，更容易忽略此類攻擊路徑。
+
+另一個可能的想法是貫徹 control plane 與 worker nodes 的切分概念，將 control plane 進一步進行虛擬化，使得每個租戶皆有專屬的完整虛擬 control plane，能夠存取更完整的 Kubernetes 功能，而實際 worker nodes 節點仍為共用，比多個完整叢集具備較少的資源負擔。然而系計中此前未有類似需求，對於 control plane 虛擬化相當陌生，需要更多實驗來了解其維運成本。
+
 \subsection{基礎設施代管}
 
 系計中在維運上除了最基礎的硬體、儲存設備與底層虛擬化平台外，軟體服務鮮少有直接購買解決方案的場景，大多採取自行維運相關基礎設施。對於網頁場景，由平日經驗中觀察，維運難度最高的是資料庫。建立一個資料庫並不複雜，但將資料庫運行的好需要設立多個實例，之間要有即時的資料複製機制，並且實做高可用性。具備高可用性的資料庫叢集雖然可靠，但萬一仍遇到罕見災難場景，其手動復原也需要對備援原理有相當深入的理解。即使 Kubernetes 本身對於高可用性已經有部份機制，牽涉到資料儲存仍然有相當大的成份需要自行處理。