Kubernetes 中的准入控制

本頁面提供了_准入控制器_的概覽。

准入控制器是一段程式碼,它在資源持久化之前,但在請求經過身份驗證和授權之後,攔截對 Kubernetes API 伺服器的請求。

Kubernetes 的幾個重要功能需要啟用准入控制器才能正確支援這些功能。因此,沒有正確配置相應准入控制器的 Kubernetes API 伺服器是不完整的伺服器,它將不支援你期望的所有功能。

它們是什麼?

准入控制器是 Kubernetes API 伺服器中的程式碼,用於檢查修改資源請求中傳入的資料。

准入控制器適用於建立、刪除或修改物件的請求。准入控制器還可以阻止自定義動詞,例如透過 API 伺服器代理連線到 Pod 的請求。准入控制器_不會_(也無法)阻止讀取(**get**、**watch** 或 **list**)物件的請求,因為讀取繞過了准入控制層。

准入控制機制可以是_驗證_、_修改_或兩者兼有。修改型控制器可以修改正在修改資源的資料;驗證型控制器則不能。

Kubernetes 1.34 中的准入控制器由以下列表組成,它們被編譯到 `kube-apiserver` 二進位制檔案中,並且只能由叢集管理員配置。

准入控制擴充套件點

在完整的列表中,有三個特殊的控制器:MutatingAdmissionWebhookValidatingAdmissionWebhookValidatingAdmissionPolicy。這兩個 Webhook 控制器分別執行在 API 中配置的修改型和驗證型准入控制 Webhook。ValidatingAdmissionPolicy 提供了一種在 API 中嵌入宣告性驗證程式碼的方法,而無需依賴任何外部 HTTP 呼叫。

你可以使用這三個准入控制器在准入時自定義叢集行為。

准入控制階段

准入控制過程分兩個階段進行。第一階段執行修改型准入控制器。第二階段執行驗證型准入控制器。請再次注意,有些控制器兩者兼有。

如果任何階段中的任何控制器拒絕了請求,則整個請求將立即被拒絕,並向終端使用者返回錯誤。

最後,除了有時會修改物件之外,准入控制器有時還可能產生副作用,即作為請求處理的一部分修改相關資源。增加配額使用量是說明這種必要性的典型例子。任何此類副作用都需要相應的回收或協調過程,因為給定的准入控制器不能確定給定請求將透過所有其他准入控制器。

這些呼叫的順序如下所示。

Sequence diagram for kube-apiserver handling requests during the admission phase showing mutation webhooks, followed by validatingadmissionpolicies and finally validating webhooks. It shows that the continue until the first rejection, or being accepted by all of them. It also shows that mutations by mutating webhooks cause all previously called webhooks to be called again.

為什麼我需要它們?

Kubernetes 的幾個重要功能需要啟用准入控制器才能正確支援這些功能。因此,沒有正確配置相應准入控制器的 Kubernetes API 伺服器是不完整的伺服器,它將不支援你期望的所有功能。

如何啟用准入控制器?

Kubernetes API 伺服器標誌 `enable-admission-plugins` 接受一個逗號分隔的准入控制外掛列表,以便在修改叢集中的物件之前呼叫這些外掛。例如,以下命令列啟用了 `NamespaceLifecycle` 和 `LimitRanger` 准入控制外掛。

kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...

如何關閉准入控制器?

Kubernetes API 伺服器標誌 `disable-admission-plugins` 接受一個逗號分隔的准入控制外掛列表,即使它們在預設啟用的外掛列表中,也會被停用。

kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...

哪些外掛預設啟用?

要檢視哪些准入外掛已啟用

kube-apiserver -h | grep enable-admission-plugins

在 Kubernetes 1.34 中,預設外掛是

CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, PodSecurity, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook

每個准入控制器有什麼作用?

AlwaysAdmit

特性狀態: Kubernetes v1.13 [已棄用]

**型別**:驗證型。

此准入控制器允許所有 Pod 進入叢集。它已**棄用**,因為其行為與根本沒有準入控制器相同。

AlwaysDeny

特性狀態: Kubernetes v1.13 [已棄用]

**型別**:驗證型。

拒絕所有請求。AlwaysDeny 已**棄用**,因為它沒有實際意義。

