2 files changed, 8 insertions(+), 8 deletions(-)

M Sections/2.Backgrounds.tex
M Sections/4.Architecture.tex

@@ 9,14 9,14 @@ Kubernetes （簡稱 K8s）為一容器編排 (orchestration) 系統，其主要
 
 \subsection{Kubernetes 架構}
 
-Kubernetes 提供 RESTful API 做為主要控制手段，以 resources 作為對操作意圖的描述以及結果，將系統操作以非同步的形式建模為對 resources 進行讀寫，並且將系統大致切成兩大部份：負責提供 API 與 resources 資料存儲的 API 伺服器 \verb|kube-apiserver|，以及實際實做 resources 所代表的操作的 controllers。典型的操作流程大致如下：
+Kubernetes 提供 RESTful API 做為主要控制手段，以 resources 作為對操作意圖的描述以及結果，將系統操作以非同步的形式建模為對 resources 進行讀寫，並且將系統大致切成兩大部份：負責提供 API 與 resources 資料存儲的 API 伺服器 kube-apiserver，以及實際實做 resources 所代表的操作的 controllers。典型的操作流程大致如下：
 
 \begin{onehalfspacing}
 \begin{enumerate}
     \item 使用者建立一 resource，並在其 \verb|spec| 欄位描述需要的系統狀態
-    \item \verb|kube-apiserver| 通知相關 controller 有新的 resource 創立
+    \item kube-apiserver 通知相關 controller 有新的 resource 創立
     \item controller 根據 \verb|spec| 欄位進行操作，嘗試滿足 \verb|spec|，並將結果存入 \verb|status| 欄位
-    \item \verb|kube-apiserver| 通知使用者 resource 有所變更
+    \item kube-apiserver 通知使用者 resource 有所變更
     \item 使用者透過更新後的 \verb|status| 欄位得知操作結果
 \end{enumerate}
 \end{onehalfspacing}


@@ 27,7 27,7 @@ Kubernetes 提供 RESTful API 做為主要控制手段，以 resources 作為對
     \caption{Kubernetes 操作模型簡易示意圖}
 \end{figure}
 
-\noindent 這個架構使得 Kubernetes 在功能面上極易擴展，只須對 \verb|kube-apiserver| 註冊一個新的 resource 種類，並且實做相關 controller 邏輯，便可以擴展 Kubernetes API。\verb|kube-apiserver| 除了資料存儲以外，也包含了基本的資料驗證、身份驗證以及相關授權機制，使得 controller 能夠更專注於達成 resource 邏輯的實做，進一步減少擴展開發者的負擔。同時在 resource 本身的設計上，通常也會盡量使描述的操作是可以被重複執行的 (idempotent)，令 controller 不須額外維護內部狀態 (stateless)，簡化 controller 的部屬管理以及提高 controller 的容錯性，使整體系統更為易用且可靠。
+\noindent 這個架構使得 Kubernetes 在功能面上極易擴展，只須對 kube-apiserver 註冊一個新的 resource 種類，並且實做相關 controller 邏輯，便可以擴展 Kubernetes API。kube-apiserver 除了資料存儲以外，也包含了基本的資料驗證、身份驗證以及相關授權機制，使得 controller 能夠更專注於達成 resource 邏輯的實做，進一步減少擴展開發者的負擔。同時在 resource 本身的設計上，通常也會盡量使描述的操作是可以被重複執行的 (idempotent)，令 controller 不須額外維護內部狀態 (stateless)，簡化 controller 的部屬管理以及提高 controller 的容錯性，使整體系統更為易用且可靠。
 
 % maybe a subsection here if it grows
 


@@ 41,7 41,7 @@ Kubernetes 中的 X.509 憑證即為 TLS 客戶端憑證 (client certificate)，
 
 Authenticating proxy 透過在 Kubernetes API 之前加一層 proxy 伺服器進行驗證邏輯。Proxy 在將請求轉發給 Kubernetes API 時會加上相關 HTTP headers 以表明使用者身份，而 proxy 本身對使用者的認證方式並沒有限制。這個方法等同於將驗證邏輯直接抽出另外自行實做，開發成本較高，並且需自行注意如撤銷等機制的是否完善。
 
