在 Operator SDK 中混合使用实现语言 - Helm、Go、Ansible

Question

我需要将多个容器部署到 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的回复后，我获得了新的视角。也许这不可能像最初预期的那样与操作员一起实现？

Answer 1

仅用于澄清目的：

• 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