Helm就像一个软件包管理器。它可以在你的集群上安装应用程序，但是它只有一些基本的逻辑来更新它的配置或者升级版本。你可以通过helm命令来控制它，并且在你需要的时候调用它。所以它可以帮助你完成一些任务，但是它仍然取决于你每天运行你的Kafka集群。
另一方面，运算符是（通常）更复杂。它们不仅处理安装，而且还处理“第二天的操作”。它们本质上试图将运行类似Kafka集群的人类操作员所需的知识和任务编码到应用程序中（= the operator）. operator一直在你的集群中运行，不断地监视Kafka集群，看看里面发生了什么，如果应该采取一些行动，对于类似Kafka的事物，Strimzi操作符例如结合了滚动更新知识，诸如控制器代理应当最后滚动并且分区副本保持同步，它处理在Kafka中通常包括多个滚动更新的升级、处理证书续订等等。
因此，操作员通常会为您做更多的事情比Helm图表，因为它为您操作Kafka集群。对于有状态的应用程序，如Kafka或例如数据库，这往往会产生巨大的不同。但它通常也更固执己见，因为它做事情的方式，它的编程，这可能是不同于你习惯。舵手图表通常给予你很大的自由去做任何你想做的事情。

• 注意：不同的运营商有不同的功能和成熟度。因此他们可能支持也可能不支持不同的任务。*

如果你在谷歌上搜索它，你会发现许多关于 *Kubernetes算子模式 * 的不同文章、视频或会议讨论，并将其与Helm Charts进行比较，后者将解释差异。

• （免责声明：我是Strimzi项目维护人员之一）*

关于舵手图与操作员的一些一般性想法：
Helm图表直接包含了使用Go语言text/template编写的Kubernetes YAML文件，而运算符则包含了实际的代码，这些代码通常是使用Kubernetes SDK编写的，它们创建了相同的对象。
如果你要安装一些应用程序，使用Helm图表，可以检查图表或使用helm template之类的工具来查看它要做什么。你对操作符没有这样的控制级别：您可以为它分配一些非常广泛的权限来创建和编辑StatesulSets和Secrets，它将执行一些操作。如果某些配置出错，Helm图表将很快明显失败，但操作员只能通过其自定义资源中的status:报告其状态，因此，如果操作员不工作，您对出错原因的可见性有限。
作为一个实现者，如果您已经熟悉Kubernetes YAML语法，那么将其转换为Helm图表是一个非常简单的过程。并且可以编写任意复杂的逻辑。测试模板化的逻辑变得很棘手。您还需要小心地管理模板输出中的空格和YAML布局问题。一旦您既然已经达到了这种复杂程度，Go原生testing包以及Kubebuilder等包中的支持工具使测试操作员变得更加容易。
操作员和控制器确实有一些额外的能力。他们运行任意代码，可以编辑集群中的对象（给定正确的RBAC权限），可以检查外部状态，并在初始安装后保持运行。通过让一个操作员创建触发另一个操作员的资源，这对分层操作员来说很简单（就像在标准Kubernetes中一样，Deployment创建ReplicaSets，ReplicaSets创建Pod）Helm的依赖关系系统定义得稍微健壮一些，但当您尝试嵌套依赖关系时会遇到麻烦。
如果你的大部分环境都是Helm，那么选择Helm图表可能是有意义的。像Helmfile这样的工具可以让安装多个Helm图表变得更直接。如果你还没有投资Helm，正在使用其他工具，并且你不介意看不到操作员在做什么，那么控制器可能更容易使用。
(In我的日常工作是维护Helm图表和自定义运算符。我的应用程序使用Kafka，但我不维护Kafka安装。我们面向Helmfile的开发人员安装程序使用Helm图表安装Kafka。）