Kubernetes 中的准入控制

此頁面概述了准入控制器。

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

Kubernetes 的幾個重要功能需要啟用准入控制器才能正確支援該功能。因此，未正確設定正確的准入控制器集的 Kubernetes API 伺服器是不完整的伺服器，將無法支援您期望的所有功能。

它們是什麼？

准入控制器是 Kubernetes API 伺服器 內的程式碼，用於檢查請求中到達的資料以修改資源。

准入控制器適用於建立、刪除或修改物件的請求。准入控制器還可以封鎖自訂動詞，例如透過 API 伺服器代理連線到 Pod 的請求。准入控制器不會（且無法）封鎖讀取（get、watch 或 list）物件的請求，因為讀取會繞過准入控制層。

准入控制機制可能是驗證、變更或兩者兼具。變更控制器可能會修改正在修改的資源的資料；驗證控制器可能不會。

Kubernetes 1.32 中的准入控制器包含以下清單，已編譯到 kube-apiserver 二進位檔案中，並且只能由叢集管理員設定。

准入控制擴充點

在完整的清單中，有三個特殊的控制器：MutatingAdmissionWebhook、ValidatingAdmissionWebhook 和 ValidatingAdmissionPolicy。這兩個 Webhook 控制器分別執行在 API 中設定的變更和驗證 准入控制 Webhook。ValidatingAdmissionPolicy 提供了一種在 API 中嵌入宣告式驗證程式碼的方法，而無需依賴任何外部 HTTP 呼叫。

您可以使用這三個准入控制器來自訂叢集在准入時的行為。

准入控制階段

准入控制過程分兩個階段進行。在第一階段，執行變更准入控制器。在第二階段，執行驗證准入控制器。再次注意，某些控制器既是變更控制器又是驗證控制器。

如果任一階段中的任何控制器拒絕請求，則會立即拒絕整個請求，並向最終使用者傳回錯誤。

最後，除了有時會變更受影響的物件之外，許可控制器有時也可能具有副作用，也就是在處理請求時變更相關的資源。遞增配額用量是說明其必要性的典型範例。任何此類副作用都需要有對應的回收或協調程序，因為給定的許可控制器無法確定給定的請求是否會通過所有其他許可控制器。

我該如何開啟許可控制器？

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.32 中，預設的外掛程式如下：

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

每個許可控制器有什麼作用？

AlwaysAdmit

類型：驗證。

此許可控制器允許所有 Pod 進入叢集。它已棄用，因為其行為與完全沒有許可控制器時相同。

AlwaysDeny

類型：驗證。

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

AlwaysPullImages

類型：變更和驗證。

此許可控制器修改每個新的 Pod，以強制映像檔提取策略為 Always。這在多租戶叢集中非常有用，如此一來，使用者可以確信他們的私有映像檔只能由那些擁有提取憑證的人使用。如果沒有此許可控制器，一旦映像檔被提取到節點，來自任何使用者的任何 Pod 都可以透過知道映像檔的名稱來使用它（假設 Pod 已排程到正確的節點上），而無需對映像檔進行任何授權檢查。當啟用此許可控制器時，映像檔總是在啟動容器之前提取，這表示需要有效的憑證。

CertificateApproval

類型：驗證。

此許可控制器觀察核准 CertificateSigningRequest 資源的請求，並執行額外的授權檢查，以確保核准使用者有權限核准 CertificateSigningRequest 資源上請求的 spec.signerName 的憑證請求。

如需在 CertificateSigningRequest 資源上執行不同動作所需的權限的詳細資訊，請參閱憑證簽署請求。

CertificateSigning

類型：驗證。

此許可控制器觀察對 CertificateSigningRequest 資源的 status.certificate 欄位的更新，並執行額外的授權檢查，以確保簽署使用者有權限簽署 CertificateSigningRequest 資源上請求的 spec.signerName 的憑證請求。

如需在 CertificateSigningRequest 資源上執行不同動作所需的權限的詳細資訊，請參閱憑證簽署請求。

CertificateSubjectRestriction

類型：驗證。

此許可控制器觀察 CertificateSigningRequest 資源的建立，這些資源的 spec.signerName 為 kubernetes.io/kube-apiserver-client。它拒絕任何指定 system:masters 的「群組」（或「組織屬性」）的請求。

DefaultIngressClass

類型：變更。

此許可控制器觀察未請求任何特定 Ingress 類別的 Ingress 物件的建立，並自動將預設 Ingress 類別新增至它們。這樣一來，不請求任何特殊 Ingress 類別的使用者完全不需要在意它們，並且他們將獲得預設的類別。

