Kubernetes 準(zhǔn)入控制器是集群管理必要功能。這些控制器主要在后臺(tái)工作，并且許多可以作為編譯插件使用，它可以極大地提高部署的安全性。

準(zhǔn)入控制器在 API 請(qǐng)求傳遞到 APIServer 之前攔截它們，并且可以禁止或修改它們。這適用于大多數(shù)類(lèi)型的 Kubernetes 請(qǐng)求。準(zhǔn)入控制器在經(jīng)過(guò)適當(dāng)?shù)纳矸蒡?yàn)證和授權(quán)后處理請(qǐng)求。

默認(rèn)情況下啟用了幾個(gè)準(zhǔn)入控制器，因?yàn)榇蠖鄶?shù)正常的 Kubernetes 操作都依賴(lài)于它們。這些控制器中的大多數(shù)都包含一些 Kubernetes 源代碼樹(shù)，并被編譯為插件。但是，也可以編寫(xiě)和部署第三方準(zhǔn)入控制器。一些說(shuō)明性示例將在稍后解決這個(gè)問(wèn)題。

準(zhǔn)入控制器工作原理

Kubernetes 控制平面由幾個(gè)組件組成。其中一個(gè)組件是 kube-apiserver，簡(jiǎn)單的 API server。它公開(kāi)了一個(gè) REST 端點(diǎn)，用戶(hù)、集群組件以及客戶(hù)端應(yīng)用程序可以通過(guò)該端點(diǎn)與集群進(jìn)行通信。總的來(lái)說(shuō)，它會(huì)進(jìn)行以下操作：

• 從客戶(hù)端應(yīng)用程序(如 kubectl)接收標(biāo)準(zhǔn) HTTP 請(qǐng)求。
• 驗(yàn)證傳入請(qǐng)求并應(yīng)用授權(quán)策略。
• 在成功的身份驗(yàn)證中，它能根據(jù)端點(diǎn)對(duì)象(Pod、Deployments、Namespace 等)和 http 動(dòng)作(Create、Put、Get、Delete 等)執(zhí)行操作。
• 對(duì) etcd 數(shù)據(jù)存儲(chǔ)進(jìn)行更改以保存數(shù)據(jù)。
• 操作完成，它就向客戶(hù)端發(fā)送響應(yīng)。

現(xiàn)在讓我們考慮這樣一種情況：在請(qǐng)求經(jīng)過(guò)身份驗(yàn)證后，但在對(duì) etcd 數(shù)據(jù)存儲(chǔ)進(jìn)行任何更改之前，我們需要攔截該請(qǐng)求。例如：

• 攔截客戶(hù)端發(fā)送的請(qǐng)求。
• 解析請(qǐng)求并執(zhí)行操作。
• 根據(jù)請(qǐng)求的結(jié)果，決定對(duì) etcd 進(jìn)行更改還是拒絕對(duì) etcd 進(jìn)行更改。

Kubernetes 準(zhǔn)入控制器就是用于這種情況的插件。在代碼層面，準(zhǔn)入控制器邏輯與 API server 邏輯解耦，這樣用戶(hù)就可以開(kāi)發(fā)自定義攔截器(custom interceptor)，無(wú)論何時(shí)對(duì)象被創(chuàng)建、更新或從 etcd 中刪除，都可以調(diào)用該攔截器。

有了準(zhǔn)入控制器，從任意來(lái)源到 API server 的請(qǐng)求流將如下所示：

根據(jù)準(zhǔn)入控制器執(zhí)行的操作類(lèi)型，它可以分為三種類(lèi)型：

• Mutating(變更)
• Validating(驗(yàn)證)
• Both(兩者都有)

Mutating：這種控制器可以解析請(qǐng)求，并在請(qǐng)求向下發(fā)送之前對(duì)請(qǐng)求進(jìn)行更改(變更請(qǐng)求)。

例如：AlwaysPullImages

Validating：這種控制器可以解析請(qǐng)求并根據(jù)特定數(shù)據(jù)進(jìn)行驗(yàn)證。

例如：NamespaceExists

Both：這種控制器可以執(zhí)行變更和驗(yàn)證兩種操作。

