帶你讀《雲原生應用開發 Operator原理與實踐》第二章 Operator 原理2.3 Kube-APIServer 介紹（一）

Kube-APIServer元件負責對外暴露資源的API，也包括自定義資源。外部通路和操作 Kubernetes 資源會經過哪些流程呢？下面介紹 KubernetesAPI 的通路控制。

2.3.1        KubernetesAPI 通路控制

在Kubernetes叢集中，Kube-APIServer是控制面的一個元件，它對外暴露Kubernetes的 API，通常這個服務使用6443端口。叢集控制面之外的元件要通路這個服務有兩種情況。

（1）  使用者可以使用 Kubectl、用戶端庫或 REST風格的請求去通路 Kube-APIServer。

（2）  使用者運作在叢集中的服務使用 ServiceAccount去通路Kube-APIServer。一個請求到達API要經過多個階段，如圖 2-9所示。

圖 2—9KubernetesAP請求處理步驟

1. 認證

如圖 2-9中的步驟①，用戶端（Kubectl工具、REST請求或叢集中的 Pod等）在叢集内應用通路Kube-APIServer的HTTP請求首先會進入認證這步。我們在建立叢集時可以配置一個或者多個認證子產品。

認證子產品的工作過程：請求會依次通過每個認證子產品，隻要有一個子產品通過則進入下一步。如果所有的認證子產品都沒有通過，就會給用戶端傳回一個 401的 HTTP狀态碼。認證通過後會解析認證資訊中對應的使用者，這個使用者會作為後續步驟決策的依據。

需要注意的是，雖然Kubernetes通過使用者來對通路Kube-APIServer的請求進行通路控制決策和通路日志記錄，但 Kubernetes中沒有使用者這個對象，也沒有在API中存儲使用者和使用者相關的資訊。

2. 鑒權

圖2-9中的步驟②是根據上一步的使用者對請求進行鑒權操作。鑒權過程是判斷目前使用者是否有權限去操作 HTTP 請中的資源對象，判斷的依據是存儲在叢集中的政策聲明。Kubernetes中支援多種鑒權子產品，比如 ABAC、RBAC和 WebHook。鑒權子產品是在建立叢集時配置的，如果配置了多種鑒權子產品，Kubernetes     會檢查每個子產品。如果有一個子產品通過鑒權，那麼該請求鑒權通過；如果所有的子產品都拒絕了該請求，就會給用戶端傳回一個 403的 HTTP狀态碼。

3. 準入控制

請求經過認證和鑒權之後會被準入控制器攔截，如圖2-9中的步驟③所示，準入控制器可以修改或拒絕請求。準入控制器隻對建立、修改或删除對象的請求起作用，對隻讀請求不起作用。當配置了多個準入控制器時，會按照順序進行調用。

與認證或鑒權子產品不同的是，如果有任何一個準入控制器拒絕了請求，那麼請求會立馬被其他準入控制器拒絕。除了拒絕請求之外，準入控制器還可以為請求中的字段設定一些預設值。

一旦請求通過所有的準入控制器，就會使用相應的驗證邏輯對 API對象進行驗證，之後會将對象寫入存儲中，即圖2-9中的步驟④。