Kubernetes 新概念 “Initializers”解析（上）：能讓你為叢集編寫插件的新模型

Kubernetes 如今能大展拳腳的原因有二：一是，因為他社群的無限優勢；二是，源于 Kubernetes API 的靈活性，以及能輕而易舉地在其上編寫自定義擴充或者插件。而在本文中，我将深入剖析一個新的概念：Initalizers，它能在實際建立之前修改 Kubernetes 動态資源和可插拔方式。

Initializers 已經在

Kubernetes 1.7

中作為 Alpha 功能。舉個例子來說，我們可以在 Google Container Engine 中使用 Intializers 來擴充 Kubernetes 的基礎功能，也可以根據需求實作新的 initializers 設定。

到目前為止，Kubernetes 隻有在 plug-in 建立之前用準入控制插件來攔截資源。例如，你可以使用一個準入插件來強制讓所有容器鏡像來自特定的系統資料庫，并組織其他鏡像被部署在 pod 中。有相當多的準入控制器提供的功能，如執行限制、應用建立檢查，并為缺少的字段設定預設值。

但準入控制器也存在如下問題：

1. 他們被編譯在 Kubernetes：如果你尋找的目标缺失，你需要 fork Kubernetes，并且寫一個準入插件，并自己保持 fork。
2. 您需要通過将其名稱傳遞給 kube-apiserver 的 –admission-control 标志來啟用每個準入插件 。在很多情況下，這意味着重新部署叢集。
3. 某些托管叢集的供應商可能不允許自定義 API 伺服器标志，是以可能無法啟用源代碼中可用的所有準入控制器。

于是便提出了動态/外部準入控制器來解決這些問題。目前有兩種類型的插件: Initializers 和 web 鈎子。Initializers 類似于準入控制器 plug-ins, 你可以在建立資源之前截取它。但它們也與準入控制器 plug-ins 不同, 因為它們不是 Kubernetes 源代碼的一部分, 也不是編譯而成的。你需要自己寫一個控制器。

你能用 Initializers 做什麼？

當你在建立 Kubernetes 對象之前截取它們時, 存在着無窮的變數: 你可以以任何方式來變換對象, 或防止對象被建立。

以下是對 Initializers 的一些想法，每個都在你的叢集中實施一個特定的政策：

• 如果該容器開放 80 端口或具有特定的注釋, 則向該 pod 注入一個代理 sidecar 容器。
• 将帶有測試證書的卷自動插入測試命名空間中的所有 pod。
• 如果一個隐藏密令少于 20 個字元（有可能是密碼），則阻止其建立。

如果您不打算修改對象并攔截隻讀對象, web 鈎子可能會是一個更快和更精簡的選擇來擷取有關對象的通知。

上面列出的一些功能，例如注入 sidecar 容器或卷，也可以使用 Pod Presets 以犧牲靈活性來進行實作。

下期導讀：将為你具體解析 Initializers，并指出其優勢和缺陷，同時手把手教你開發你自己的 Initializers。

本文轉自中文社群-

Kubernetes 新概念 “Initializers”解析（上）：能讓你為叢集編寫插件的新模型