Hello Helm Team,

We are using Helm in our product for the deployments and upgrade. We are looking at the next step of introducing the Kubernetes Operator for handling the Day 2 Operations.

Going through this page we see that Helm does not support complete Operator capability level:https://sdk.operatorframework.io/docs/overview/operator-capabilities/

Could someone let me know if Helm has a plan to support the complete Operator maturity level on the roadmap as we see with Ansible and Go.

Thanks and Regards,

Anil Kumar

I’d like to add to what Paul said.

Helm and operators are two different types of things. They don’t solve the same problem. Think of it this way, would I ask apt or yum to implement ansible features? The answer is obviously no because they solve two different problems and can be used to compliment each other. Ansible regularly uses RPMs and Debian packages.

Helm is a package manager like apt or yum. It is used to install, upgrade, and uninstall packages.

Operators are more complex. To quote the original definition of operators…

An Operator is an application-specific controller that extends the Kubernetes API to create, configure, and manage instances of complex stateful applications on behalf of a Kubernetes user. It builds upon the basic Kubernetes resource and controller concepts but includes domain or application-specific knowledge to automate common tasks.

It’s about managing instances of applications. This reminds me of something like ansible or Chef. It’s more like Chef conceptually because Chef did things with agents and a pull based model.

These two can complement each other. An operator can use Helm and charts for the install, upgrade, and uninstall elements. In fact, some do.

So, I would not expect to have Helm support operator capabilities because they solve different problems. The fact that they’re compared that way is marketing rather than technical.

- Matt Farina

On Oct 6, 2021, at 11:31 AM, Paul C <username.taken@...> wrote:

The complete Operator capability level is a bit of a misnomer and very self serving and are often not operator specific, but assume the operator writer has implemented extra things. There not really much there that a well written Helm Chart can't/won't do.  

* Full lifecycle -  Assuming the app is fairly cloud native the kube controllers (deployment/statefulset/etc) will manage most failure recoveries, and jobs/cronjobs for backups, and helm hooks for assisting with upgrade tasks.  

* Deep insight - this isn't really an operator thing, except for the fact an operator can automatically set up prometheus (and similar) servicemonitors/alerts etc, all things you can do with your helm charts

* Auto Pilot - most of the auto-scaling can be done with kube HPA/VPA and similar techniques, I've seens cronjobs used to do scheduled scaling as well, abnormality detection etc can be done as easily with a sidecar application as it can with an operator.

On Wed, Oct 6, 2021 at 3:53 AM Anil Kumar <anil181@...> wrote:

Hello Helm Team,

We are using Helm in our product for the deployments and upgrade. We are looking at the next step of introducing the Kubernetes Operator for handling the Day 2 Operations.

Going through this page we see that Helm does not support complete Operator capability level:https://sdk.operatorframework.io/docs/overview/operator-capabilities/

Could someone let me know if Helm has a plan to support the complete Operator maturity level on the roadmap as we see with Ansible and Go.

Thanks and Regards,

Anil Kumar

Thanks for providing clarification with…

The "Operator Capability Levels" you reference are comparing helm-based operators, ansible-based operators, and go-based operators as supported by the operator-sdk.

I think there are a couple problems here, though.

1. People are taking the levels as Helm stand alone vs operators in general. This has come up in numerous conversations. It appears to be a point of confusion. How can we work to clear that up?
2. The community has taken the model far further than Operator SDK based. The operator working group included it as a general thing in their white paper on operators. This model is being applied outside its intended space, as you have said the space is. How can the communication be updated to help clear that up?
3. The OperatorHub website uses the model and says it’s for operators. It does not clarify that it’s for Operator SDK based operators. There are many non-Operator SDK based operators. This, I think, leads to the confusion in messaging.

Do you see why people are confused on the topic?

- Matt Farina

On Oct 6, 2021, at 4:10 PM, Michael Hrivnak <mhrivnak@...> wrote:

The "Operator Capability Levels" you reference are comparing helm-based operators, ansible-based operators, and go-based operators as supported by the operator-sdk. Those are the three operator types that operator-sdk can help you make. The capability levels *do not* draw a comparison of operators vs. helm.

For very brief background: the operator-sdk enables you to use a helm chart as the basis for a simple operator, with no coding required. You get a CRD to represent your operand, and a controller that applies the chart during reconciliation. That can be useful, but the resulting operator is limited to whatever the chart can do.

Michael

On Wed, Oct 6, 2021 at 3:07 PM Matt Farina <matt@...> wrote:

I’d like to add to what Paul said.

Helm and operators are two different types of things. They don’t solve the same problem. Think of it this way, would I ask apt or yum to implement ansible features? The answer is obviously no because they solve two different problems and can be used to compliment each other. Ansible regularly uses RPMs and Debian packages.

Helm is a package manager like apt or yum. It is used to install, upgrade, and uninstall packages.

Operators are more complex. To quote the original definition of operators…

An Operator is an application-specific controller that extends the Kubernetes API to create, configure, and manage instances of complex stateful applications on behalf of a Kubernetes user. It builds upon the basic Kubernetes resource and controller concepts but includes domain or application-specific knowledge to automate common tasks.

It’s about managing instances of applications. This reminds me of something like ansible or Chef. It’s more like Chef conceptually because Chef did things with agents and a pull based model.

These two can complement each other. An operator can use Helm and charts for the install, upgrade, and uninstall elements. In fact, some do.

So, I would not expect to have Helm support operator capabilities because they solve different problems. The fact that they’re compared that way is marketing rather than technical.

- Matt Farina

On Oct 6, 2021, at 11:31 AM, Paul C <username.taken@...> wrote:

The complete Operator capability level is a bit of a misnomer and very self serving and are often not operator specific, but assume the operator writer has implemented extra things. There not really much there that a well written Helm Chart can't/won't do.  

* Full lifecycle -  Assuming the app is fairly cloud native the kube controllers (deployment/statefulset/etc) will manage most failure recoveries, and jobs/cronjobs for backups, and helm hooks for assisting with upgrade tasks.  

* Deep insight - this isn't really an operator thing, except for the fact an operator can automatically set up prometheus (and similar) servicemonitors/alerts etc, all things you can do with your helm charts

* Auto Pilot - most of the auto-scaling can be done with kube HPA/VPA and similar techniques, I've seens cronjobs used to do scheduled scaling as well, abnormality detection etc can be done as easily with a sidecar application as it can with an operator.

On Wed, Oct 6, 2021 at 3:53 AM Anil Kumar <anil181@...> wrote:

Hello Helm Team,

We are using Helm in our product for the deployments and upgrade. We are looking at the next step of introducing the Kubernetes Operator for handling the Day 2 Operations.

Going through this page we see that Helm does not support complete Operator capability level:https://sdk.operatorframework.io/docs/overview/operator-capabilities/

Could someone let me know if Helm has a plan to support the complete Operator maturity level on the roadmap as we see with Ansible and Go.

Thanks and Regards,

Anil Kumar

-- 

Michael Hrivnak

Senior Principal Software Engineer, RHCE 

Red Hat