You can think of K8s Controllers/Operators as a way to extend the K8s API at runtime with a new type of object that is managed by a controller you've written yourself (as opposed to the built in k8s objects that are handled by the default controller-manager).
A Helm chart by comparison is a way to template out K8s objects to make them configurable for different environments.
Some shops will end up combining one with the other.
And that’s why the team created a Helm-operator based on Lostromos (a tool for expanding Helm charts without running a tillers erver) that makes it easy to use a Helm chart for templating but still add additional lifecycle on top:
Comments
You can think of K8s Controllers/Operators as a way to extend the K8s API at runtime with a new type of object that is managed by a controller you've written yourself (as opposed to the built in k8s objects that are handled by the default controller-manager).
A Helm chart by comparison is a way to template out K8s objects to make them configurable for different environments.
Some shops will end up combining one with the other.
And that’s why the team created a Helm-operator based on Lostromos (a tool for expanding Helm charts without running a tillers erver) that makes it easy to use a Helm chart for templating but still add additional lifecycle on top:
https://github.com/operator-framework/helm-app-operator-kit
The templating aspect of Helm and the set of quality content is complementary to being able to add higher level lifecycle.