-其餘的手段皆是透過 token 進行身份驗證，但 token 本身有所不同。Static tokens 是在 Kubernetes 本身預先設定好一個 token 對應使用者名稱、所在群組的清單，token 本身通常採用一個隨機的字串。由於目前實做上更動這份清單需要重新啟動 \verb|kube-apiserver|，這個方法較少人採用。Webhook tokens 則是透過管理者提供的 HTTPS API 去將 token 對應到相關資訊，比 static tokens 來的有彈性，可以動態更動不須重啟 \verb|kube-apiserver|。
+其餘的手段皆是透過 token 進行身份驗證，但 token 本身有所不同。Static tokens 是在 Kubernetes 本身預先設定好一個 token 對應使用者名稱、所在群組的清單，token 本身通常採用一個隨機的字串。由於目前實做上更動這份清單需要重新啟動 kube-apiserver，這個方法較少人採用。Webhook tokens 則是透過管理者提供的 HTTPS API 去將 token 對應到相關資訊，比 static tokens 來的有彈性，可以動態更動不須重啟 kube-apiserver。
 
 ServiceAccount tokens 與 OpenID Connect tokens 則都是 JSON Web Token (JWT)，一個有經過簽章的 token 格式，裡面包含身份資訊與使用期限等，Kubernetes 透過驗證簽章來確保他的真實性。ServiceAccount 是一個 resources 種類，代表一個身份，但不支援群組，由此可以簽發 ServiceAccount tokens，刪除 ServiceAccount resources 可以撤銷全部由其發出的 tokens。簽發 ServiceAccount tokens 時也可以進一步綁定 Secrets\footnote{Secret: Kubernetes resources 種類，提供資料儲存，本身並不帶有任何功能。} 或 Pods，使用時會額外檢查這些 resources 是否存在，達成以 token 為單位的撤銷。由於可以透過 Kubernetes API 管理，ServiceAccount tokens 常用於自動化場景，也常用於 controllers 元件。由於 ServiceAccount tokens 採用標準的 JWT 格式，透過簽章即可確認真偽，也有自 Kubernetes 存取外部系統時，供外部系統驗證的應用。
 


@@ 57,7 57,7 @@ Kubernetes 主要透過兩個機制達成使用者的存取控制，其一是 RB
 
 Kubernetes 內建許多 admission controllers，其中一些用來實做基本功能並預設啟用，例如資源配額的部份邏輯即是以這個機制實做。另外也有些預設停用的 admission controllers，提供給管理者進行平台加固或者調整行為使用。
 
-對於內建的 admission controllers 不敷使用的場合，Kubernetes 提供兩個機制讓管理者進一步自訂邏輯：webhooks 與 Common Expression Language （簡稱 CEL）。Webhooks 透過呼叫管理者提供的 HTTPS API 達成，支援 mutating 與 validating，可以透過任何能架設 HTTPS API 的語言編寫，在生態系上已經有多個框架可以協助開發，例如：Open Policy Agent 與 Kyverno 等。CEL 為一結構資料處理語言，常用以使軟體功能可程式化，以 Kubernetes 1.31 而言，目前只有 validating 進入穩定狀態，對 mutating 的支援仍在測試階段 (alpha)。相對於 webhooks，使用 CEL 可以直接在 \verb|kube-apiserver| 上執行邏輯，省略了呼叫 HTTPS API 的網路溝通，減少造成的延遲影響與管理負擔，但能夠進行的操作受限於 Kubernetes 對其執行環境提供的函式庫。
+對於內建的 admission controllers 不敷使用的場合，Kubernetes 提供兩個機制讓管理者進一步自訂邏輯：webhooks 與 Common Expression Language （簡稱 CEL）。Webhooks 透過呼叫管理者提供的 HTTPS API 達成，支援 mutating 與 validating，可以透過任何能架設 HTTPS API 的語言編寫，在生態系上已經有多個框架可以協助開發，例如：Open Policy Agent 與 Kyverno 等。CEL 為一結構資料處理語言，常用以使軟體功能可程式化，以 Kubernetes 1.31 而言，目前只有 validating 進入穩定狀態，對 mutating 的支援仍在測試階段 (alpha)。相對於 webhooks，使用 CEL 可以直接在 kube-apiserver 上執行邏輯，省略了呼叫 HTTPS API 的網路溝通，減少造成的延遲影響與管理負擔，但能夠進行的操作受限於 Kubernetes 對其執行環境提供的函式庫。
 
 \section{Helm}
 