AlwaysPullImages

**型別**:修改型和驗證型。

此准入控制器修改每個新的 Pod,強制其映象拉取策略為 `Always`。這在多租戶叢集中很有用,這樣使用者就可以確保他們的私有映象只能由擁有拉取憑據的人使用。如果沒有此准入控制器,一旦映象被拉取到節點上,任何使用者建立的任何 Pod 都可以透過知道映象名稱(假設 Pod 被排程到正確的節點)來使用它,而無需對映象進行任何授權檢查。啟用此准入控制器後,在啟動容器之前總是會拉取映象,這意味著需要有效的憑據。

CertificateApproval

**型別**:驗證型。

此准入控制器觀察批准 CertificateSigningRequest 資源的請求,並執行額外的授權檢查,以確保批准使用者擁有**批准** CertificateSigningRequest 資源上請求的 `spec.signerName` 證書請求的許可權。

有關執行 CertificateSigningRequest 資源上的不同操作所需的許可權的更多資訊,請參閱證書籤名請求

CertificateSigning

**型別**:驗證型。

此准入控制器觀察對 CertificateSigningRequest 資源的 `status.certificate` 欄位的更新,並執行額外的授權檢查,以確保簽名使用者擁有**簽名** CertificateSigningRequest 資源上請求的 `spec.signerName` 證書請求的許可權。

有關執行 CertificateSigningRequest 資源上的不同操作所需的許可權的更多資訊,請參閱證書籤名請求

CertificateSubjectRestriction

**型別**:驗證型。

此准入控制器觀察建立 `spec.signerName` 為 `kubernetes.io/kube-apiserver-client` 的 CertificateSigningRequest 資源。它拒絕任何指定 `system:masters` '組'(或'組織屬性')的請求。

DefaultIngressClass

**型別**:修改型。

此准入控制器觀察不請求任何特定 Ingress 類的 `Ingress` 物件的建立,並自動為其新增預設 Ingress 類。這樣,不請求任何特殊 Ingress 類的使用者無需關心它們,他們將獲得預設的 Ingress 類。

當沒有配置預設 Ingress 類時,此准入控制器不執行任何操作。當有多個 Ingress 類被標記為預設時,它會拒絕任何 `Ingress` 的建立並返回錯誤,管理員必須重新檢查其 `IngressClass` 物件,並只將一個標記為預設(使用註解 "ingressclass.kubernetes.io/is-default-class")。此准入控制器忽略任何 `Ingress` 更新;它僅在建立時起作用。

有關 Ingress 類以及如何將一個標記為預設的更多資訊,請參閱Ingress 文件。

DefaultStorageClass

**型別**:修改型。

此准入控制器觀察不請求任何特定儲存類的 `PersistentVolumeClaim` 物件的建立,並自動為其新增預設儲存類。這樣,不請求任何特殊儲存類的使用者無需關心它們,他們將獲得預設的儲存類。

當不存在預設 `StorageClass` 時,此准入控制器不執行任何操作。當有多個儲存類被標記為預設時,並且你建立一個沒有設定 `storageClassName` 的 `PersistentVolumeClaim`,Kubernetes 會使用最近建立的預設 `StorageClass`。當建立一個指定了 `volumeName` 的 `PersistentVolumeClaim` 時,如果靜態卷的 `storageClassName` 與應用了任何預設 StorageClass 後的 `PersistentVolumeClaim` 上的 `storageClassName` 不匹配,它將保持掛起狀態。此准入控制器忽略任何 `PersistentVolumeClaim` 更新;它僅在建立時起作用。

有關持久卷宣告和儲存類以及如何將儲存類標記為預設的更多資訊,請參閱持久卷文件。

DefaultTolerationSeconds

**型別**:修改型。

如果 Pod 尚未對 `node.kubernetes.io/not-ready:NoExecute` 或 `node.kubernetes.io/unreachable:NoExecute` 汙點設定容忍,此准入控制器根據 k8s-apiserver 輸入引數 `default-not-ready-toleration-seconds` 和 `default-unreachable-toleration-seconds` 為 Pod 設定預設寬恕容忍,以容忍 `notready:NoExecute` 和 `unreachable:NoExecute` 汙點。`default-not-ready-toleration-seconds` 和 `default-unreachable-toleration-seconds` 的預設值為 5 分鐘。

