<p>Can anyone explain in simple terms what is the difference between deploying Kafka through Kubernetes operator (for example Strimzi ) and Kafka helm chart or manifest file?</p>
<p>Previously in my project we used helm chart for kafka but for now we've received requirement to move to kafka strimzi-operator. I can't access people who invented it but my colleguess also don't know the reason.</p>
<p>So please explain why kafka strimzi operator better (or maybe worse) than kafka helm chart ?</p>

<p>Some generic thoughts on Helm charts vs. operators:</p>
<p>A Helm chart directly includes Kubernetes YAML files using the Go <a href="https://pkg.go.dev/text/template" rel="nofollow noreferrer"><code>text/template</code></a> language.  An operator has actual code, frequently written in Go using the <a href="https://kubernetes.io/docs/reference/using-api/client-libraries/" rel="nofollow noreferrer">Kubernetes SDK</a>, that creates the same objects.</p>
<p>If you're going to install some application, using a Helm chart it's possible to inspect the chart or use a tool like <code>helm template</code> to see what it's going to do.  You do not have that level of control over an operator: you can assign it some very broad permissions to create and edit StatesulSets and Secrets and it will do...something.  A Helm chart will visibly fail quickly if some configuration is wrong, but an operator can only report its state via the <code>status:</code> in its custom resources, so you can have limited visibility into what's going wrong if an operator isn't working.</p>
<p>As an implementer, if you're familiar with the Kubernetes YAML syntax already, it's a straightforward transition to turn it into a Helm chart.  The template language is Turing-complete, though, and it's possible to write arbitrarily complex logic.  Testing the templated logic becomes tricky.  You also need to carefully manage whitespace and YAML layout concerns in the output of your templates.  Once you've gotten up to this level of complexity, the Go native <code>testing</code> package with the support tools in packages like <a href="https://kubebuilder.io" rel="nofollow noreferrer">Kubebuilder</a> make testing an operator much easier.</p>
<p>Operators and controllers do have some additional capabilities.  They run arbitrary code, can edit objects in the cluster (given the right RBAC permissions), can inspect external state, and keep running after the initial installation.  It is straightforward to layer operators by having one operator create the resource that triggers another (as in standard Kubernetes where a Deployment creates ReplicaSets which create Pods).  Helm's dependency system is a little more robustly defined, but runs into trouble when you do try to have nested dependencies.</p>
<p>If most of your environment is in Helm anyways, it might make sense to prefer Helm charts for everything.  Tools like <a href="https://helmfile.readthedocs.org" rel="nofollow noreferrer">Helmfile</a> can make installing multiple Helm charts more straightfoward.  If you're not already invested in Helm and are using other tools, and you don't mind not being able to see what the operator is doing, then a controller will be likely be simpler to use.</p>
<p>(In my day job, I maintain both Helm charts and custom operators.  My application uses Kafka, but I do not maintain the Kafka installation.  Our Helmfile-oriented developer setup installs Kafka using a Helm chart.)</p>
