5 ms·

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 deployi

by pm90 9y ago

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

elsonrodriguez 9y ago
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 9y ago
  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 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.
alpb 9y ago
The main difference of Operators is explained here https://coreos.com/blog/introducing-operators.html 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 https://github.com/ianlewis/memcached-operator.
mfer 9y ago
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-tools/ https://codeengineered.com/blog/2018/kubernetes-helm-related...
- nikolay 9y ago
  Any plans to switch from templatized YAML to Jsonnet/Ksonnet?
  - bryanlarsen 9y ago
    The helm 3 proposal uses Lua. Not sure if they've actually started working on it: https://github.com/kubernetes-helm/community/blob/master/helm-v3/000-helm-v3.md https://github.com/kubernetes-helm/community/blob/master/hel...
    - nikolay 9y ago
      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!
      - hobofan 9y ago
        > but it's not mainstream, and it's not going to be! Why are you suggesting jsonnet then?
        nikolay 9y ago
        Because it's popular in Kubernetes and makes sense, unlike Lua in the context.
      - mfer 9y ago
        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.
streetcat1 9y ago
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.

by pm90 9y ago

elsonrodriguez 9y ago

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 9y ago
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 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.

alpb 9y ago

The main difference of Operators is explained here https://coreos.com/blog/introducing-operators.html 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 https://github.com/ianlewis/memcached-operator.

mfer 9y ago

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-tools/ https://codeengineered.com/blog/2018/kubernetes-helm-related...

nikolay 9y ago
Any plans to switch from templatized YAML to Jsonnet/Ksonnet?
- bryanlarsen 9y ago
  The helm 3 proposal uses Lua. Not sure if they've actually started working on it: https://github.com/kubernetes-helm/community/blob/master/helm-v3/000-helm-v3.md https://github.com/kubernetes-helm/community/blob/master/hel...
  - nikolay 9y ago
    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!
    - hobofan 9y ago
      > but it's not mainstream, and it's not going to be! Why are you suggesting jsonnet then?
      - nikolay 9y ago
        Because it's popular in Kubernetes and makes sense, unlike Lua in the context.
    - mfer 9y ago
      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.

streetcat1 9y ago

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.