DenyServiceExternalIPs

**型別**:驗證型。

此准入控制器拒絕所有新增的 `Service` 欄位 `externalIPs` 的使用。此功能非常強大(允許網路流量攔截),並且沒有得到很好的策略控制。啟用後,叢集使用者不得建立使用 `externalIPs` 的新 Service,也不得向現有 `Service` 物件上的 `externalIPs` 新增新值。現有 `externalIPs` 的使用不受影響,使用者可以從現有 `Service` 物件上的 `externalIPs` 中刪除值。

大多數使用者根本不需要此功能,叢集管理員應考慮停用它。確實需要使用此功能的叢集應考慮使用一些自定義策略來管理其使用。

此准入控制器預設停用。

EventRateLimit

特性狀態: Kubernetes v1.13 [alpha]

**型別**:驗證型。

此准入控制器可緩解 API 伺服器被大量儲存新事件的請求淹沒的問題。叢集管理員可以透過以下方式指定事件速率限制:

  • 啟用 `EventRateLimit` 准入控制器;
  • 從提供給 API 伺服器命令列標誌 `---admission-control-config-file` 的檔案中引用 `EventRateLimit` 配置檔案
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: EventRateLimit
    path: eventconfig.yaml
...

配置中可以指定四種類型的限制

  • `Server`:API 伺服器收到的所有事件請求(建立或修改)共享一個桶。
  • `Namespace`:每個名稱空間有一個專用的桶。
  • `User`:每個使用者分配一個桶。
  • `SourceAndObject`:根據事件的來源和涉及物件的每個組合分配一個桶。

下面是一個此類配置的示例 `eventconfig.yaml`

apiVersion: eventratelimit.admission.k8s.io/v1alpha1
kind: Configuration
limits:
  - type: Namespace
    qps: 50
    burst: 100
    cacheSize: 2000
  - type: User
    qps: 10
    burst: 50

有關更多詳細資訊,請參閱EventRateLimit Config API (v1alpha1)

此准入控制器預設停用。

ExtendedResourceToleration

**型別**:修改型。

此外掛有助於建立帶有擴充套件資源的專用節點。如果操作員希望建立帶有擴充套件資源(如 GPU、FPGA 等)的專用節點,他們應該將擴充套件資源名稱作為鍵汙點節點。如果啟用此准入控制器,它會自動為請求擴充套件資源的 Pod 新增此類汙點的容忍度,因此使用者不必手動新增這些容忍度。

此准入控制器預設停用。

ImagePolicyWebhook

**型別**:驗證型。

ImagePolicyWebhook 准入控制器允許後端 Webhook 做出准入決策。

此准入控制器預設停用。

配置檔案格式

ImagePolicyWebhook 使用配置檔案來設定後端行為的選項。此檔案可以是 json 或 yaml 格式,具有以下結構:

imagePolicy:
  kubeConfigFile: /path/to/kubeconfig/for/backend
  # time in s to cache approval
  allowTTL: 50
  # time in s to cache denial
  denyTTL: 50
  # time in ms to wait between retries
  retryBackoff: 500
  # determines behavior if the webhook backend fails
  defaultAllow: true

從提供給 API 伺服器命令列標誌 `---admission-control-config-file` 的檔案中引用 ImagePolicyWebhook 配置檔案

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook
    path: imagepolicyconfig.yaml
...

或者,你可以直接將配置嵌入到檔案中

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook
    configuration:
      imagePolicy:
        kubeConfigFile: <path-to-kubeconfig-file>
        allowTTL: 50
        denyTTL: 50
        retryBackoff: 500
        defaultAllow: true

ImagePolicyWebhook 配置檔案必須引用一個kubeconfig 格式的檔案,該檔案用於設定與後端的連線。要求後端透過 TLS 進行通訊。

kubeconfig 檔案的 `cluster` 欄位必須指向遠端服務,`user` 欄位必須包含返回的授權者。

# clusters refers to the remote service.
clusters:
  - name: name-of-remote-imagepolicy-service
    cluster:
      certificate-authority: /path/to/ca.pem    # CA for verifying the remote service.
      server: https://images.example.com/policy # URL of remote service to query. Must use 'https'.