@@ 69,7 69,7 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使
 \subsection{PodTolerationRestriction}
 \label{sec:PodTolerationRestriction}
 
-在典型的 Kubernetes 叢集規劃下，節點分為兩大類：control plane 與 worker nodes。Control plane 負責運行叢集本身的元件，例如 \verb|kube-apiserver| 與各式 controllers 等；而 worker nodes 負責運行一般的工作負載。Control plane 的元件通常也是以容器的形式部屬，而其節點也會納入叢集本身的管轄下，然而我們不希望 control plane 節點運行一般工作負載，避免影響到叢集控制邏輯的運行。Kubernetes 提供 taints 機制，用來標示 Node 的屬性，以及屬性應帶來的效果。以這個場景為例，我們標示這個 Node 為 control plane 並且不允許納入排程。此外，taints 機制同時也拿來自動標記異常的節點，例如節點資源即將耗盡的場景，並且藉此調整排程機制，優先使用其他節點。
+在典型的 Kubernetes 叢集規劃下，節點分為兩大類：control plane 與 worker nodes。Control plane 負責運行叢集本身的元件，例如 kube-apiserver 與各式 controllers 等；而 worker nodes 負責運行一般的工作負載。Control plane 的元件通常也是以容器的形式部屬，而其節點也會納入叢集本身的管轄下，然而我們不希望 control plane 節點運行一般工作負載，避免影響到叢集控制邏輯的運行。Kubernetes 提供 taints 機制，用來標示 Node 的屬性，以及屬性應帶來的效果。以這個場景為例，我們標示這個 Node 為 control plane 並且不允許納入排程。此外，taints 機制同時也拿來自動標記異常的節點，例如節點資源即將耗盡的場景，並且藉此調整排程機制，優先使用其他節點。
 
 與 taints 相對，Pod 可以設定 tolerations 來抑制 taints 的效果。例如在擴充 Kubernetes API 的場景，我們需要部屬實做自訂 resource 種類邏輯的 controller，這個 controller 屬於叢集控制邏輯的一部分，我們會希望規劃在 control plane 運行。在部屬此 controller 時，我們便會設定前述 taints 相對的 tolerations 解除限制，並且搭配其他排程設定強制排程至 control plane。
 


@@ 115,7 115,7 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使
 
 對於管理需求，我們在 admission control 實做保留了彈性，若操作者為管理者即不加以限制。管理者可以自行創立代表他人的 User，為其修改身份組，提供人工處理政策上例外的空間。另外，由 User 所產生的每個 resource 皆會採用 Kubernetes 的 \verb|ownerReferences| 機制。\verb|ownerReferences| 表現了一個 resource 被一個 owner resource 所管轄，當 owner resource 被刪除時，Kubernetes 的回收機制也會一併刪除此 resource。在我們的場景，由於使用者的資料皆為於個人專屬的 Namespace 底下，而 User 又為此 Namespace 的 owner resource，於是當使用者行為極端異常，管理者需要對其制裁時，只須刪除其 User 變可以徹底清除此使用者的所作所為。
 
-在實做方面，User 種類的定義以及 controller 邏輯採取 kubebuilder 框架實做。kubebuilder 採用 Go 程式語言，以及 \verb|sig.k8s.io/controller-runtime| 函式庫開發，提供由 Go 語言的資料結構定義輔以註解擴充，搭配程式碼生成技術實現 Kubernetes resource 種類的定義，並且提供實做 controller 時所需的監控 resources 變更等基本邏輯。另外，\verb|sig.k8s.io/controller-runtime| 亦具備 \verb|envtest| 測試框架，自動化運行 \verb|kube-apiserver| 等元件，在不需要架設完整叢集的前提下，提供 controller 較為完整的測試環境。
+在實做方面，User 種類的定義以及 controller 邏輯採取 kubebuilder 框架實做。kubebuilder 採用 Go 程式語言，以及 \verb|sig.k8s.io/controller-runtime| 函式庫開發，提供由 Go 語言的資料結構定義輔以註解擴充，搭配程式碼生成技術實現 Kubernetes resource 種類的定義，並且提供實做 controller 時所需的監控 resources 變更等基本邏輯。另外，\verb|sig.k8s.io/controller-runtime| 亦具備 \verb|envtest| 測試框架，自動化運行 kube-apiserver 等元件，在不需要架設完整叢集的前提下，提供 controller 較為完整的測試環境。
 
 \subsection{Namespace}