[pm90]

Can anyone talk about the positives/negatives of Operators v/s Helm Charts?

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).

[mfer]

Helm and Community Charts maintainer here...

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...

[nikolay]

Any plans to switch from templatized YAML to Jsonnet/Ksonnet?

[bryanlarsen]

The helm 3 proposal uses Lua. Not sure if they've actually started working on it: https://github.com/kubernetes-helm/community/blob/master/hel...

[nikolay]

Honestly, this is a terrible choice! I like Lua, but it's not mainstream, and it's not going to be! There are tons of embeddable JavaScript engines - they could've used TypeScript, too!

[mfer]

Let me try to add a little color here.

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.

[hobofan]

> but it's not mainstream, and it's not going to be!

Why are you suggesting jsonnet then?

[nikolay]

Because it's popular in Kubernetes and makes sense, unlike Lua in the context.

[mfer]

> Any plans to switch from templatized YAML to Jsonnet/Ksonnet?

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.

[nikolay]

Ksonnet might be under active development, but Jsonnet is stable. YAML + Jinja2 is a dirty workaround - you can't even guarantee valid YAML with it as to Jinja2, everything's just text unlike with Jsonnet.

[streetcat1]

To understand operators you should think differently about k8s. I.e. as it core, k8s is a distributed messaging queue, where the messages are in the form of a declarative desired state (defined by yaml file) of a thing.

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.

[alpb]

The main difference of Operators is explained here https://coreos.com/blog/introducing-operators.html Operators basically encapsulate human operational knowledge on a particular system, like how do you run a Memcached Ring on Kubernetes capsulated by https://github.com/ianlewis/memcached-operator.

[elsonrodriguez]

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.

[smarterclayton]

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.