## 1 要解決的問題

叢集分配給多個使用者使用時，需要使用配額以限制使用者的資源使用，包括 CPU 核數、記憶體大小、GPU 卡數等，以防止資源被某些使用者耗盡，造成不公平的資源分配。

大多數情況下，叢集原生的 `ResourceQuota` 機制可以很好地解決問題。但隨著叢集規模擴大，以及任務型別的增多，我們對配額管理的規則需要進行調整：

- `ResourceQuota` 針對單叢集設計，但實際上，開發/生產中經常使用 **多叢集** 環境。
- 叢集大多數任務透過比如`deployment`、`mpijob` 等 **高階資源物件** 進行提交，我們希望在高階資源物件的 **提交階段** 就能對配額進行判斷。但 `ResourceQuota` 計算資源請求時以 `pod` 為粒度，從而無法滿足此需求。

基於以上問題，我們需要自行進行配額管理。而 Kubernetes 提供了動態准入的機制，允許我們編寫自定義的外掛，以實現請求的准入。我們的配額管理方案，就以此入手。

## 2 叢集動態准入原理

進入 K8s 叢集的請求，被 API server 接收後，會經過如下幾個順序執行的階段：

1. 認證/鑑權
2. 准入控制（變更）
3. 格式驗證
4. 准入控制（驗證）
5. 持久化

請求在上述前四個階段都會被相應處理，並且依次被判斷是否允許透過。各個階段都透過後，才能夠被持久化，即存入到 etcd 資料庫中，從而變為一次成功的請求。其中，在 **准入控制（變更）** 階段，`mutating admission webhook` 會被呼叫，可以修改請求中的內容。而在 **准入控制（驗證）** 階段，`validating admission webhook` 會被呼叫，可以校驗請求內容是否符合某些要求，從而決定是否允許或拒絕該請求。而這些 `webhook` 支援擴充套件，可以被獨立地開發和部署到叢集中。

雖然，在 **准入控制（變更）** 階段，`webhook`也可以檢查和拒絕請求，但其被呼叫的次序無法保證，無法限制其它 `webhook` 對請求的資源進行修改。因此，我們部署用於配額校驗的 `validating admission webhook`，配置於 **准入控制（驗證）** 階段呼叫，進行請求資源的檢查，就可以實現資源配額管理的目的。

## 3 方案

### 3.1 如何在叢集中部署校驗服務

在 K8s 叢集中使用自定義的 `validating admission webhook` 需要部署：

1. `ValidatingWebhookConfiguration` 配置（需要叢集啟用 ValidatingAdmissionWebhook） ，用於定義要對何種資源物件（`pod`, `deployment`, `mpijob` 等）進行校驗，並提供用於實際處理校驗的服務回撥地址。推薦使用在叢集內配置 `Service` 的方式來提供校驗服務的地址。
2. 實際處理校驗的服務，透過在 `ValidatingWebhookConfiguration` 配置的地址可訪問即可。

單叢集環境中，將校驗服務以 `deployment` 的方式在叢集中部署。多叢集環境中，可以選擇：

1. 使用 virtual kubelet，cluster federation 等方案將多叢集合併為單叢集，從而退化為採用單叢集方案部署。
2. 將校驗服務以 `deloyment` 的方式部署於一個或多個叢集中，但要注意保證服務到各個叢集網路連通。

需要注意的是，不論是單叢集還是多叢集的環境中，處理校驗的服務都需要進行資源監控，這一般由單點實現。因此都需要 進行選主。

### 3.2 如何實現校驗服務

#### 3.2.1 校驗服務架構設計

##### 3.2.1.1 基本元件構成

