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

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

@@ 43,7 43,7 @@ Authenticating proxy 透過在 Kubernetes API 之前加一層 proxy 伺服器進
 
 其餘的手段皆是透過 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 存取外部系統時，供外部系統驗證的應用。
+ServiceAccount tokens 與 OpenID Connect tokens 則都是 JSON Web Token (JWT)，一個有經過簽章的 token 格式，裡面包含身份資訊與使用期限等，Kubernetes 透過驗證簽章來確保他的真實性。ServiceAccount 是一個 resources 種類，代表一個身份，但不支援群組，由此可以簽發 ServiceAccount tokens，刪除 ServiceAccount resources 可以撤銷全部由其發出的 tokens。簽發 ServiceAccount tokens 時也可以進一步綁定 Secrets\footnote{Secret: Resources 種類，提供資料儲存，本身並不帶有任何功能。} 或 Pods，使用時會額外檢查這些 resources 是否存在，達成以 token 為單位的撤銷。由於可以透過 Kubernetes API 管理，ServiceAccount tokens 常用於自動化場景，也常用於 controllers 元件。由於 ServiceAccount tokens 採用標準的 JWT 格式，透過簽章即可確認真偽，也有自 Kubernetes 存取外部系統時，供外部系統驗證的應用。
 
 OpenID Connect (OIDC) 則是一個基於 OAuth 框架衍生的身份驗證協定，常用於網頁應用場景，由中心化的伺服器進行驗證，將身份資訊授予其他應用使用，並且可以讓使用者管理對應用存取身份資料的授權。Kubernetes 本身並不實做 OIDC 協定，而是利用驗證流程 OIDC 伺服器所簽發的 JWT (\verb|id_token|) 進行驗證，並預期由客戶端處理 OIDC 協定相關操作。由於可以跟現有 OIDC server 整合，實做容易且使用者不須額外的註冊流程，常用於使用者的互動存取。
 


@@ 61,7 61,7 @@ Kubernetes 內建許多 admission controllers，其中一些用來實做基本
 
 \section{Helm}
 
-Helm 是用來簡化 Kubernetes 上的應用部屬流程的工具，其手段是透過模板化，使得部屬上的設定可以透過更貼近應用本身的角度撰寫。在 Kubernetes 上，典型的部屬應用流程會牽涉多個 resources，例如：Deployment\footnote{Deployment: Kubernetes resources 種類，提供高層次的 Pod 管理，以實做 Pod 的更新與複製等。} 用以管控 Pods、Service 將 Pods 提供的服務集結做負載均衡、Ingress\footnote{Ingress: Kubernetes resources 種類，配置叢集的 HTTP 反向代理，將多個網頁服務集中提供外界存取。} 為 Service 的網頁服務設立反向代理至公網公開等。多個 resources 使得應用部屬有一定的複雜程度，Helm 可以提供更高層級、以應用為中心的單一設定界面，藉此簡化 Kubernetes 的使用。
+Helm 是用來簡化 Kubernetes 上的應用部屬流程的工具，其手段是透過模板化，使得部屬上的設定可以透過更貼近應用本身的角度撰寫。在 Kubernetes 上，典型的部屬應用流程會牽涉多個 resources，例如：Deployment\footnote{Deployment: Resources 種類，提供高層次的 Pod 管理，以實做 Pod 的更新與複製等。} 用以管控 Pods、Service 將 Pods 提供的服務集結做負載均衡、Ingress\footnote{Ingress: Kubernetes resources 種類，配置叢集的 HTTP 反向代理，將多個網頁服務集中提供外界存取。} 為 Service 的網頁服務設立反向代理至公網公開等。多個 resources 使得應用部屬有一定的複雜程度，Helm 可以提供更高層級、以應用為中心的單一設定界面，藉此簡化 Kubernetes 的使用。
 
 Helm 用來產生 Kubernetes resources 的模板稱為 Helm Chart，Helm Charts 會集中在 Helm Repository 裡提供使用，Helm Chart 的模板參數稱為 Helm Values，由 Helm 安裝起來的一套應用稱為 Helm Release。透過模板產生的 resources 定義除了套用到 Kubernetes 上之外，Release 會對 resources 額外進行版本紀錄，用以實做更新、回滾、解除安裝等操作。Release 的版本追蹤資訊通常以 Secrets 的形式儲存在叢集內。
 

@@ 129,6 129,8 @@ Namespace 上 \verb|u-| 以及平台提供域名中 \verb|u.| 的命名切分設
 
 ResourceQuota 是 Kubernetes 的一個 resource 種類，用來實做資源配額，其運作邏輯大致分兩大塊：admission controller 與一般的 controller。ResourceQuota 的 admission controller 屬於 validating，負責在創立或更新 resource 時推算其資源用量的變化值，並且拒絕用量會超出配額的請求。一般的 controller 端則是以更為全面的觀點，監控整體 resources 的變更，並且統計資源用量總額。
 
+ResourceQuota 所能管控的資源大致有兩種：運算資源以及 resources 的數量。運算資源具有量值，例如部屬容器時設定的 CPU 或者記憶體用量限制，以及 PersistentVolumeClaim (PVC)\footnote{PVC: Resources 種類，表示儲存空間請求，需自動或手動與 PersistentVolume（PV，分配實體）耦合。} 中的儲存用量請求。Resources 的數量則是滿足特定條件的 resources 的個數，例如正在運行的 Pods。
+
 \section{網頁界面實做}
 
 進一步對網頁界面的需求分析，可以將網頁界面切分為兩大塊：支援 Helm 的通用 Kubernetes 網頁型客戶端，以及 CSKloud 特定的部份，包含權限開通元件的整合以及 CSKloud 平台面向使用者的文件等。其中 Kubernetes 客戶端很容易的就可以利用於其他場景，我們採取 open core 的策略，將其 Kubernetes 客戶端開放原始碼，以 MIT 授權條款\footnote{MIT license: 一個在網頁技術場域廣受歡迎的寬鬆型開放原始碼條款。}釋出，命名為 Sparkles\footnote{Sparkles 釋出於 \url{https://github.com/xdavidwu/sparkles} 。}，回饋於社會，使得非平台使用者也能受益，同時可以也利用開放原始碼社群的力量來茁壯平台的發展。