我需要將多個容器部署到 Kubernetes 集群。目標是自動化Kafka，Kafka Connect，PostgreSQL等的部署。其中一些已經提供了我們可以使用的Helm運算符。所以我的問題是，我們能以某種方式在操作員內部使用這些頭盔操作員嗎？如果是這樣，最好的方法是什么？到目前為止，我能想到的唯一方法是從部署應用中調用 helm setup 控制臺命令。另一種方法，如果不使用這些 helm 文件，就是在我自己的運算符中實現每個運算符的功能，這似乎沒有多大意義，因為我需要的東西已經開發并且是公開的。我對操作員開發非常陌生，所以如果這是一個愚蠢的問題，請原諒我。編輯：運算符的主要目的是部署 X 數據庫。除此之外，我們希望有一個可以立即部署整個系統的單個運算符/捆綁包。即使我們對某些容器有其他任務，使用運算符進行捆綁是否有意義？這樣，用戶將在 yaml 文件中指定：databases - type: "postgres" name: "users" - type: "postgres" name: "purchases"并將創建2個PostgreSQL數據庫。然后，可以在其他 yaml 文件中提及這些數據庫，也可以在同一 yaml 文件中進一步提及這些數據庫。手頭案例：數據庫中的信息將由 Debezium（另一個容器）提取，因此 Debezium 需要知道他們的地址。因此，操作員應創建一個服務并將服務地址與數據庫名稱相關聯。這是 ETL 系統的一部分。這個想法是，操作員可以通過處理大部分配置來輕松部署整個系統。考慮到這一點，我們正在考慮是否不可能選擇現有的Helm運算符（或其他類型的運算符）并通過對配置進行小的修改來部署它們，例如不同數據庫的不同端口。但在閱讀了F1ko的回復后，我獲得了新的視角。也許這不可能像最初預期的那樣與操作員一起實現？
1 回答
阿波羅的戰車
TA貢獻1862條經驗 獲得超6個贊
僅用于澄清目的：
Helm是一個包管理器，您可以使用它以捆綁的方式將應用程序安裝到集群上：它基本上為您提供了所有必要的YAML，例如ConfigMaps，Services，Deployments以及以正確方式啟動和運行所需應用程序所需的任何其他內容。
操作員本質上是一個控制器。在 Kubernetes 中，每當您執行某些操作時，都有許多不同的控制器定義“邏輯”（例如，如果您決定增加字段，則復制控制器會添加更多 Pod 的復制）。有太多的控制器無法將它們全部列出并單獨運行，這就是為什么它們被編譯成一個稱為kube-controller-manager的二進制文件。定制的控制器稱為運算符，以便于區分。這些操作員只是監視某些“事物”的狀態，并在需要時執行操作。大多數時候，這些“東西”將是CustomResources（CR），本質上是通過應用CustomResourceDefinitions（CRD）引入集群的新Kubernetes對象。
replicas
話雖如此，使用舵柄來部署操作員并不罕見，但是，盡量避免使用術語“舵機操作員”，因為它實際上指的是非常具體的操作員，并且可能導致將來的混淆：https://github.com/fluxcd/helm-operator
所以我的問題是，我們能以某種方式在操作員內部使用這些頭盔操作員嗎？
雖然您可以使用operator-sdk構建自己的運算符，然后允許您部署或觸發來自其他運算符的某些事件（例如，通過編輯其CRD），但沒有理由這樣做。
到目前為止，我能想到的唯一方法是從部署應用中調用 helm setup 控制臺命令。
您正在尋找的很可能是正確的 CI/CD 工作流。只需提交您在 Git 存儲庫中使用的 helm 圖表和 values.yaml 文件，并在每次進行新提交時讓 CI/CD 工具（如 GitLab）將它們部署到您的集群中。helm install
更新：由于另一個人編輯了他的問題并留下了評論，我決定更新這篇文章：
該運算符的主要目的是部署 X 數據庫。除此之外，我們希望有一個可以立即部署整個系統的單個運算符/捆綁包。
您認為將運算符捆綁在另一個運算符中是否有意義，就像使用 Helm 一樣？
不，它根本沒有意義。這正是掌舵的用途。使用helm，您可以捆綁東西，甚至可以將多個helm圖表捆綁在一起，這可能是您真正想要的。您可以有一個舵手圖，將所需的值向下傳遞到實際的操作員舵手圖，因此在多個位置使用類似于服務名稱的內容。
對于操作員內部的操作員，在配置操作員時是否仍需要單獨配置每個子操作員？
如上所述，這樣做沒有任何意義，它只是一種過度設計的方法。但是，如果您真的想采用操作員方法，基本上可以采用兩種方法：
編寫一個運算符，通過更改其他運算符的 CR、ConfigMaps 等來配置其他運算符;使用這種方法，您將擁有一個有點輕量級的操作員，但是您必須確保它始終與您希望它干擾的所有不同操作員兼容（當他們更改為具有重大更改的新CR，引入新的CR或類似的東西時，您將不得不再次適應）。
apiVersion將整個邏輯從現有運算符中提取到運算符中（即重建已經存在的東西）;使用這種方法，您將擁有一個大型的整體式應用程序，維護起來將非常痛苦，因為每當上游運算符中有更新時，您都必須不斷更新代碼
希望現在已經很清楚，為“操作”其他運算符構建自己的運算符會帶來很多痛苦的依賴關系，不應該是要走的路。
是否可以部署不同的映像配置？例如，數據庫配置了不同的端口？
好的運算符和舵手圖可以讓您開箱即用地執行此操作，無論是通過相應的CR / ConfigMap還是文件，但是，現在這取決于您將要使用的解決方案。因此，一般來說，答案是：是的，如果支持，這是可能的。values.yaml
- 1 回答
- 0 關注
- 181 瀏覽
添加回答
舉報
0/150
提交
取消