例如：CertificateSigning

默認(rèn)準(zhǔn)入控制器

Kubernetes 具有多個(gè)內(nèi)置準(zhǔn)入控制器。一個(gè)簡(jiǎn)單的例子，DefaultIngressClass將默認(rèn)入口類(lèi)應(yīng)用到還沒(méi)有指定類(lèi)的入口對(duì)象。同樣，DefaultStorageClass將默認(rèn)存儲(chǔ)類(lèi)應(yīng)用到PersistentVolumeClaims還沒(méi)有的存儲(chǔ)類(lèi)。必須啟用此控制器以允許基于存儲(chǔ)類(lèi)的動(dòng)態(tài)存儲(chǔ)配置。

準(zhǔn)入控制器在維護(hù)安全性方面非常有幫助。例如，它們可以減輕對(duì)多租戶(hù)集群的拒絕服務(wù) (DoS) 攻擊。考慮LimitRanger插件，顧名思義，它強(qiáng)制限制范圍。限制范圍以每個(gè)命名空間為基礎(chǔ)定義資源消耗的強(qiáng)制范圍。這可以防止租戶(hù)耗盡彼此的資源。

另一個(gè)問(wèn)題是所謂的事件泛濫，集群被事件淹沒(méi)，無(wú)法充分處理其他合法請(qǐng)求。對(duì)于EventRateLimit此類(lèi)情況，控制器是一種強(qiáng)大的緩解工具。它的設(shè)計(jì)使其能夠限制每個(gè)命名空間或每個(gè)用戶(hù)的事件發(fā)生率。

此外，還有兩個(gè)重要的控制器允許開(kāi)發(fā)人員將他們的準(zhǔn)入插件作為 webhook 運(yùn)行，以便在運(yùn)行時(shí)進(jìn)行配置。MutatingAdmissionWebhook使 webhook 能夠修改提交的資源，通常用于強(qiáng)制執(zhí)行自定義默認(rèn)值。同時(shí)，ValidatingAdmissionWebhook控制器啟用已注冊(cè)的 webhook 來(lái)決定處于最終狀態(tài)的 API 驗(yàn)證資源是繼續(xù)通過(guò)還是被完全丟棄。

第三方準(zhǔn)入控制器

Kubernetes 有兩個(gè)領(lǐng)先的開(kāi)源策略引擎：Open Policy Agent (OPA) Gatekeeper 和 Kyverno。

這兩個(gè)引擎都是對(duì)云原生計(jì)算基金會(huì) (CNCF) 的捐贈(zèng)，該基金會(huì)致力于云原生技術(shù)的標(biāo)準(zhǔn)化和推廣。它在其上級(jí)組織 Linux 基金會(huì)下運(yùn)作。值得注意的是，Kubernetes 是一個(gè) CNCF 項(xiàng)目。

Kyverno 的主要優(yōu)勢(shì)在于它不需要學(xué)習(xí)額外的語(yǔ)言。它的所有策略都定義為 Kubernetes 資源。相反，Gatekeeper 利用 OPA 的聲明性語(yǔ)言 Rego。Gatekeeper 是更大的 OPA 系統(tǒng)的一部分，而 Kyverno 是 Kubernetes 的獨(dú)立項(xiàng)目。總而言之，Gatekeeper 是更 成熟的項(xiàng)目，但 Kyverno 的學(xué)習(xí)曲線更小。

使用控制器的目的

在物理機(jī)上執(zhí)行多項(xiàng)服務(wù)的最初方法是讓虛擬機(jī)共享同一主機(jī)，并使用管理程序分隔它們的操作系統(tǒng)。一個(gè)復(fù)雜的云配置系統(tǒng)(例如，由 AWS 定義的那些)使系統(tǒng)保持獨(dú)立，并確保租戶(hù)不會(huì)意外或故意傷害彼此。

Kubernetes 最初被設(shè)計(jì)為單個(gè)組織或用戶(hù)可以使用的協(xié)作系統(tǒng)。此外，它比其他云系統(tǒng)之間的依賴(lài)更強(qiáng)。然而，隨著 Kubernetes 在可用部署的多樣性和處理更大集群規(guī)模的能力方面的增長(zhǎng)，制定確保單個(gè)用戶(hù)不會(huì)干擾系統(tǒng)操作的策略變得越來(lái)越重要。