# users refers to the API server's webhook configuration.
users:
  - name: name-of-api-server
    user:
      client-certificate: /path/to/cert.pem # cert for the webhook admission controller to use
      client-key: /path/to/key.pem          # key matching the cert

有關其他 HTTP 配置,請參閱kubeconfig 文件。

請求負載

當面臨准入決策時,API 伺服器將 POST 一個 JSON 序列化的 `imagepolicy.k8s.io/v1alpha1` `ImageReview` 物件,描述該操作。此物件包含描述正在准入的容器以及匹配 `*.image-policy.k8s.io/*` 的任何 Pod 註解的欄位。

一個示例請求正文

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "spec": {
    "containers": [
      {
        "image": "myrepo/myimage:v1"
      },
      {
        "image": "myrepo/myimage@sha256:beb6bd6a68f114c1dc2ea4b28db81bdf91de202a9014972bec5e4d9171d90ed"
      }
    ],
    "annotations": {
      "mycluster.image-policy.k8s.io/ticket-1234": "break-glass"
    },
    "namespace": "mynamespace"
  }
}

遠端服務應填寫請求的 `status` 欄位並響應以允許或拒絕訪問。響應正文的 `spec` 欄位被忽略,可以省略。一個允許的響應將返回

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "status": {
    "allowed": true
  }
}

要拒絕訪問,服務將返回

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "status": {
    "allowed": false,
    "reason": "image currently blacklisted"
  }
}

有關更多文件,請參閱`imagepolicy.v1alpha1` API

使用註解進行擴充套件

Pod 上所有匹配 `*.image-policy.k8s.io/*` 的註解都將傳送到 Webhook。傳送註解允許瞭解映象策略後端的使用者向其傳送額外資訊,並允許不同的後端實現接受不同的資訊。

你可能在此處放置的資訊示例有

  • 在緊急情況下,請求“打破常規”以覆蓋策略。
  • 記錄“打破常規”請求的票務系統中的票號
  • 向策略伺服器提供關於所提供映象的 imageID 的提示,以節省查詢時間

在任何情況下,註解均由使用者提供,Kubernetes 不會以任何方式驗證。

LimitPodHardAntiAffinityTopology

**型別**:驗證型。

此准入控制器拒絕在 `requiredDuringSchedulingRequiredDuringExecution` 中定義除 `kubernetes.io/hostname` 之外的 `AntiAffinity` 拓撲鍵的任何 Pod。

此准入控制器預設停用。

LimitRanger

**型別**:修改型和驗證型。

此准入控制器將觀察傳入請求,並確保其不違反 `Namespace` 中 `LimitRange` 物件列舉的任何約束。如果你在 Kubernetes 部署中使用 `LimitRange` 物件,則必須使用此准入控制器來強制執行這些約束。LimitRanger 還可以用於對未指定任何資源請求的 Pod 應用預設資源請求;目前,預設的 LimitRanger 將 0.1 CPU 要求應用於 `default` 名稱空間中的所有 Pod。

有關更多詳細資訊,請參閱LimitRange API 參考LimitRange 示例

MutatingAdmissionWebhook

**型別**:修改型。

此准入控制器呼叫任何與請求匹配的修改型 Webhook。匹配的 Webhook 序列呼叫;每個 Webhook 都可以根據需要修改物件。

此准入控制器(顧名思義)僅在修改階段執行。

如果此控制器呼叫的 Webhook 具有副作用(例如,減少配額),則它**必須**有一個協調系統,因為無法保證後續 Webhook 或驗證准入控制器會允許請求完成。

如果你停用 MutatingAdmissionWebhook,則還必須透過 `--runtime-config` 標誌停用 `admissionregistration.k8s.io/v1` 組/版本中的 `MutatingWebhookConfiguration` 物件,兩者預設都是啟用的。

