kubernetes中的Admission Controllers

這是啥

准入控制admission controller本質上一段代碼，在對kubernetes api的請求過程當中，順序爲 先通過 認證 & 受權，執行准入操做，在對目標對象進行操做。這個准入代碼在apiserver中，並且必須被編譯到二進制文件中才能被執行。

在對集羣進行請求時，每一個准入控制代碼都按照必定順序執行。若是有一個准入控制拒絕了這次請求，那麼整個請求的結果將會當即返回，並提示用戶相應的error信息。

在某些狀況下，爲了適用於應用系統的配置，准入邏輯可能會改變目標對象。此外，准入邏輯也會改變請求操做的一部分相關資源。

爲何須要？

在kubernetes中，一些高級特性正常運行的前提條件爲，將一些准入模塊處於enable狀態。總結下，對於kubernetes apiserver，若是不適當的配置准入控制模塊，他就不能稱做是一個完整的server，某些功能也不會正常的生效。

如何開啓一個准入模塊

在kubernetes apiserver中有一個參數：admission_control，他的值爲一串用逗號鏈接的 有序的 准入模塊列表，設置後，就可在對象唄操做前執行必定順序的准入模塊調用。

每一個准入模塊都幹了啥

AlwaysAdmit

對全部請求開綠燈。

AlwaysDeny

對全部請求開紅燈，多用於測試環境。

DenyExecOnPrivileged

它會攔截全部想在privileged container上執行命令的請求。
若是本身的集羣支持privileged container，本身又但願限制用戶在這些privileged container上執行命令，那麼強烈推薦使用它。

ServiceAccount

這個plug-in將 serviceAccounts實現了自動化，若是想要使用ServiceAccount 對象，那麼強烈推薦使用它。
關於serviceAccount的描述以下：

一個serviceAccount爲運行在pod內的進程添加了相應的認證信息。當準入模塊中開啓了此插件（默認開啓），那麼當pod建立或修改時他會作一下事情：

1. 若是pod沒有serviceAccount屬性，將這個pod的serviceAccount屬性設爲「default」；
   
   
   1. 確保pod使用de serviceAccount始終存在；
   2. 若是LimitSecretReferences 設置爲true，當這個pod引用了Secret對象卻沒引用ServiceAccount對象，棄置這個pod；
   3. 若是這個pod沒有包含任何ImagePullSecrets，則serviceAccount的ImagePullSecrets被添加給這個pod；
   4. 若是MountServiceAccountToken爲true，則將pod中的container添加一個VolumeMount 。

SecurityContextDeny

這個插件將會將使用了 SecurityContext的pod中定義的選項所有失效。
關於 SecurityContext的描述：

SecurityContext 在container中定義了操做系統級別的安全設定（uid, gid, capabilities, SELinux等等）。

ResourceQuota

它會觀察全部的請求，確保在namespace中ResourceQuota對象處列舉的container沒有任何異常。若是在kubernetes中使用了ResourceQuota對象，就必須使用這個插件來約束container。

推薦在admission control參數列表中，這個插件排最後一個。

LimitRanger

他會觀察全部的請求，確保沒有違反已經定義好的約束條件，這些條件定義在namespace中LimitRange對象中。若是在kubernetes中使用LimitRange對象，則必須使用這個插件。

NamespaceExists

它會觀察全部的請求，若是請求嘗試建立一個不存在的namespace，則這個請求被拒絕。

有推薦的插件順序嗎？

有！

--admission_control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota