本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes 1.26：介紹驗證性准入策略

作者：Joe Betz (Google), Cici Huang (Google) |

在 Kubernetes 1.26 中，驗證性准入策略的第一個 Alpha 版本已可用！

驗證性准入策略使用通用表示式語言 (Common Expression Language, CEL) 來為驗證性准入 Webhook 提供一種宣告式的、程序內的替代方案。

CEL 最初被引入 Kubernetes 是用於CustomResourceDefinitions 的驗證規則。此增強功能擴充套件了 CEL 在 Kubernetes 中的使用，以支援更廣泛的准入場景。

准入 Webhook 的開發和運維可能很繁瑣。Webhook 開發者必須實現並維護一個 Webhook 二進位制檔案來處理准入請求。此外，准入 Webhook 的運維也很複雜。每個 Webhook 都必須被部署、監控，並有明確的升級和回滾計劃。更糟糕的是，如果 Webhook 超時或不可用，Kubernetes 控制平面可能會變得不可用。此增強功能透過將 CEL 表示式嵌入到 Kubernetes 資源中，而不是呼叫遠端的 Webhook 二進位制檔案，從而避免了准入 Webhook 的大部分複雜性。

例如，要限制 Deployment 可以擁有的副本數量。首先定義一個驗證策略

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicy
metadata:
  name: "demo-policy.example.com"
spec:
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
    - expression: "object.spec.replicas <= 5"

expression 欄位包含用於驗證准入請求的 CEL 表示式。matchConstraints 聲明瞭此 ValidatingAdmissionPolicy 可能驗證的請求型別。

接下來將策略繫結到適當的資源

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "demo-binding-test.example.com"
spec:
  policyName: "demo-policy.example.com"
  matchResources:
    namespaceSelector:
      matchExpressions:
      - key: environment
        operator: In
        values:
        - test

此 ValidatingAdmissionPolicyBinding 資源僅將上述策略繫結到 environment 標籤被設定為 test 的名字空間。一旦此繫結被建立，kube-apiserver 將開始強制執行此准入策略。

為了強調這種方法比准入 Webhook 簡單多少，如果這個例子改用 Webhook 實現，就需要開發和維護一整個二進位制檔案，只為了執行一個 <= 檢查。在我們對生產環境中使用的各種准入 Webhook 的審查中，絕大多數執行的都是相對簡單的檢查，所有這些都可以很容易地使用 CEL 來表達。

驗證性准入策略是高度可配置的，使策略作者能夠定義可被引數化並根據叢集管理員的需要限定於特定資源的策略。

例如，可以修改上述准入策略使其可配置

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicy
metadata:
  name: "demo-policy.example.com"
spec:
  paramKind:
    apiVersion: rules.example.com/v1 # You also need a CustomResourceDefinition for this API
    kind: ReplicaLimit
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
    - expression: "object.spec.replicas <= params.maxReplicas"

在這裡，paramKind 定義了用於配置策略的資源，並且 expression 使用 params 變數來訪問引數資源。

這允許多個繫結被定義，每個繫結的配置都不同。例如

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "demo-binding-production.example.com"
spec:
  policyName: "demo-policy.example.com"
  paramRef:
    name: "demo-params-production.example.com"
  matchResources:
    namespaceSelector:
      matchExpressions:
      - key: environment
        operator: In
        values:
        - production

apiVersion: rules.example.com/v1 # defined via a CustomResourceDefinition
kind: ReplicaLimit
metadata:
  name: "demo-params-production.example.com"
maxReplicas: 1000

這個繫結和引數資源對將 environment 標籤設定為 production 的名字空間中的 Deployment 副本數限制為最多 1000 個。

然後你可以使用一個單獨的繫結和引數對為 test 環境中的名字空間設定不同的限制。

我希望這讓你對驗證性准入策略的可能性有了一個初步的瞭解！我們還有很多特性尚未提及。

要了解更多資訊，請閱讀驗證性准入策略。

我們正在努力為準入策略新增更多功能，並使該增強功能更易於使用。請試用它，向我們傳送你的反饋，並幫助我們構建一個更簡單的准入 Webhook 替代方案！

我如何參與？

如果你想參與准入策略的開發，討論增強功能的路線圖，或報告錯誤，你可以在 SIG API Machinery 與開發者聯絡。