準入控制器（Admission Controller） · kubernetes完整攻略

# 準入控制器（Admission Controller）準入控制器（Admission Controller）位于 API Server 中，在對象被持久化之前，準入控制器攔截對 API Server 的請求，一般用來做身份驗證和授權。其中包含兩個特殊的控制器：`MutatingAdmissionWebhook` 和 `ValidatingAdmissionWebhook`。分別作為配置的變異和驗證[準入控制 webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 **變更（Mutating）準入控制**：修改請求的對象 **驗證（Validating）準入控制**：驗證請求的對象準入控制器是在 API Server 的啟動參數重配置的。一個準入控制器可能屬于以上兩者中的一種，也可能兩者都屬于。當請求到達 API Server 的時候首先執行變更準入控制，然后再執行驗證準入控制。我們在部署 Kubernetes 集群的時候都會默認開啟一系列準入控制器，如果沒有設置這些準入控制器的話可以說你的 Kubernetes 集群就是在裸奔，應該只有集群管理員可以修改集群的準入控制器。例如我會默認開啟如下的準入控制器。 ```bash --admission-control=ServiceAccount,NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQuota,MutatingAdmissionWebhook,ValidatingAdmissionWebhook ``` ## 準入控制器列表 Kubernetes 目前支持的準入控制器有： - **AlwaysPullImages**：此準入控制器修改每個 Pod 的時候都強制重新拉取鏡像。 - **DefaultStorageClass**：此準入控制器觀察創建`PersistentVolumeClaim`時不請求任何特定存儲類的對象，并自動向其添加默認存儲類。這樣，用戶就不需要關注特殊存儲類而獲得默認存儲類。 - **DefaultTolerationSeconds**：此準入控制器將Pod的容忍時間`notready:NoExecute`和`unreachable:NoExecute` 默認設置為5分鐘。 - **DenyEscalatingExec**：此準入控制器將拒絕`exec` 和附加命令到以允許訪問宿主機的升級了權限運行的pod。 - **EventRateLimit (alpha)**：此準入控制器緩解了 API Server 被事件請求淹沒的問題，限制時間速率。 - **ExtendedResourceToleration**：此插件有助于創建具有擴展資源的專用節點。 - **ImagePolicyWebhook**：此準入控制器允許后端判斷鏡像拉取策略，例如配置鏡像倉庫的密鑰。 - **Initializers (alpha)**：Pod初始化的準入控制器，詳情請參考[動態準入控制](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)。 - **LimitPodHardAntiAffinityTopology**：此準入控制器拒絕任何在 `requiredDuringSchedulingRequiredDuringExecution` 的 `AntiAffinity ` 字段中定義除了`kubernetes.io/hostname` 之外的拓撲關鍵字的 pod 。 - **LimitRanger**：此準入控制器將確保所有資源請求不會超過 namespace 的 `LimitRange`。 - **MutatingAdmissionWebhook （1.9版本中為beta）**：該準入控制器調用與請求匹配的任何變更 webhook。匹配的 webhook是串行調用的；如果需要，每個人都可以修改對象。 - **NamespaceAutoProvision**：此準入控制器檢查命名空間資源上的所有傳入請求，并檢查引用的命名空間是否存在。如果不存在就創建一個命名空間。 - **NamespaceExists**：此許可控制器檢查除 `Namespace` 其自身之外的命名空間資源上的所有請求。如果請求引用的命名空間不存在，則拒絕該請求。 - **NamespaceLifecycle**：此準入控制器強制執行正在終止的命令空間中不能創建新對象，并確保`Namespace`拒絕不存在的請求。此準入控制器還防止缺失三個系統保留的命名空間`default`、`kube-system`、`kube-public`。 - **NodeRestriction**：該準入控制器限制了 kubelet 可以修改的`Node`和`Pod`對象。 - **OwnerReferencesPermissionEnforcement**：此準入控制器保護對`metadata.ownerReferences`對象的訪問，以便只有對該對象具有“刪除”權限的用戶才能對其進行更改。 - **PodNodeSelector**：此準入控制器通過讀取命名空間注釋和全局配置來限制可在命名空間內使用的節點選擇器。 - **PodPreset**：此準入控制器注入一個pod，其中包含匹配的PodPreset中指定的字段，詳細信息見[Pod Preset](pod-preset.md)。 - **PodSecurityPolicy**：此準入控制器用于創建和修改pod，并根據請求的安全上下文和可用的Pod安全策略確定是否應該允許它。 - **PodTolerationRestriction**：此準入控制器首先驗證容器的容忍度與其命名空間的容忍度之間是否存在沖突，并在存在沖突時拒絕該容器請求。 - **Priority**：此控制器使用`priorityClassName`字段并填充優先級的整數值。如果未找到優先級，則拒絕Pod。 - **ResourceQuota**：此準入控制器將觀察傳入請求并確保它不違反命名空間的`ResourceQuota`對象中列舉的任何約束。 - **SecurityContextDeny**：此準入控制器將拒絕任何試圖設置某些升級的[SecurityContext](https://kubernetes.io/docs/user-guide/security-context)字段的pod 。 - **ServiceAccount**：此準入控制器實現[serviceAccounts的](https://kubernetes.io/docs/user-guide/service-accounts)自動化。 - **用中的存儲對象保護**：該`StorageObjectInUseProtection`插件將`kubernetes.io/pvc-protection`或`kubernetes.io/pv-protection`終結器添加到新創建的持久卷聲明（PVC）或持久卷（PV）。在用戶刪除PVC或PV的情況下，PVC或PV不會被移除，直到PVC或PV保護控制器從PVC或PV中移除終結器。有關更多詳細信息，請參閱使用中的[存儲對象保護](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。 - **ValidatingAdmissionWebhook（1.8版本中為alpha；1.9版本中為beta）**：該準入控制器調用與請求匹配的任何驗證webhook。匹配的webhooks是并行調用的；如果其中任何一個拒絕請求，則請求失敗。 ## 推薦配置 **Kubernetes 1.10+** 對于Kubernetes 1.10及更高版本，我們建議使用`--enable-admission-plugins`標志運行以下一組準入控制器（**順序無關緊要**）。 > **注意：** `--admission-control`在1.10中已棄用并替換為`--enable-admission-plugins`。 ```bash --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota ``` 對于Kubernetes 1.9及更早版本，我們建議使用`--admission-control`標志（**順序有關**）運行以下一組許可控制器。 **Kubernetes 1.9** ```bash --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota ``` 值得重申的是，在1.9中，這些發生在變更階段和驗證階段，并且例如`ResourceQuota`在驗證階段運行，因此是運行的最后一個準入控制器。 `MutatingAdmissionWebhook`在此列表中出現在它之前，因為它在變更階段運行。對于早期版本，沒有驗證準入控制器和變更準入控制器的概念，并且準入控制器以指定的確切順序運行。 **Kubernetes 1.6 - 1.8** ```bash --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds ``` ## 參考 - [Using Admission Controllers - kubernetes.io](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)