在 Operator SDK - Helm、Go、Ansible 中混合實現語言

Question

我需要將多個容器部署到 Kubernetes 集群。 目標是自動化 Kafka、Kafka Connect、PostgreSQL 等的部署。 其中一些已經提供了我們可以使用的 Helm 操作符。 所以我的問題是，我們能否以某種方式在操作員內部使用這些 helm 操作員？ 如果是這樣，最好的方法是什么？

到目前為止，我能想到的唯一方法是從部署應用程序中調用 helm setup 控制台命令。 另一種方法，不使用這些 helm 文件，將在我自己的 operator 中實現每個 operator 的功能，這似乎沒有多大意義，因為我需要的東西已經開發並且是公開的。

我對運營商開發很陌生，所以如果這是一個愚蠢的問題，請原諒。

編輯：運營商的主要目的是部署 X 數據庫。 除此之外，我們還希望有一個可以立即部署整個系統的操作員/捆綁包。 即使我們對某些容器有額外的任務，使用操作符進行捆綁是否有意義？ 這樣，用戶將在 yaml 文件中指定：

databases
  - type: "postgres"
    name: "users"
  - type: "postgres"
    name: "purchases"

和 2 PostgreSQL 數據庫將被創建。 然后可以在其他 yaml 文件中或在同一 yaml 文件中進一步提及這些數據庫。 手頭案例：數據庫中的信息將由 Debezium（另一個容器）提取，因此 Debezium 需要知道它們的地址。 所以運營商應該創建一個服務並將服務地址與數據庫名稱相關聯。

這是 ETL 系統的一部分。 這個想法是操作員可以通過處理大部分配置來輕松部署整個系統。 考慮到這一點，我們在考慮是否不可能選擇現有的 Helm 操作員（或其他類型的操作員）並通過對配置進行少量修改（例如不同數據庫的不同端口）來部署它們。

但是在閱讀了F1ko的回復后，我獲得了新的視角。 也許這對於最初預期的操作員來說是不可能的？

Edit2 ：對edit1的澄清。

Answer 1

僅出於澄清目的：

• Helm 是一個 package 管理器，您可以使用它以捆綁的方式將應用程序安裝到集群上：它基本上為您提供了所有必要的 YAML，例如 ConfigMap、服務、部署以及啟動所需應用程序所需的任何其他內容以正確的方式運行。

• 操作員本質上是 controller。 在 Kubernetes 中，有很多不同的控制器在你做某事時定義“邏輯”（例如，如果你決定增加replicas字段，復制控制器會添加更多的 Pod 副本）。 控制器太多了，無法全部列出並單獨運行，這就是為什么它們被編譯成一個稱為 kube-controller-manager 的二進制文件的原因。 定制的控制器被稱為操作符以便於區分。 這些操作員只需監視某些“事物”的 state 並在需要時執行操作。 大多數情況下，這些“東西”將是 CustomResources (CRs)，它們本質上是新的 Kubernetes 對象，通過應用 CustomResourceDefinitions (CRDs) 引入集群。

話雖如此，使用 helm 部署算子並不少見，但是，請盡量避免使用“helm 算子”一詞，因為它實際上指的是一個非常具體的算子，並且將來可能會導致混淆： https:// github.com/fluxcd/helm-operator

所以我的問題是，我們能否以某種方式在操作員內部使用這些 helm 操作員？

盡管您可以使用operator-sdk構建自己的操作員，然后您可以部署或觸發來自其他操作員的某些事件（例如，通過編輯他們的 CRD），但沒有理由這樣做。

到目前為止，我能想到的唯一方法是從部署應用程序中調用 helm setup 控制台命令。

您正在尋找的很可能是一個合適的 CI/CD 工作流程。 只需提交 helm 圖表和values.yaml文件，您在helm install期間使用Git存儲庫並擁有 CI/CD 工具（例如GitLab 每次部署新集群時）。

更新：當另一個編輯他的問題並發表評論時，我決定更新這篇文章：

算子的主要目的是部署X數據庫。 除此之外，我們還希望有一個可以立即部署整個系統的操作員/捆綁包。

您認為將運算符捆綁在另一個運算符中是否有意義，就像對 Helm 所做的那樣？

不，這根本沒有意義。 這正是 helm 的用途。 使用 helm，您可以捆綁東西，甚至可以將多個 helm 圖表捆綁在一起，這可能是您真正想要的。 您可以擁有一個 helm 圖表，將所需的值傳遞給實際的 operator helm 圖表，因此在多個位置使用類似 service-name 的東西。

算子里面算子的情況下，配置算子的時候還需要單獨配置每個子算子嗎？

如上所述，這樣做沒有任何意義，這只是一種過度設計的方法。 但是，如果您真的想使用運算符方法 go ，基本上可以采用兩種方法：

• 編寫一個算子，通過更改其他算子的 CR、ConfigMap 等來配置其他算子； 使用這種方法，您將擁有一個輕量級的運算符，但是您必須確保它始終與您希望它干擾的所有不同運算符兼容（當它們更改為具有重大更改的新apiVersion時，引入新的 CR或任何類似的東西，你將不得不再次適應）。
• 將現有運算符中的整個邏輯提取到您的運算符中（即重建已經存在的東西）； 使用這種方法，您將擁有一個龐大的單體應用程序，維護起來會非常痛苦，因為只要上游操作符有更新，您就必須不斷更新代碼

希望現在很清楚，為“操作”其他操作符構建自己的操作符會帶來很多痛苦的依賴關系，不應該成為 go 的方式。

是否可以部署不同的圖像配置？ 比如數據庫配置了不同的端口？

好的操作符和舵圖讓您可以通過相應的 CR / ConfigMap 或values.yaml文件開箱即用地執行此操作，但是，現在這取決於您要使用的解決方案。 所以總的來說答案是：是的，如果支持的話是可能的。