編寫和安裝修改型 Webhook 時請謹慎

  • 使用者可能會對他們嘗試建立的物件與實際獲得的物件不同感到困惑。
  • 內建控制迴圈可能會在他們嘗試建立的物件在讀回時發生變化時中斷。
    • 設定最初未設定的欄位比覆蓋原始請求中設定的欄位更不容易引起問題。避免後者。
  • 未來對內建資源或第三方資源的控制迴圈的更改可能會破壞目前執行良好的 Webhook。即使 Webhook 安裝 API 已最終確定,也並非所有可能的 Webhook 行為都能保證無限期地受到支援。

NamespaceAutoProvision

**型別**:修改型。

此准入控制器檢查名稱空間資源上的所有傳入請求,並檢查引用的名稱空間是否存在。如果找不到,它將建立一個名稱空間。此准入控制器在不希望在使用名稱空間之前限制其建立的部署中很有用。

NamespaceExists

**型別**:驗證型。

此准入控制器檢查除 `Namespace` 本身之外的所有名稱空間資源請求。如果請求中引用的名稱空間不存在,則拒絕該請求。

NamespaceLifecycle

**型別**:驗證型。

此准入控制器強制處於終止過程中的 `Namespace` 中不能建立新物件,並確保拒絕不存在 `Namespace` 的請求。此准入控制器還阻止刪除三個系統保留的名稱空間 `default`、`kube-system`、`kube-public`。

`Namespace` 刪除會啟動一系列操作,以刪除該名稱空間中的所有物件(Pod、Service 等)。為了強制執行此過程的完整性,我們強烈建議執行此准入控制器。

NodeRestriction

**型別**:驗證型。

此准入控制器限制 kubelet 可以修改的 `Node` 和 `Pod` 物件。為了受此准入控制器限制,kubelet 必須使用 `system:nodes` 組中的憑據,使用者名稱為 `system:node:<nodeName>` 形式。此類 kubelet 將只允許修改其自己的 `Node` API 物件,並且只修改繫結到其節點的 `Pod` API 物件。kubelet 不允許更新或刪除其 `Node` API 物件中的汙點。

`NodeRestriction` 准入外掛阻止 kubelet 刪除其 `Node` API 物件,並強制 kubelet 按如下方式修改 `kubernetes.io/` 或 `k8s.io/` 字首下的標籤:

  • **阻止** kubelet 新增/刪除/更新帶有 `node-restriction.kubernetes.io/` 字首的標籤。此標籤字首保留給管理員用於對其 `Node` 物件進行工作負載隔離,kubelet 不允許修改帶有該字首的標籤。
  • **允許** kubelet 新增/刪除/更新這些標籤和標籤字首
    • kubernetes.io/hostname
    • kubernetes.io/arch
    • kubernetes.io/os
    • beta.kubernetes.io/instance-type
    • node.kubernetes.io/instance-type
    • failure-domain.beta.kubernetes.io/region(已棄用)
    • failure-domain.beta.kubernetes.io/zone(已棄用)
    • topology.kubernetes.io/region
    • topology.kubernetes.io/zone
    • kubelet.kubernetes.io/ 字首標籤
    • node.kubernetes.io/ 字首標籤

kubelet 對 `kubernetes.io` 或 `k8s.io` 字首下任何其他標籤的使用均被保留,將來 `NodeRestriction` 准入外掛可能會禁止或允許。

未來版本可能會增加額外的限制,以確保 kubelet 擁有正確操作所需的最小許可權集。

OwnerReferencesPermissionEnforcement

**型別**:驗證型。

此准入控制器保護對物件 `metadata.ownerReferences` 的訪問,以便只有具有物件**刪除**許可權的使用者才能更改它。此准入控制器還保護對物件 `metadata.ownerReferences[x].blockOwnerDeletion` 的訪問,以便只有具有對引用**所有者**的 `finalizers` 子資源**更新**許可權的使用者才能更改它。

PersistentVolumeClaimResize

特性狀態: Kubernetes v1.24 [stable]

**型別**:驗證型。

此准入控制器為檢查傳入的 `PersistentVolumeClaim` 擴容請求實現了額外的驗證。

建議啟用 `PersistentVolumeClaimResize` 准入控制器。預設情況下,此准入控制器會阻止所有 PVC 的擴容,除非 PVC 的 `StorageClass` 透過將 `allowVolumeExpansion` 設定為 `true` 顯式啟用擴容。

