should we provide an operator instead of a helm-chart?

[wkloucek]

Operators have possibilites, that a helm-chart doesn't have: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

More resources:

• https://www.techtarget.com/searchitoperations/tip/When-to-use-Kubernetes-operators-vs-Helm-charts
• https://www.youtube.com/watch?v=sxHdwO52P-o

There is the Operator SDK that allows one to package a Helm chart as operator or program the operator in Go. We could start with the Helm operator and transition (rewrite) the operator in Go, if we need so.

Transportability of operators between different Kubernetes distributions is mainly dependent on the Resource Classes, one uses (just like in Helm charts).

We could use the operator for maintenance tasks as:

• generating secrets & certificates if not provided (this is hard with plain Helm)
• certificate rotation (this is hard with plain Helm)
• backup & restore
• migration

Operator examples to look at:

• etcd operatorhttps://github.com/coreos/etcd-operator (but is archived)
• Red Hat CodeReady Workspaces, but where does the Code live?

[PixelJonas]

Hey ;)

just in the process of (still trying) to deploy these charts on my local Kubernetes. I'm happy to enable you in using the operator-sdk if you decide to move this issue further.

please reach out to me if you need any help

The upstream code for CodeReady Workspaces is the eclipse-che project. You can find the code for the operator here: https://github.com/eclipse-che/che-operator

[Deaddy]

To answer the question in the heading: no. Operators should not be used as substitute for helm charts.

The etcd operator and similar (stolon, databases etc.) made[^1] sense when providing cloud infrastructure to other tenants and you want to offer them "one click clusters", where they can just push a button in some webinterface and then all the webinterface needs to do is to create the operator crd and the operator spins up the cluster for them.

This works fine in simple service clusters like Galera oder etcd, but to provide an ownCloud to a group of users one also usually needs to connect it to some IDM and have group settings and what not, so any generalized solution would be excessively configurable.

---

That being said, there might be tasks which might be facilitated using the operator pattern and then deploying this operator as part of the helm chart.

Just to illustrate, definitely not meant as a good idea, in oC10 there is this maintenance mode. Activating it in a cluster is PITA, as one needs to activate it in all running pods and then one also probably wants to serve a different maintenance page.

By using an annotation in the config.php, one can expose the maintenance mode setting to the cluster API. Then an operator which consumes a CRD which basically only consists of maintenance: true could annotate all pods and reroute the ingress for the time being, running the control loop on the crd and all existing pods, until at some point maintenance: false is being set.

It is more about exposing functionality via k8s than about solving deployments.

[^1]: Nowadays we have argo and flux anyway, making those operators essentially obsolete

[wkloucek]

So far we're gonna stay with an Helm chart. This may change in the future if requirements change