為了使這個(gè)過(guò)程自動(dòng)化，組織需要一個(gè)策略系統(tǒng)。Kubernetes 具有一些內(nèi)置支持，但它不具備功能齊全的專(zhuān)用策略引擎的能力。

自定義準(zhǔn)入控制器

您可以使用 Webhook 使用任何可以處理 HTTP 請(qǐng)求并返回 Javascript 對(duì)象表示法 (JSON) 的語(yǔ)言來(lái)編寫(xiě)自定義準(zhǔn)入控制器邏輯。例如，Go、Python 或 Ruby 都是有效的選項(xiàng)。

下面的示例演示了如何為自定義準(zhǔn)入控制器設(shè)置 webhook。它類(lèi)似于上面介紹的 LimitRanger，它拒絕對(duì)超過(guò)資源命名空間限制的 Pod 的請(qǐng)求。

首先，使用配置對(duì)象注冊(cè) webhook：

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration
metadata:
  name: mywebhook
webhooks:
  - name: mywebhook
    clientConfig:
      service:
        name: mywebhook
        namespace: project1
        path: "/hook"
    rules:
      - operations: ["CREATE"]
        apiVersions: ["v1"]
        apiGroups: [""]
        resources: ["pods"]

這說(shuō)明 ValidatingWebhookController webhook。它還指定要訪問(wèn)的服務(wù)以及在運(yùn)行服務(wù)器的容器上探測(cè)的路徑。它還確定在決定是否調(diào)用 webhook 時(shí)要應(yīng)用哪些規(guī)則。此示例側(cè)重于創(chuàng)建新 pod。

實(shí)際上，在集群上創(chuàng)建此資源將在最后發(fā)生 - 在為 webhook 服務(wù)器創(chuàng)建部署之后。部署包含與上述文件中的定義匹配的服務(wù)：

apiVersion: v1
kind: Service
metadata:
  name: mywebhook
  namespace: project1
spec:
  - ports:
      name: mywebhook
      port: 80
      targetPort: 8000

下面是 webhook 的示例部署，與常規(guī)應(yīng)用程序沒(méi)有什么不同。我們不會(huì)探索使用傳輸層安全 (TLS) 來(lái)保護(hù)通信，但強(qiáng)烈建議這樣做。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mywebhook
  namespace: project1
spec:
  selector:
    matchLabels:
      app: mywebhook
  template:
    metadata:
      labels:
        app: mywebhook
    spec:
      containers:
        - image: webhook1:latest
          name: mywebhook

新的 Pod 請(qǐng)求提交給 Kubernetes 并通過(guò) Kubernetes 傳遞后ValidatingWebhook，相關(guān)信息會(huì)作為POST請(qǐng)求發(fā)送到配置的 URL 路徑，并包含一個(gè) JSON 對(duì)象供 webhook 處理。

驗(yàn)證是否正常工作

部署完 webhook 服務(wù)器并完成配置之后，我們還需要對(duì)它進(jìn)行測(cè)試和驗(yàn)證，

用 kubectl create -f examples/.yaml 創(chuàng)建 Pod。如果是前兩種情況，我們可以通過(guò)檢查日志來(lái)驗(yàn)證 Pod 運(yùn)行時(shí)的用戶(hù) ID，例如：

$ kubectl create -f examples/pod-test.yaml
$ kubectl logs pod-test

{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": {
    "uid": "6ce7a33c-ea67-40e5-9cc8-f710d31985dc",
    "allowed": true
  }
}

當(dāng)然我們也可以自定義更復(fù)雜的準(zhǔn)入控制器，明確某些 Pod 必須以非 root 身份運(yùn)行，如果不對(duì)，那么就可以拒絕對(duì)象創(chuàng)建請(qǐng)求。

自定義準(zhǔn)入控制器可以像這個(gè)示例一樣簡(jiǎn)單，也可以復(fù)雜得多。