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

M Sections/2.Backgrounds.tex
A assets/kubernetes-resources.png

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