後 我們介紹他的哥哥 - 。 這是一個開源項目，用於將系統元件安裝到 Kubernetes 叢集中，這些元件可以稱為附加元件。
為什麼還要添加任何內容？
眾所周知，Kubernetes 不是現成的一體化產品，要建立一個「成人」集群，您將需要各種添加。 Addon-operator 將協助您安裝、設定這些附加元件並保持最新。
集群中對附加元件的需求在 同事們 。 簡而言之，目前 Kubernetes 的情況是，對於簡單的「玩轉」安裝，您可以使用開箱即用的元件，對於開發人員和測試，您可以添加 Ingress，但對於完整安裝，大約需要你可以說“你的生產已經準備好了”，你需要添加十幾個不同的附加組件：用於監控的東西，用於日誌記錄的東西，不要忘記入口和證書管理器，選擇節點組，添加網絡策略，季節使用 sysctl 和 pod 自動縮放器設定...
與他們合作的具體細節是什麼？
實踐表明，問題不僅限於一次安裝。 為了舒適地使用集群，需要更新、停用附加元件（從集群中刪除），並且您需要在將它們安裝到生產集群中之前測試一些附加元件。
那麼，也許 Ansible 就夠了？ 或許。 但 一般來說，成熟的附加元件如果沒有設定就無法生存。 這些設定可能會有所不同，具體取決於叢集變體（aws、gce、azure、裸機、do...）。 有些設定無法提前指定；它們必須從叢集中取得。 而且叢集不是靜態的：對於某些設置，您必須監視變更。 這裡 Ansible 已經缺少了：你需要一個位於叢集中的程序，即Kubernetes 運營商。
那些在工作中嘗試過的人 ，他們會說安裝和更新附加元件以及監控設定的任務可以使用完全解決 對於 shell 操作符。 您可以編寫一個執行條件的腳本 kubectl apply 並監視，例如 ConfigMap，其中將儲存設定。 這大約是在 addon-operator 中實現的。
這是如何在 addon-operator 中組織的？
在創建新的解決方案時，我們遵循以下原則：
- 附加安裝程式必須支援 模板化和聲明性配置。 我們不製作安裝附加元件的神奇腳本。 Addon-operator 使用 Helm 來安裝外掛程式。 要安裝，您需要建立一個圖表並選擇將用於配置的值。
- 設定可以是 安裝時生成， 他們可以 從集群中獲取或 接收更新、監控叢集資源。 這些操作可以使用鉤子來實現。
- 設定可以是 儲存在叢集中。 為了在叢集中儲存設置，需要建立一個 ConfigMap/addon-operator，並且 Addon-operator 會監視對此 ConfigMap 的變更。 插件操作符使鉤子能夠使用簡單的約定來存取設定。
- 添加取決於設置。 如果設定已更改，則插件操作員將推出具有新值的 Helm 圖表。 我們將 Helm 圖表、其值和掛鉤模組的組合稱為（更多詳細資訊請參見下文）。
- 分期。 沒有神奇的發布腳本。 更新機制類似於常規應用程式 - 將附加元件和附加操作符收集到圖像中，標記它們並推出它們。
- 結果控制。 Addon-operator 可以為 Prometheus 提供指標。
addon-operator 中的 padding 是什麼？
新增可以被視為向叢集新增功能的任何內容。 例如，安裝 Ingress 就是一個很好的附加元件範例。 這可以是任何具有自己的 CRD 的操作員或控制器：prometheus-operator、cert-manager、kube-controller-manager 等。 或一些小但更容易使用的東西 - 例如，秘密複製器，它將註冊表秘密複製到新的命名空間，或 sysctl 調諧器，它在新節點上配置 sysctl 參數。
為了實作附加元件，Addon-operator 提供了幾個概念：
- 舵圖 用於將各種軟體安裝到叢集中 - 例如 Prometheus、Grafana、nginx-ingress。 如果所需的元件有Helm圖表，那麼使用Addon-operator安裝它會非常簡單。
- 值儲存。 Helm 圖表通常有許多不同的設置，這些設置會隨著時間的推移而改變。 Addon-operator 支援儲存這些設置，並且可以監視它們的更改，以便使用新值重新安裝 Helm 圖表。
- 掛鉤 是附加操作符在事件上運行並存取值儲存的可執行檔。 此鉤子可以監視叢集中的變化並更新值儲存中的值。 那些。 使用鉤子，您可以在啟動時或根據計劃進行發現以從集群中收集值，也可以進行持續發現，根據集群中的變化從集群中收集值。
- 模 是 Helm 圖表、值儲存和鉤子的組合。 可以啟用或停用模組。 停用模組意味著刪除所有 Helm Chart 版本。 模組可以動態地啟用自己，例如，如果啟用了它需要的所有模組，或者如果發現在掛鉤中找到了必要的參數 - 這是使用輔助啟用腳本完成的。
- 全域掛鉤。 這些是「獨立」的鉤子，它們不包含在模組中，並且可以存取全局值存儲，其值可用於模組中的所有鉤子。
這些部分如何協同工作？ 我們來看看文件中的圖片：
有兩種工作場景：
- 全域鉤子由事件觸發 - 例如，當叢集中的資源發生變化時。 此掛鉤處理變更並將新值寫入全域值儲存。 Addon-operator 注意到全域儲存已變更並啟動所有模組。 每個模組使用其鉤子確定是否需要啟用並更新其值儲存。 如果啟用該模組，Addon 操作員將開始安裝 Helm 圖表。 在這種情況下，Helm圖表可以存取模組儲存和全域儲存中的值。
- 第二種情況更簡單：模組鉤子由事件觸發並更改模組值儲存中的值。 插件操作員注意到這一點並啟動具有更新值的 Helm 圖表。
添加可以作為一個單獨的鉤子或一個 Helm 圖表來實現，或者 甚至作為幾個依賴模組 - 這取決於叢集中安裝的元件的複雜性以及所需的配置彈性等級。 例如，在儲存庫中（）有一個 sysctl-tuner 插件，它既作為帶有鉤子和 Helm 圖表的簡單模組實現，又使用值存儲，這使得可以透過編輯 ConfigMap 添加設定。
交付更新
關於組織 Addon-operator 安裝的組件更新的幾句話。
要在叢集中執行 Addon-operator，您需要 建立帶有附加內容的圖像 以hook和Helm圖表檔案的形式，新增二進位文件 addon-operator 以及鉤子所需的一切： bash, kubectl, jq, python ETC。 然後，可以將該映像作為常規應用程式推廣到集群，並且您很可能希望組織一種或另一種標記方案。 如果叢集很少，與應用程式相同的方法可能是合適的：新版本、新版本、前往所有叢集並修正 Pod 的映像。 然而，在部署到大量叢集的情況下，從通道自我更新的概念更適合我們。
我們是這樣做的：
- 通道本質上是一個可以設定為任何內容的標識符（例如，dev/stage/ea/stable）。
- 頻道名稱是圖像標籤。 當您需要對頻道進行更新時，會組裝一個新圖像並用頻道名稱標記。
- 當註冊表中出現新映像時，Addon-operator 將重新啟動並使用新映像啟動。
正如中所寫，這不是最佳實踐 。 不建議這樣做，但我們正在討論 位於同一集群中的常規應用程式。 對於 Addon-operator 來說，一個應用程式是分散在叢集中的大量 Deployment，自我更新有很大幫助，讓生活變得更輕鬆。
通路幫助和 測試中：如果有輔助集群，可以配置到通道 stage 並將更新滾動到其中，然後再將其發佈到頻道 ea и stable。 如果通道上有集群 ea 發生錯誤，您可以將其切換到 stable，同時正在調查該集群的問題。 如果叢集不再受到主動支持，它會切換到「凍結」通道 - 例如， freeze-2019-03-20.
除了更新 hooks 和 Helm 圖表之外，您可能還需要 更新和第三方元件。 例如，您注意到條件節點導出器中的錯誤，甚至想出瞭如何修補它。 接下來，您開啟了 PR，正在等待新版本遍歷所有叢集並增加鏡像的版本。 為了避免無限期地等待，您可以建立節點導出器並在接受 PR 之前切換到它。
一般來說，這可以在沒有Addon-operator 的情況下完成，但是使用Addon-operator，用於安裝節點導出器的模組將在一個存儲庫中可見，用於構建鏡像的Dockerfile 可以保留在那裡，對於所有參與者來說都變得更容易了解發生了什麼的過程...如果有多個集群，那麼測試您的 PR 並推出新版本就會變得更容易！
這種元件更新組織對我們來說很成功，但畢竟可以實施任何其他合適的方案 在本例中，Addon-operator 是一個簡單的二進位文件.
結論
Addon-operator 中實現的原則可讓您建立一個透明的流程，用於在叢集中建立、測試、安裝和更新附加元件，類似於常規應用程式的開發流程。
模組格式（Helm 圖表 + 掛鉤）的 Addon-operator 的附加元件可以公開提供。 我們，Flant 公司，計劃在夏季以此類新增內容的形式發布我們的開發成果。 加入 GitHub 上的開發 (, ），嘗試根據 и ，等待有關哈布雷和我們的消息 !
聚苯乙烯
另請閱讀我們的博客：
- «“;
- «“。
來源： www.habr.com