在 Operator SDK 中混合实现语言 - Helm、Go、Ansible
Mix implementation languages in Operator SDK - Helm, Go, Ansible
我需要将多个容器部署到 Kubernetes 集群。目标是自动部署 Kafka、Kafka Connect、PostgreSQL 等。其中一些已经提供了我们可以使用的 Helm 操作符。所以我的问题是，我们能否以某种方式在我们的操作员中使用这些 helm 操作员？如果是这样，最好的方法是什么？
到目前为止我能想到的唯一方法是从部署应用程序中调用 helm 设置控制台命令。
不使用这些 helm 文件的另一种方法是在我自己的操作符中实现每个操作符的功能，这似乎没有多大意义，因为我需要的已经开发出来并且是 public.
我对运算符开发还很陌生，所以如果这是一个愚蠢的问题，请原谅。
编辑：
操作员的主要目的是部署 X 数据库。除此之外，我们还希望有一个 operator/bundle 可以立即部署整个系统。即使我们对某些容器有额外的任务，使用操作符进行捆绑是否有意义？这样，用户将在 yaml 文件中指定：
databases
- type: "postgres"
name: "users"
- type: "postgres"
name: "purchases"
将创建 2 个 PostgreSQL 数据库。然后可以在其他 yaml 文件中或在同一 yaml 文件中进一步提及这些数据库。现有案例：来自数据库的信息将由 Debezium（另一个容器）提取，因此 Debezium 需要知道它们的地址。所以运营商应该创建一个服务，并将服务地址与数据库名称相关联。
这是 ETL 系统的一部分。这个想法是，操作员可以通过处理大部分配置来轻松部署整个系统。
考虑到这一点，我们在考虑是否有可能选择现有的 Helm 操作员（或其他类型的操作员）并通过对配置进行小的修改来部署它们，例如不同数据库的不同端口。
但是看了F1ko的回复我又有了新的看法。也许这对于最初预期的操作员来说是不可能的？
Edit2: edit1 的澄清。
仅供说明：
Helm 是一个包管理器，您可以使用它以捆绑方式将应用程序安装到集群上：它基本上为您提供了所有必要的 YAML，例如 ConfigMaps、Services、Deployments 等需要 else 才能以正确的方式启动所需的应用程序和 运行。
操作员本质上是一个控制器。在 Kubernetes 中，有许多不同的控制器在您做某事时定义“逻辑”（例如，如果您决定增加 replicas 字段，复制控制器会添加更多 Pod 副本）。控制器实在是太多了，无法一一列举 运行，这就是为什么它们被编译成一个称为 kube-controller-manager 的二进制文件的原因。
定制的控制器被称为操作员，以便于区分。这些操作员只是监视某些“事物”的状态，并在需要时执行操作。大多数时候，这些“东西”将是 CustomResources (CRs)，它们本质上是通过应用 CustomResourceDefinitions (CRDs) 引入集群的新 Kubernetes 对象。
话虽如此，使用 helm 来部署操作员并不少见，但是，请尽量避免使用“helm 操作员”一词，因为它实际上指的是一个非常具体的操作员，将来可能会造成混淆: https://github.com/fluxcd/helm-operator
So my question is, can we somehow use those helm operators inside our operator?
虽然您可以使用 operator-sdk 构建自己的操作员，然后让您部署或触发其他操作员的某些事件（例如，通过编辑他们的 CRD），但没有理由这样做。
The only method I can think of so far is calling the helm setup console commands from within a deployment app.
很可能您正在寻找的是正确的 CI/CD 工作流程。
每次提交新提交时，只需提交 helm chart 和 values.yaml files that you are using during helm install inside a Git repository and have a CI/CD tool (such as GitLab) 将它们部署到您的集群。
更新： 由于对方编辑了他的问题并发表了评论，我决定更新此 post：
The main purpose of the operator is to deploy X databases. Along with that we would like to have a single operator/bundle that deploys the whole system right away.
Do you think it makes sense to bundle operators together in another operator, as one would do with Helm?
不，这根本没有意义。这正是 helm 的用途。使用 helm 你可以捆绑东西，你甚至可以将多个 helm 图表捆绑在一起，这可能是你真正想要的。您可以拥有一个 helm chart，将所需的值传递给实际的操作员 helm chart，因此可以在多个位置使用类似服务名称的内容。
In the case of operators inside operators, is it still necessary to configure every sub-operator individually when configuring the operator?
如上所述，那样做没有任何意义，只是一种过度设计的方法。但是，如果您真的想使用运算符方法，基本上可以采用两种方法：
- 编写一个操作符，通过更改其他操作符的 CR、ConfigMap 等来配置其他操作符；通过这种方法，您将拥有一个 有点 轻量级运算符，但是您必须确保它始终与您希望它干扰的所有不同运算符兼容（当它们更改为一个新的
apiVersion 具有重大变化，引入新的 CR 或任何类似的东西，你将不得不重新适应）。
- 将现有运算符的整个逻辑提取到您的运算符中（即重建已经存在的东西）；使用这种方法，您将拥有一个庞大的单体应用程序，维护起来会非常痛苦，因为只要上游运算符有更新，您就必须不断更新代码
希望现在已经清楚，为“操作”其他操作符而构建自己的操作符会带来很多痛苦的依赖关系，不应该是这样。
Is it possible to deploy different configurations of images? Such as databases configured with different ports?
好的操作员和 helm 图表可以让您通过相应的 CR / ConfigMap 或 values.yaml 文件开箱即用，但是，这现在取决于您要使用的解决方案。所以总的来说答案是：是的，如果支持的话是可以的。
我需要将多个容器部署到 Kubernetes 集群。目标是自动部署 Kafka、Kafka Connect、PostgreSQL 等。其中一些已经提供了我们可以使用的 Helm 操作符。所以我的问题是，我们能否以某种方式在我们的操作员中使用这些 helm 操作员？如果是这样，最好的方法是什么？
到目前为止我能想到的唯一方法是从部署应用程序中调用 helm 设置控制台命令。 不使用这些 helm 文件的另一种方法是在我自己的操作符中实现每个操作符的功能，这似乎没有多大意义，因为我需要的已经开发出来并且是 public.
我对运算符开发还很陌生，所以如果这是一个愚蠢的问题，请原谅。
编辑： 操作员的主要目的是部署 X 数据库。除此之外，我们还希望有一个 operator/bundle 可以立即部署整个系统。即使我们对某些容器有额外的任务，使用操作符进行捆绑是否有意义？这样，用户将在 yaml 文件中指定：
databases
- type: "postgres"
name: "users"
- type: "postgres"
name: "purchases"
将创建 2 个 PostgreSQL 数据库。然后可以在其他 yaml 文件中或在同一 yaml 文件中进一步提及这些数据库。现有案例：来自数据库的信息将由 Debezium（另一个容器）提取，因此 Debezium 需要知道它们的地址。所以运营商应该创建一个服务，并将服务地址与数据库名称相关联。
这是 ETL 系统的一部分。这个想法是，操作员可以通过处理大部分配置来轻松部署整个系统。 考虑到这一点，我们在考虑是否有可能选择现有的 Helm 操作员（或其他类型的操作员）并通过对配置进行小的修改来部署它们，例如不同数据库的不同端口。
但是看了F1ko的回复我又有了新的看法。也许这对于最初预期的操作员来说是不可能的？
Edit2: edit1 的澄清。
仅供说明：
Helm 是一个包管理器，您可以使用它以捆绑方式将应用程序安装到集群上：它基本上为您提供了所有必要的 YAML，例如 ConfigMaps、Services、Deployments 等需要 else 才能以正确的方式启动所需的应用程序和 运行。
操作员本质上是一个控制器。在 Kubernetes 中，有许多不同的控制器在您做某事时定义“逻辑”（例如，如果您决定增加
replicas字段，复制控制器会添加更多 Pod 副本）。控制器实在是太多了，无法一一列举 运行，这就是为什么它们被编译成一个称为 kube-controller-manager 的二进制文件的原因。 定制的控制器被称为操作员，以便于区分。这些操作员只是监视某些“事物”的状态，并在需要时执行操作。大多数时候，这些“东西”将是 CustomResources (CRs)，它们本质上是通过应用 CustomResourceDefinitions (CRDs) 引入集群的新 Kubernetes 对象。
话虽如此，使用 helm 来部署操作员并不少见，但是，请尽量避免使用“helm 操作员”一词，因为它实际上指的是一个非常具体的操作员，将来可能会造成混淆: https://github.com/fluxcd/helm-operator
So my question is, can we somehow use those helm operators inside our operator?
虽然您可以使用 operator-sdk 构建自己的操作员，然后让您部署或触发其他操作员的某些事件（例如，通过编辑他们的 CRD），但没有理由这样做。
The only method I can think of so far is calling the helm setup console commands from within a deployment app.
很可能您正在寻找的是正确的 CI/CD 工作流程。
每次提交新提交时，只需提交 helm chart 和 values.yaml files that you are using during helm install inside a Git repository and have a CI/CD tool (such as GitLab) 将它们部署到您的集群。
更新： 由于对方编辑了他的问题并发表了评论，我决定更新此 post：
The main purpose of the operator is to deploy X databases. Along with that we would like to have a single operator/bundle that deploys the whole system right away.
Do you think it makes sense to bundle operators together in another operator, as one would do with Helm?
不，这根本没有意义。这正是 helm 的用途。使用 helm 你可以捆绑东西，你甚至可以将多个 helm 图表捆绑在一起，这可能是你真正想要的。您可以拥有一个 helm chart，将所需的值传递给实际的操作员 helm chart，因此可以在多个位置使用类似服务名称的内容。
In the case of operators inside operators, is it still necessary to configure every sub-operator individually when configuring the operator?
如上所述，那样做没有任何意义，只是一种过度设计的方法。但是，如果您真的想使用运算符方法，基本上可以采用两种方法：
- 编写一个操作符，通过更改其他操作符的 CR、ConfigMap 等来配置其他操作符；通过这种方法，您将拥有一个 有点 轻量级运算符，但是您必须确保它始终与您希望它干扰的所有不同运算符兼容（当它们更改为一个新的
apiVersion具有重大变化，引入新的 CR 或任何类似的东西，你将不得不重新适应）。 - 将现有运算符的整个逻辑提取到您的运算符中（即重建已经存在的东西）；使用这种方法，您将拥有一个庞大的单体应用程序，维护起来会非常痛苦，因为只要上游运算符有更新，您就必须不断更新代码
希望现在已经清楚，为“操作”其他操作符而构建自己的操作符会带来很多痛苦的依赖关系，不应该是这样。
Is it possible to deploy different configurations of images? Such as databases configured with different ports?
好的操作员和 helm 图表可以让您通过相应的 CR / ConfigMap 或 values.yaml 文件开箱即用，但是，这现在取决于您要使用的解决方案。所以总的来说答案是：是的，如果支持的话是可以的。