共計 1533 個字符，預計需要花費 4 分鐘才能閱讀完成。

如何進行 Kubernetes 中準入控制器的分析，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

什么是準入控制器

每個針對 Kubernetes 資源對象的操作請求，都要經過 kube-apiserver 的層層審查才會被放行。對于讀操作而言，需要經過認證（是否是合法用戶）和鑒權（是否擁有權限）；而對于寫操作而言，除了要經過認證和鑒權外，還要檢查請求是合乎要求，只有順利通過這些審查才會被持久化到 etcd 存儲中。

準入控制器（Admission Controller）是用于審查請求的組件，它會劫持發往 kube-apiserver 的請求，對請求進行審查（必要時也會修改請求內容），它是 kube-apiserver 審查鏈中重要的一環，不合理的請求會被拒絕。

kube-apiserver 支持配置多個準入控制器，準入控制器分為修改型（Mutating）控制器和校驗型（Validating）控制器。修改型控制器會自動根據指定的策略對請求進行修改，而校驗型控制器則只是單純地檢查請求是否合乎要求，充當“看門狗”的角色。

多個準入控制器以插件（Webhook Plugin）的形式被組織起來，kube-apiserver 在審查請求時會先把請求交給修改型控制器對請求進行必要的修改，然后再將請求交給校驗型控制器進行審查。下圖展示了請求的審查完整路徑，以及準入控制器所在的位置：

API 請求到達 kube-apiserver 后會先進行認證（Authentication）和鑒權（Authorization），然后把請求交給修改型準入控制器進行必要的修改（多個修改型準入控制器串行執行），當所有修改型準入控制器執行完畢后，再使用 OpenAPI 校驗功能進行初步的語法校驗，接著再把請求交給校驗型準入控制器進行語法或語義的校驗（多個修改型準入控制器并行執行），最后再寫入 etcd。上面中的任何一個審查環節、任何一個準入控制器返回失敗，都會造成請求被拒絕。

準入控制器配置

準入控制器根據其部署形式可分為內置控制器和動態控制器兩種。內置控制器集成在 kube-apiserver 中，以插件的形式提供，每個插件都可以通過參數控制啟用或禁止；而動態控制器則是按一定標準實現的服務。關于動態控制器的更多內容將會在后續章節中展開介紹，本節主要介紹內置控制器的配置方法。

kube-apiserver 提供了數十個準入控制器插件，其中一些是默認開啟的，也可以通過參數顯式地控制啟用或禁用的插件。

開啟控制器插件

通過 kube-apiserver 的 –enable-admission-plugins 參數可以設置除默認啟用的控制器插件以外需要額外啟用的插件，多個插件名字以逗號分隔，例如以下參數開啟 NodeRestriction 和 ResourceQuota 兩個插件。

--enable-admission-plugins=NodeRestriction,ResourceQuota

該參數主要在需要啟用默認禁用的插件時使用。

關閉控制插件

通過 kube-apiserver 的 –disable-admission-plugins 參數可以設置禁用的控制器插件，同樣多個插件名字以逗號分隔，例如以下參數關閉 PodNodeSelector 和 AlwaysDeny 兩個插件。

--disable-admission-plugins=PodNodeSelector,AlwaysDeny

該參數主要在需要禁用默認啟用的插件時使用。

看完上述內容，你們掌握如何進行 Kubernetes 中準入控制器的分析的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注丸趣 TV 行業資訊頻道，感謝各位的閱讀！