如何進行Kubernetes中準入控制器的分析

如何進行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中準入控制器的分析的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！