例如:從以下 `StorageClass` 建立的所有 `PersistentVolumeClaim` 都支援卷擴容

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gluster-vol-default
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://192.168.10.100:8080"
  restuser: ""
  secretNamespace: ""
  secretName: ""
allowVolumeExpansion: true

有關持久卷宣告的更多資訊,請參閱PersistentVolumeClaims

PodNodeSelector

特性狀態: Kubernetes v1.5 [alpha]

**型別**:驗證型。

此准入控制器透過讀取名稱空間註解和全域性配置來預設並限制名稱空間中可以使用哪些節點選擇器。

此准入控制器預設停用。

配置檔案格式

`PodNodeSelector` 使用配置檔案來設定後端行為的選項。請注意,配置檔案格式將在未來版本中轉換為版本化檔案。此檔案可以是 json 或 yaml 格式,具有以下結構:

podNodeSelectorPluginConfig:
  clusterDefaultNodeSelector: name-of-node-selector
  namespace1: name-of-node-selector
  namespace2: name-of-node-selector

從提供給 API 伺服器命令列標誌 `---admission-control-config-file` 的檔案中引用 `PodNodeSelector` 配置檔案

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodNodeSelector
  path: podnodeselector.yaml
...

配置註解格式

`PodNodeSelector` 使用註解鍵 `scheduler.alpha.kubernetes.io/node-selector` 為名稱空間分配節點選擇器。

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    scheduler.alpha.kubernetes.io/node-selector: name-of-node-selector
  name: namespace3

內部行為

此准入控制器具有以下行為

  1. 如果 `Namespace` 具有鍵為 `scheduler.alpha.kubernetes.io/node-selector` 的註解,則將其值用作節點選擇器。
  2. 如果名稱空間缺少此類註解,則使用 `PodNodeSelector` 外掛配置檔案中定義的 `clusterDefaultNodeSelector` 作為節點選擇器。
  3. 評估 Pod 的節點選擇器與名稱空間節點選擇器之間的衝突。衝突會導致拒絕。
  4. 評估 Pod 的節點選擇器與外掛配置檔案中定義的名稱空間特定允許選擇器之間的衝突。衝突會導致拒絕。

PodSecurity

特性狀態: Kubernetes v1.25 [穩定]

**型別**:驗證型。

PodSecurity 准入控制器在 Pod 被准入之前檢查新 Pod,根據請求的安全上下文和 Pod 所在名稱空間允許的Pod 安全標準限制來決定是否准入。

有關更多資訊,請參閱Pod 安全准入文件。

PodSecurity 替換了舊的名為 PodSecurityPolicy 的准入控制器。

PodTolerationRestriction

特性狀態: Kubernetes v1.7 [alpha]

**型別**:修改型和驗證型。

PodTolerationRestriction 准入控制器驗證 Pod 容忍度與其名稱空間容忍度之間的任何衝突。如果存在衝突,則拒絕 Pod 請求。然後,它將名稱空間上註解的容忍度合併到 Pod 的容忍度中。將結果容忍度與名稱空間上註解的允許容忍度列表進行檢查。如果檢查成功,則准入 Pod 請求,否則拒絕。

如果 Pod 的名稱空間沒有關聯的預設容忍度或允許的容忍度註解,則如果指定了叢集級別的預設容忍度或叢集級別的允許容忍度列表,則使用它們。

名稱空間的容忍度透過 `scheduler.alpha.kubernetes.io/defaultTolerations` 註解鍵分配。允許的容忍度列表可以透過 `scheduler.alpha.kubernetes.io/tolerationsWhitelist` 註解鍵新增。

名稱空間註解示例

apiVersion: v1
kind: Namespace
metadata:
  name: apps-that-need-nodes-exclusively
  annotations:
    scheduler.alpha.kubernetes.io/defaultTolerations: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'
    scheduler.alpha.kubernetes.io/tolerationsWhitelist: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'

此准入控制器預設停用。

PodTopologyLabels

特性狀態: Kubernetes v1.34 []

**型別**:修改型

PodTopologyLabels 准入控制器會修改所有繫結到 Node 的 Pod 的 `pods/binding` 子資源,新增與繫結 Node 匹配的拓撲標籤。這使得 Node 拓撲標籤可以作為 Pod 標籤提供,並透過Downward API 暴露給正在執行的容器。此控制器提供的標籤是 topology.kubernetes.io/regiontopology.kuberentes.io/zone 標籤。