當未設定預設 Ingress 類別時，此許可控制器不會執行任何動作。當多個 Ingress 類別被標記為預設時，它會拒絕任何 Ingress 的建立，並顯示錯誤，管理員必須重新檢視其 IngressClass 物件，並僅將一個標記為預設（使用註解 "ingressclass.kubernetes.io/is-default-class"）。此許可控制器忽略任何 Ingress 更新；它僅在建立時執行動作。

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

DefaultStorageClass

類型：變更。

此許可控制器觀察未請求任何特定儲存類別的 PersistentVolumeClaim 物件的建立，並自動將預設儲存類別新增至它們。這樣一來，不請求任何特殊儲存類別的使用者完全不需要在意它們，並且他們將獲得預設的類別。

當未設定預設儲存類別時，此許可控制器不會執行任何動作。當多個儲存類別被標記為預設時，它會拒絕任何 PersistentVolumeClaim 的建立，並顯示錯誤，管理員必須重新檢視其 StorageClass 物件，並僅將一個標記為預設。此許可控制器忽略任何 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 物件上的 externalIPs。externalIPs 的現有使用不受影響，使用者可以從現有 Service 物件上的 externalIPs 中移除值。

大多數使用者根本不需要此功能，叢集管理員應考慮停用它。需要使用此功能的叢集應考慮使用一些自訂政策來管理其使用。

此許可控制器預設為停用。

EventRateLimit

類型：驗證。

此許可控制器減輕了 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 中定義 AntiAffinity 拓撲金鑰，但 kubernetes.io/hostname 除外的 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、服務等）。為了強制執行該程序的完整性，我們強烈建議執行此許可控制器。

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

類型：驗證。

此許可控制器實作額外的驗證，以檢查傳入的 PersistentVolumeClaim 調整大小請求。

建議啟用 PersistentVolumeClaimResize 許可控制器。此許可控制器預設會防止調整所有聲明的大小，除非聲明的 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

類型：驗證。

此許可控制器預設並限制命名空間中可能使用的節點選取器，方法是讀取命名空間註解和全域組態。

此許可控制器預設為停用。

組態檔格式

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

類型：驗證。

PodSecurity 許可控制器會在新的 Pod 被許可之前檢查它們，根據請求的安全環境定義以及 Pod 將在其中的命名空間的允許 Pod 安全標準的限制，判斷是否應許可它們。

如需更多資訊，請參閱 Pod 安全許可 文件。

PodSecurity 取代了名為 PodSecurityPolicy 的舊版許可控制器。

PodTolerationRestriction

類型：變更和驗證。

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"}]'

此許可控制器預設為停用。

Priority

類型：變更和驗證。

優先順序許可控制器使用 priorityClassName 欄位並填入優先順序的整數值。如果找不到優先順序類別，則會拒絕 Pod。

ResourceQuota

類型：驗證。

此許可控制器將觀察傳入的請求，並確保其不違反 Namespace 中 ResourceQuota 物件中列舉的任何限制。如果您在 Kubernetes 部署中使用 ResourceQuota 物件，您必須使用此許可控制器來強制執行配額限制。

如需更多詳細資訊，請參閱 ResourceQuota API 參考和 Resource Quota 範例。

RuntimeClass

類型：變更和驗證。

如果您定義了具有設定Pod 額外負荷的 RuntimeClass，此許可控制器會檢查傳入的 Pod。啟用後，此許可控制器會拒絕任何已設定額外負荷的 Pod 建立請求。對於在其 .spec 中設定和選取 RuntimeClass 的 Pod，此許可控制器會根據對應 RuntimeClass 中定義的值，在 Pod 中設定 .spec.overhead。

另請參閱 Pod 額外負荷 以取得更多資訊。

ServiceAccount

類型：變更和驗證。

此許可控制器實作 serviceAccount 的自動化。Kubernetes 專案強烈建議啟用此許可控制器。如果您打算使用任何 Kubernetes ServiceAccount 物件，您應該啟用此許可控制器。

為了增強 Secrets 周圍的安全措施，請使用個別的命名空間來隔離對已掛載 Secrets 的存取。

StorageObjectInUseProtection

類型：變更。

StorageObjectInUseProtection 外掛程式將 kubernetes.io/pvc-protection 或 kubernetes.io/pv-protection finalizer 新增至新建立的持久卷聲明 (PVC) 或持久卷 (PV)。如果使用者刪除 PVC 或 PV，則在 PVC 或 PV Protection Controller 從 PVC 或 PV 移除 finalizer 之前，不會移除 PVC 或 PV。如需更多詳細資訊，請參閱 使用中儲存物件保護。

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 標記啟用預設集合以外的其他許可控制器（順序無關緊要）。