7 files changed, 19 insertions(+), 6 deletions(-)

M Sections/1.Introduction.tex
M Sections/2.Backgrounds.tex
A Sections/3.RelatedWorks.tex
R Sections/{3.Architecture.tex => 4.Architecture.tex}
R Sections/{4.Evaluation.tex => 5.Evaluation.tex}
R Sections/{5.Conclusion.tex => 6.Conclusion.tex}
M main.tex

@@ 1,7 1,7 @@
 \chapter{緒論}
 \label{ch:intro}
 
-本章節敘述國立陽明交通大學資工系資訊中心（以下簡稱系計中）對於網頁代管的需求起源，並分析現有雛型系統 CScloud。
+本章節敘述國立陽明交通大學資工系資訊中心（以下簡稱系計中）對於網頁代管的需求起源，以及演變成雲端平台的脈絡。
 
 \section{研究動機}
 

@@ 7,6 7,8 @@
 
 Kubernetes （簡稱 K8s ）為一容器編排 (orchestration) 系統，其主要任務為將容器委派至叢集節點上執行。為了對網路服務容器達到理想的編排，Kubernetes 也帶有負載均衡、高可用性及自動擴展等網路功能，因此可以將 Kubernetes 視為高度可擴展、可靠的網路程式平台。
 
+\subsection{Kubernetes 架構}
+
 Kubernetes 提供 RESTful API 做為主要控制手段，以 resources 作為對操作意圖的描述以及結果，將系統操作以非同步的形式建模為對 resources 進行讀寫，並且將系統大致切成兩大部份：負責提供 API 與 resources 資料存儲的 API 伺服器 (kube-apiserver)，以及實際實做 resources 所代表的操作的 controllers。典型的操作流程大致如下：
 
 \begin{enumerate}


@@ 20,9 22,15 @@ Kubernetes 提供 RESTful API 做為主要控制手段，以 resources 作為對
 \begin{figure}
     \centering
     \includegraphics{assets/kubernetes.png}
-    \caption{Kubernetes 操作模型簡化示意圖}
+    \caption{Kubernetes 操作模型簡易示意圖}
 \end{figure}
 
 \noindent 這個架構使得 Kubernetes 在功能面上極易擴展，只須對 kube-apiserver 註冊一個新的 resource 類別，並且實做相關 controller 邏輯，便可以擴展 Kubernetes API。kube-apiserver 除了資料存儲以外，也包含了基本的資料驗證、身份驗證以及相關授權機制，使得 controller 能夠更專注於達成 resource 邏輯的實做，進一步減少擴展開發者的負擔。同時在 resource 本身的設計上，通常也會盡量使描述的操作是可以被重複執行的 (idempotent)，令 controller 不須額外維護內部狀態 (stateless)，簡化 controller 的部屬管理以及提高 controller 的容錯性，使整體系統更為易用且可靠。
 
-Kubernetes resources 的種類帶給 resources 既定的語意和格式，例如：Pod 代表一組可以互通部份設定的容器、Service 代表網路上具備負載均衡的一個存取點、Node 代表從集中的一個節點等。其中各個種類又可以分為兩大類：namespaced 與 cluster-scoped。Namespaced 代表這種 resources 在 API 上受到 Namespace 分隔，在不同的 Namespace 下，各個 resources 無法相互關聯，通常用於描述賦予叢集的工作 (workload)，Pod 與 Service 即為此類，Service 可以關聯到多個 Pod 提供存取點的實際服務內容，但在設計上不允許 Service 取用其他 Namespace 下的 Pod。Cluster-scoped 的種類不受 Namespace 管轄，屬於整個叢集，常見於描述叢集本身的設定，Node 與 Namespace 本身即為此類。Namespace 常用於切分不同的應用，使得不同應用在部屬設定上不會互相衝突影響，但須注意 Namespace 僅只影響 resources 能夠描述的相互關係，並不代表會對實際運行的容器或網路進行隔離加固。
+% maybe a subsection here if it grows
+
+Kubernetes resources 的種類帶給 resources 既定的語意和格式，例如：Pod 代表一組可以互通部份設定的容器、Service 代表網路上具備負載均衡的一個存取點、Node 代表叢集中的一個節點等。其中各個種類又可以分為兩大類型：namespaced 與 cluster-scoped。Namespaced 代表這種 resources 在 API 上受到 Namespace 分隔，在不同的 Namespace 下，各個 resources 無法相互關聯，通常用於描述賦予叢集的工作 (workload)，Pod 與 Service 即為此類，Service 可以關聯到多個 Pod 提供存取點的實際服務內容，但在設計上不允許 Service 取用其他 Namespace 下的 Pod。Cluster-scoped 的種類不受 Namespace 管轄，屬於整個叢集，常見於描述叢集本身的設定，Node 與 Namespace 本身即為此類。Namespace 常用於切分不同的應用，使得不同應用在部屬設定上不會互相衝突影響，但須注意 Namespace 僅只影響 resources 能夠描述的相互關係，並不代表會對實際運行的容器或網路進行隔離加固。
+
+% TODO maybe authn here to introduce sparkles token management later
+
+\subsection{Kubernetes 存取控制}

@@ 0,0 1,4 @@
+\chapter{相關研究}
+\label{ch:related-works}
+
+本章節敘述系計中對於此議題所發展出的 CScloud PaaS 雛型系統，並分析其架構優劣，作為本研究的基石。

@@ 135,9 135,10 @@
 % put your statements in the following
 \input{Sections/1.Introduction} \newpage
 \input{Sections/2.Backgrounds} \newpage
-\input{Sections/3.Architecture} \newpage
-\input{Sections/4.Evaluation} \newpage
-\input{Sections/5.Conclusion} \newpage
+\input{Sections/3.RelatedWorks} \newpage
+\input{Sections/4.Architecture} \newpage
+\input{Sections/5.Evaluation} \newpage
+\input{Sections/6.Conclusion} \newpage
 
 
 % ====================================================