From what I see, it seems like Operators are a better tool for defining and deploying Custom k8s resources whereas helm charts are good way to organize applications (deployment, service etc. templates packaged into one tar).
Helm is a package manager. Think of it like apt for Kubernetes.
Operators enable you to manage the operation of applications within Kubernetes.
They are complementary. You can deploy an operator as part of a Helm Chart. I recently wrote a blog post that explains how the different tools relate. https://codeengineered.com/blog/2018/kubernetes-helm-related...
Lua support is NOT being added for templating. It's being added to enable extensions in charts (a new thing) and for cross platform plugins. Existing style plugins will still work. This is providing some extras to help enable more cross platform work.
There are a couple reasons Lua was chosen and documentation has been written up as well.
1. There are go packages for this so we can do it in a cross platform manner (mac/win/linux/bsd/etc). Helm is used on many platforms.
2. Security issues, especially with extensions to charts, have a path forward to address. In a similar way to how we opt-in for apps to use features on cell phones we can do that for features used in extensions.
The people who did the analysis has embedded JS engines in applications recently. They are aware of the benefits, pitfalls, and how it all works.
Why are you suggesting jsonnet then?
Not exactly. Two things to know...
First, a little history.
Only a tiny amount of people have asked for it. A prototype was created and no one, not even the ksonnet devs, were up for taking the work forward from the prototype phase. The code is still up on GitHub and Helm was built with the intent of more engines being used.
Second, ksonnet is going through some major changes right now. We can all come back and look on it again when it's ready.
Helm 3 is working to make it easier to bring your own tools, like jsonnet. It's just not likely to be baked in or replace YAML. People really aren't asking for it much.
The operator (or to be more precise one or more controllers) listen to those messages and try to reconcile the desired state with the current state.
So an operator is a combination of the message types and the controllers that take of the reconciliation process.
Taking this point of view, k8s is much more than container orchestration framework. I.e. it can orchestrate anything in the real world, as long as there is a way to define the desired state of a thing and a controller that can affect the real world.
Back to the original question. Helm was created in order to raise the abstraction of resource definition (I.e. the desired state) from plain yaml to property file which is much more readable and smaller. Along the way, it also became a packaging tool.
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.
The templating aspect of Helm and the set of quality content is complementary to being able to add higher level lifecycle.