~xdavidwu/cskloudv3-thesis

b646a45690b06952019945161196ff1e1be0bbbd — Pinghao Wu 2 months ago bae95a4
Architecture: why kubebuilder, \verb|kube-apiserver|
2 files changed, 10 insertions(+), 8 deletions(-)

M Sections/2.Backgrounds.tex
M Sections/4.Architecture.tex
M Sections/2.Backgrounds.tex => Sections/2.Backgrounds.tex +6 -6
@@ 9,14 9,14 @@ Kubernetes (簡稱 K8s)為一容器編排 (orchestration) 系統,其主要

\subsection{Kubernetes 架構}

Kubernetes 提供 RESTful API 做為主要控制手段,以 resources 作為對操作意圖的描述以及結果,將系統操作以非同步的形式建模為對 resources 進行讀寫,並且將系統大致切成兩大部份:負責提供 API 與 resources 資料存儲的 API 伺服器 (kube-apiserver),以及實際實做 resources 所代表的操作的 controllers。典型的操作流程大致如下:
Kubernetes 提供 RESTful API 做為主要控制手段,以 resources 作為對操作意圖的描述以及結果,將系統操作以非同步的形式建模為對 resources 進行讀寫,並且將系統大致切成兩大部份:負責提供 API 與 resources 資料存儲的 API 伺服器 \verb|kube-apiserver|,以及實際實做 resources 所代表的操作的 controllers。典型的操作流程大致如下:

\begin{onehalfspacing}
\begin{enumerate}
    \item 使用者建立一 resource,並在其 \verb|spec| 欄位描述需要的系統狀態
    \item kube-apiserver 通知相關 controller 有新的 resource 創立
    \item \verb|kube-apiserver| 通知相關 controller 有新的 resource 創立
    \item controller 根據 \verb|spec| 欄位進行操作,嘗試滿足 \verb|spec|,並將結果存入 \verb|status| 欄位
    \item kube-apiserver 通知使用者 resource 有所變更
    \item \verb|kube-apiserver| 通知使用者 resource 有所變更
    \item 使用者透過更新後的 \verb|status| 欄位得知操作結果
\end{enumerate}
\end{onehalfspacing}


@@ 27,7 27,7 @@ Kubernetes 提供 RESTful API 做為主要控制手段,以 resources 作為對
    \caption{Kubernetes 操作模型簡易示意圖}
\end{figure}

\noindent 這個架構使得 Kubernetes 在功能面上極易擴展,只須對 kube-apiserver 註冊一個新的 resource 種類,並且實做相關 controller 邏輯,便可以擴展 Kubernetes API。kube-apiserver 除了資料存儲以外,也包含了基本的資料驗證、身份驗證以及相關授權機制,使得 controller 能夠更專注於達成 resource 邏輯的實做,進一步減少擴展開發者的負擔。同時在 resource 本身的設計上,通常也會盡量使描述的操作是可以被重複執行的 (idempotent),令 controller 不須額外維護內部狀態 (stateless),簡化 controller 的部屬管理以及提高 controller 的容錯性,使整體系統更為易用且可靠。
\noindent 這個架構使得 Kubernetes 在功能面上極易擴展,只須對 \verb|kube-apiserver| 註冊一個新的 resource 種類,並且實做相關 controller 邏輯,便可以擴展 Kubernetes API。\verb|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 本身通常採用一個隨機的字串。由於目前實做上更動這份清單需要重新啟動 kube-apiserver,這個方法較少人採用。Webhook tokens 則是透過管理者提供的 HTTPS API 去將 token 對應到相關資訊,比 static tokens 來的有彈性,可以動態更動不須重啟 kube-apiserver。
其餘的手段皆是透過 token 進行身份驗證,但 token 本身有所不同。Static tokens 是在 Kubernetes 本身預先設定好一個 token 對應使用者名稱、所在群組的清單,token 本身通常採用一個隨機的字串。由於目前實做上更動這份清單需要重新啟動 \verb|kube-apiserver|,這個方法較少人採用。Webhook tokens 則是透過管理者提供的 HTTPS API 去將 token 對應到相關資訊,比 static tokens 來的有彈性,可以動態更動不須重啟 \verb|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 可以直接在 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 可以直接在 \verb|kube-apiserver| 上執行邏輯,省略了呼叫 HTTPS API 的網路溝通,減少造成的延遲影響與管理負擔,但能夠進行的操作受限於 Kubernetes 對其執行環境提供的函式庫。

\section{Helm}


M Sections/4.Architecture.tex => Sections/4.Architecture.tex +4 -2
@@ 68,7 68,7 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API,使
\subsection{PodTolerationRestriction}
\label{sec:PodTolerationRestriction}

在典型的 Kubernetes 叢集規劃下,節點分為兩大類:control plane 與 worker nodes。Control plane 負責運行叢集本身的元件,例如 kube-apiserver 與各式 controllers 等;而 worker nodes 負責運行一般的工作負載。Control plane 的元件通常也是以容器的形式部屬,而其節點也會納入叢集本身的管轄下,然而我們不希望 control plane 節點運行一般工作負載,避免影響到叢集控制邏輯的運行。Kubernetes 提供 taints 機制,用來標示 Node 的屬性,以及屬性應帶來的效果。以這個場景為例,我們標示這個 Node 為 control plane 並且不允許納入排程。此外,taints 機制同時也拿來自動標記異常的節點,例如節點資源即將耗盡的場景,並且藉此調整排程機制,優先使用其他節點。
在典型的 Kubernetes 叢集規劃下,節點分為兩大類:control plane 與 worker nodes。Control plane 負責運行叢集本身的元件,例如 \verb|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。



@@ 111,7 111,9 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API,使

實際上以 \verb|profile| 欄位而言,還有一個可行的方法,即是以 mutating admission control 層由叢集端判斷寫入,而不用仰賴網頁界面邏輯。這個方式目前有個缺點:admission control 邏輯我們希望透過 CEL 實做,而以 CEL 實做 mutating 雖然已有相關機制,現今仍未進入穩定狀態。另外,透過網頁界面預填也使得 admission control 層只須實做 validating,相對於 mutating,validating 因不能修改 resource 內容,較為單純且有平行化處理的空間,在效能與管理上皆有些許優勢。

對於管理需求,我們在 admission control 實做保留了彈性,若操作者為管理員即不加以限制。管理員可以自行創立代表他人的 User,為其修改身份組,提供人工處理政策上例外的空間。
對於管理需求,我們在 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 較為完整的測試環境。

\section{網頁界面實做}