在 Operator SDK 中混合使用实现语言

仅用于澄清目的：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

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

1回答