任何人都可以简单地解释一下通过 Kubernetes Operator(例如 Strimzi )部署 Kafka 与 Kafka helm 图表或 list 文件有什么区别？
之前在我的项目中，我们使用 kafka 的 helm 图表，但现在我们收到了迁移到 kafka strimzi-operator 的要求。我无法联系到发明它的人，但我的同事也不知道原因。
那么请解释一下为什么 kafka strimzi 操作符比 kafka helm Chart 更好(或者可能更差)？
最佳答案
Helm 就像一个包管理器。它可以在您的集群上安装应用程序，但它只有一些用于更新其配置或版本升级的基本逻辑。您可以通过 helm 命令控制它，并在需要时调用它。因此它可以帮助您完成一些任务，但日常运行 Kafka 集群仍然取决于您。
另一方面，运算符(operator)(通常)更加复杂。他们不仅处理安装，还处理第二天的操作。他们本质上是尝试将运行 Kafka 集群之类的运算符(operator)所需的知识和任务编码到应用程序(= 运算符(operator))中。该运算符(operator)始终在您的集群中运行，并不断监视 Kafka 集群以查看其中发生了什么、是否应该采取某些操作等等。对于像 Kafka 这样的东西，Strimzi 运算符结合了滚动更新知识，例如 Controller 代理应该最后滚动并且分区副本保持同步，它处理在 Kafka 中通常由多个滚动更新组成的升级，处理证书更新等等。
因此，运算符(operator)通常会为您做比 Helm Chart 更多的事情，因为它为您操作 Kafka 集群。对于 Kafka 等有状态应用程序或数据库来说，这通常会产生巨大的差异。但它通常也更加固执己见，因为它按照编程的方式做事，这可能与您习惯的不同。 Helm Charts 通常会给您很大的自由度，让您可以按照自己的方式做事。
注意:不同的运营商有不同的功能和成熟度。因此它们可能支持也可能不支持不同的任务。
如果您用 google 搜索，您会发现许多关于 Kubernetes 运算符模式的不同文章、视频或 session 演讲，并将其与 Helm Charts 进行比较，这将解释其中的差异。
(免责声明:我是 Strimzi 项目维护者之一)
关于kubernetes - Kafka Operator 与 Kafka Helm Chart 之间的区别，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/75695295/