![](https://main.qcloudimg.com/raw/681444356fc4cb1a4639b094e2aeaee2.png)

- **API server**：叢集請求入口，呼叫 `validating admission webhook` 以驗證請求
- **API**：准入服務介面，使用叢集約定的 AdmissionReview 資料結構作為請求和返回
- **Quota usage service**：請求資源使用量介面
- **Admissions**：准入服務實現，包括 `deployment` 和 `mpijob` 等不同資源型別准入
- **Resource validator**：對資源請求進行配額校驗
- **Quota adapter**：對接外部配額服務供 validator 查詢
- **Resource usage manager**：資源使用管理器，維護資源使用情況，實現配額判斷
- **Informers**：透過 K8s 提供的 watch 機制監控叢集中資源，包括 `deployment` 和 `mpijob` 等，以維護當前資源使用
- **Store**：存放資源使用資料，可以對接服務本地記憶體實現，或者對接 Redis 服務實現

##### 3.2.1.2 資源配額判斷的基本流程

以使用者建立 `deployment` 資源為例：

1. 使用者建立 `deployment` 資源，定義中需要包含指定了應用組資訊的 `annotation`，比如 `ti.cloud.tencent.com/group-id: 1`，表示申請使用應用組 `1` 中的資源（如果沒有帶有應用組資訊，則根據具體場景，直接拒絕，或者提交到預設的應用組，比如應用組 `0` 等）。
2. 請求由 **API server** 收取，由於在叢集中正確配置了 `ValidatingWebhookConfiguration`，因此在准入控制的驗證階段，會請求叢集中部署的 `validating admission webhook` 的 **API**，使用 K8s 規定的結構體`AdmissionReviewRequest` 作為請求，期待 `AdmissionReviewResponse` 結構體作為返回。
3. 配額校驗服務收到請求後，會進入負責處理 `deployment` 資源的 **admission** 的邏輯，根據改請求的動作是 CREATE 或 UPDATE 來計算出此次請求需要新申請或者釋放的資源。
4. 從 `deployment` 的 `spec.template.spec.containers[*].resources.requests` 欄位中提取要申請的資源，比如為 `cpu: 2` 和 `memory: 1Gi`，以 *apply* 表示。
5. **Resource validator** 查詢 **quota adapter** 獲取應用組 `1` 的配額資訊，比如 `cpu: 10` 和 `memory: 20Gi` ，以 *quota* 表示。連同上述獲取的 *apply*，向 **resource usage manager** 申請資源。
6. **Resource usage manager** 一直在透過 **informer** 監控獲取 `deployment` 的資源使用情況，並維護在 **store** 中。**Store** 可以使用本地記憶體，從而無外部依賴。或者使用 `Redis` 作為儲存介質，方便服務水平擴充套件。
7. **Resource usage manager** 收到 **resource validator** 的請求時，可以透過 **store** 查到應用組 `1` 當前已經佔用的資源情況，比如 `cpu: 8` 和 `memory: 16Gi`，以 *usage* 表示。檢查發現 *apply* + *usage* <= *quota* 則認為沒有超過配額，請求透過，並最終返回給 **API server**。

以上就是實現資源配額檢查的基本流程。有一些細節值得補充說明：

- 校驗服務的介面 **API** 必須採用 https 暴露服務。
- 針對不用的資源型別，比如 `deployment`、`mpijob` 等，都需要實現相應的 **admission** 以及 **informer** 。
- 每個資源型別可能有不同的版本，比如 `deployment` 有 `apps/v1`、`apps/v1beta1` 等，需要根據叢集的實際情況相容處理。
- 收到 UPDATE 請求時，需要根據資源型別中 `pod` 的欄位是否變化，來判斷是否需要重建當前已有的 `pod` 例項，以正確計算資源申請的數目。
- 除了 K8s 自帶的資源型別，比如 `cpu` 等，如果還需要自定義的資源型別配額控制，比如 GPU 型別等，需要在資源請求約定好相應的 `annotations`，比如 `ti.cloud.tencent.com/gpu-type: V100`
- 在 **resource usage manager** 進行使用量、申請量和配額的判斷過程中，可能會出現 **資源競爭**、配額透過校驗但實際 **資源建立失敗** 等問題。接下來我們會對這兩個問題進行解釋。

#### 3.2.2 關於資源申請競爭

由於併發資源請求的存在：

1. *usage* 需要能夠被在資源請求後即時更新
2. *usage* 的更新需要進行併發控制

在上述步驟 7 中，**Resource usage manager** 校驗配額時，需要查詢應用組當前的資源佔用情況，即應用組的 *usage* 值。此 *usage* 值由 **informers** 負責更新和維護，但由於從資源請求被 `validating admission webhook` 透過，到 **informer** 能夠觀察到，存在時間差。這個過程中，可能仍有資源請求，那麼 *usage* 值就是不準確的了。因此，*usage* 需要能夠被在資源請求後即時更新。

並且對 *usage* 的更新需要進行併發控制，舉個例子：

1. 應用組 `2` 的 *quota* 為 `cpu: 10`，*usage* 為 `cpu: 8`
2. 進入兩個請求 `deployment1` 和 `deployment2` 申請使用應用組 `2`，它們的 *apply* 同為 `cpu: 2`
3. 需要首先判斷 `deployment1`， 計算 *apply* + *usage* = `cpu: 10`，未超過 *quota* 值，因此 `deployment1` 的請求允許透過。
4. *usage* 被更新為 `cpu: 10`
5. 再去判斷 `deployment2`，由於 *usage* 被更新為 `cpu: 10`，則算出 *apply* + *usage* = `cpu: 12`，超過了 *quota* 的值，因此不允許透過該請求。

上述過程中，容易發現 *usage* 是關鍵的 **共享** 變數，需要順序查詢和更新。若 `deployment1` 和 `deployment2` 不加控制地同時使用 *usage* 為 `cpu: 8`，就會導致 `deployment1` 和 `deployment2` 請求都被透過，從而實際超出了配額限制。這樣，使用者可能佔用 **超過** 配額規定的資源。

可行的解決辦法：

- 資源申請進入佇列，由單點的服務依次消費和處理。
- 將共享的變數 *usage* 所處的臨界區上鎖，在鎖內查詢和更新 *usage* 的值。

#### 3.2.3 關於資源建立失敗

由於資源競爭的問題，我們要求 *usage* 需要能夠被在資源請求後即時更新，但這也帶來新的問題。在 **4. 准入控制（驗證）** 階段之後，請求的資源物件會進入 **5. 持久化** 階段，這個過程中也可能出現異常（比如其他的 `webhook` 又拒絕了該請求，或者叢集斷電，etcd 故障等）導致任務沒有實際提交成功到叢集資料庫。在這種情況下，我們在 **驗證** 階段，已經增加了 *usage* 的值，就把沒有實際佔用配額的任務算作佔用了配額。這樣，使用者可能佔用 **不足** 配額規定的資源。

為了解決這個問題，後臺服務會定時全域性更新每個應用組的 *usage* 值。這樣，如果出現了 **驗證** 階段增加了 *usage* 值，但任務實際提交到資料庫失敗的情況，在全域性更新的時候，*usage* 值最終會重新更新為那個時刻應用組在叢集內資源使用的準確值。

> 但在極少數情況下，全域性更新會在這種時刻發生：某最終會成功存入 etcd **持久化** 的資源物件建立請求，已經透過 `webhook` **驗證**，但尚未完成 **持久化** 的時刻。這種時刻的存在，導致全域性更新依然會帶來使用者佔用 **超過** 配額的問題。
> 比如，在之前的例子中，`deployment1` 更新了 *usage* 值之後，恰巧發生了全域性更新。此時 `deployment1` 的資訊恰好尚未存入 etcd，所以全域性更新會把 *usage* 重新更新為舊值，這樣會導致 `dployment2` 也能被透過，從而超過了配額限制。
> 但通常，從 **驗證** 到 **持久化** 的時間很短。**低頻** 的全域性更新情況下，此種情況 **幾乎不會發生**。後續，如果有進一步的需求，可以採用更復雜的方案來規避這個問題。

#### 3.2.3 原生 `ResourceQuota` 的工作方式

K8s 叢集中原生的配額管理 `ResourceQuota` 針對上述 **資源申請競爭** 和 **資源建立失敗** 問題，採用了類似的解決方案：

**即時更新解決申請競爭問題**

檢查完配額後，即時更新資源用量，K8s 系統自帶的樂觀鎖保證併發的資源控制（詳見 K8s 原始碼中 [checkQuotas](https://github.com/kubernetes/kubernetes/blob/e7b9453972eccaa57d18dfb7024b017b97de0b26/staging/src/k8s.io/apiserver/pkg/admission/plugin/resourcequota/controller.go#L215) 的實現），解決資源競爭問題。

`checkQuotas` 中最相關的原始碼解讀：

```go
// now go through and try to issue updates.  Things get a little weird here:
// 1. check to see if the quota changed.  If not, skip.
// 2. if the quota changed and the update passes, be happy
// 3. if the quota changed and the update fails, add the original to a retry list
var updatedFailedQuotas []corev1.ResourceQuota
var lastErr error
for i := range quotas {
    newQuota := quotas[i]
    // if this quota didn't have its status changed, skip it
    if quota.Equals(originalQuotas[i].Status.Used, newQuota.Status.Used) {
        continue
    }
    if err := e.quotaAccessor.UpdateQuotaStatus(&newQuota); err != nil {
        updatedFailedQuotas = append(updatedFailedQuotas, newQuota)
        lastErr = err
    }
}
```

這裡 `quotas` 是經過校驗後的配額資訊，其中 `newQuota.Status.Used` 欄位則記錄了該配額的資源使用情況。如果針對該配額的資源請求透過了，執行到這段程式碼時，`Used` 欄位中已經被加上了新申請資源的量。隨後，`Equals` 函式被呼叫，即如果 `Used` 欄位未變，說明沒有新的資源申請。否則，就會執行到 `e.quotaAccessor.UpdateQuotaStatus`，立刻去把 etcd 中的配額資訊按照 `newQuota.Status.Used` 來更新。

**定時全域性更新解決建立失敗問題**

定時全域性更新資源使用量（詳見 K8s 原始碼中 [Run](https://github.com/kubernetes/kubernetes/blob/1cd2ed816a5c22a621c5ea59b906834c7f145301/pkg/controller/resourcequota/resource_quota_controller.go#L290) 的實現），解決可能的資源建立失敗問題 。

`Run` 中最相關的原始碼解讀：

```go
// the timer for how often we do a full recalculation across all quotas
go wait.Until(func() { rq.enqueueAll() }, rq.resyncPeriod(), stopCh)
```

這裡 `rq` 為 `ResourceQuota` 物件對應 controller 的自引用。這個 Controller 執行 `Run` 迴圈，持續地控制所有 `ResourceQuota` 物件。迴圈中，不間斷定時呼叫 `enqueueAll`，即把所有的 `ResourceQuota` 壓入佇列中，修改其 `Used` 值，進行全域性更新。

------

## 4 參考

- [Controlling Access to the Kubernetes API](https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/)
- [Dynamic Admission Control](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)
- [A Guide to Kubernetes Admission Controllers](https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/)
- [深入理解 Kubernetes Admission Webhook](https://www.qikqiak.com/post/k8s-admission-webhook/)
- https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/main.go
- [Admission Webhooks: Configuration and Debugging Best Practices - Haowei Cai, Google](https://www.youtube.com/watch?v=r_v07P8Go6w&ab_channel=CNCF[CloudNativeComputingFoundation])

使用 Admission Webhook 機制實現多叢集資源配額控制

相關文章