當啟用 `PodTopologyLabelsAdmission` 特性門控時,此准入控制器被啟用。

Priority

**型別**:修改型和驗證型。

優先順序准入控制器使用 `priorityClassName` 欄位並填充優先順序的整數值。如果未找到優先順序類,則拒絕 Pod。

ResourceQuota

**型別**:驗證型。

此准入控制器將觀察傳入請求,並確保其不違反 `Namespace` 中 `ResourceQuota` 物件列舉的任何約束。如果你在 Kubernetes 部署中使用 `ResourceQuota` 物件,則必須使用此准入控制器來強制執行配額約束。

有關更多詳細資訊,請參閱ResourceQuota API 參考資源配額示例

RuntimeClass

**型別**:修改型和驗證型。

如果你定義了配置了Pod 開銷的 RuntimeClass,此准入控制器將檢查傳入的 Pod。啟用後,此准入控制器將拒絕任何已設定開銷的 Pod 建立請求。對於在其 `.spec` 中配置並選擇了 RuntimeClass 的 Pod,此准入控制器根據相應 RuntimeClass 中定義的值設定 Pod 中的 `.spec.overhead`。

另請參閱Pod 開銷以獲取更多資訊。

ServiceAccount

**型別**:修改型和驗證型。

此准入控制器實現了服務賬戶的自動化。Kubernetes 專案強烈建議啟用此准入控制器。如果你打算使用 Kubernetes `ServiceAccount` 物件,則應啟用此准入控制器。

為了增強 Secret 的安全措施,請使用單獨的名稱空間來隔離對掛載 Secret 的訪問。

StorageObjectInUseProtection

**型別**:修改型。

`StorageObjectInUseProtection` 外掛將 `kubernetes.io/pvc-protection` 或 `kubernetes.io/pv-protection` finalizers 新增到新建立的 Persistent Volume Claims (PVCs) 或 Persistent Volumes (PV)。如果使用者刪除了 PVC 或 PV,則在 PVC 或 PV 保護控制器從 PVC 或 PV 中移除 finalizer 之前,PVC 或 PV 不會被刪除。有關詳細資訊,請參閱Storage Object in Use Protection

TaintNodesByCondition

**型別**:修改型。

此准入控制器將新建立的節點汙點為 `NotReady` 和 `NoSchedule`。這種汙點避免了競爭條件,該條件可能導致 Pod 在其汙點更新以準確反映其報告條件之前被排程到新節點上。

ValidatingAdmissionPolicy

**型別**:驗證型。

此准入控制器為傳入的匹配請求實現 CEL 驗證。當特性門控 `validatingadmissionpolicy` 和 `admissionregistration.k8s.io/v1alpha1` 組/版本都啟用時,它被啟用。如果任何 ValidatingAdmissionPolicy 失敗,則請求失敗。

ValidatingAdmissionWebhook

**型別**:驗證型。

此准入控制器呼叫任何與請求匹配的驗證型 Webhook。匹配的 Webhook 並行呼叫;如果其中任何一個拒絕請求,則請求失敗。此准入控制器僅在驗證階段執行;它呼叫的 Webhook 不能修改物件,這與 `MutatingAdmissionWebhook` 准入控制器呼叫的 Webhook 不同。

如果此控制器呼叫的 Webhook 具有副作用(例如,減少配額),則它**必須**有一個協調系統,因為無法保證後續 Webhook 或其他驗證准入控制器會允許請求完成。

如果你停用 ValidatingAdmissionWebhook,則還必須透過 `--runtime-config` 標誌停用 `admissionregistration.k8s.io/v1` 組/版本中的 `ValidatingWebhookConfiguration` 物件。

是的。推薦的准入控制器預設啟用(此處顯示),因此你無需顯式指定它們。你可以使用 `---enable-admission-plugins` 標誌啟用預設集之外的其他准入控制器(**順序無關緊要**)。

上次修改時間:2025 年 6 月 16 日下午 1:59 PST:修復 PodTopologyLabels 備註未渲染 (1eb1607153)