Operator-sdk: What is the best practise for operators include multiple resources

[gyliu513]

Type of question

Are you asking about community best practices, how to implement a specific feature, or about general context and help around the operator-sdk?

Question

What did you do?
I want to create an monitoring operator, but the operator include components like Prometheus, Grafana, exporter etc.

So I have two options to create my monitoring operator:

• Option 1: Use one operator to manage Prometheus, Grafana, exporter for monitoring.
• Option 2: There are already some operators for prometheus, Grafana etc, so just build my monitoring operator based on the existing operators.

What did you expect to see?
Hope to get some comments/suggestions for what is the best practise for my monitoring operator.

[camilamacedo86]

HI @gyliu513,

By building an operator via SDK, you can check that the implementation to export the metrics using the Prometheus Operator is done by default. Check the main.go. There a ServiceMonitor will be created to export the Prometheus metrics for the operator and its custom resources.

To install the Prometheus, follow up https://github.com/coreos/kube-prometheus. It is very straight forward. Then, after you have the Prometheus installed and deploy the operator you will be able to get the metrics already.

The Grafhana also can be installed very easy by following the instructions on the above link. Then, you can use the metrics which are exported by default to create your dashboard, rules, Prometheus alert and etc ...

I'd recommend you check the doc as well. We may need to update it, so please also feel free to contribute to the project. You are very welcome. :-)

Please, let me know if it is what you are looking for.

[grdryn]

HI @grdryn,

@gyliu513 this is probably for you :)

[camilamacedo86]

Autocomplete / GitHub suggestions issues :-P. Tks @grdryn

[gyliu513]

Thanks @camilamacedo86 for the always great support! Sorry for not describe clearly, here I was wondering if I can get some guidance for the best practise of one operators include multiple resources, and my monitoring operator is just an example :-)

[camilamacedo86]

Hi @gyliu513,

Sorry, but for me still not very clear what you are looking for. Note that you can define how many API's can be required for your solution. Could you please give more details for we are able to provide better assistance?

[gyliu513]

@camilamacedo86 let me explain the problem in detail, hope this helps.

Assume I have an application a1 which include c1, c2 and c3 as internal components, and now I want to create a operator to manage a1. In my understanding, there are two options for the operator of a1:

• Option 1: Use one operator to manage c1, c2 and c3 for application a1.
• Option 2: Build operators for c1, c2 and c3, then use build operator for application a1 with operators for c1, c2 and c3.

Here I want to get some best practise or guidance for above user scenario.

[camilamacedo86]

Hi @gyliu513,

You can have how many CRD/API defined in the projects as your business requires. See a demonstration of this idea in the blog post for example. Also, indeed an operator A can use/check resources of an Operator B.

Also, if you are using OLM, for example, you can define that one operator depends on others. See https://github.com/operator-framework/operator-lifecycle-manager#de

Please let me know if it is what you were looking for.

Hi @joelanford @shawn-hurley,
Would you like to supplement any additional information here?

[joelanford]

@gyliu513 Either option is reasonable. I think it depends on the complexity of c1, c2, and c3. If they are simple components that are tightly coupled, perhaps a single operator can handle all three.

However if one or more of them have complex reconciliation requirements (e.g. a database that requires backups and data migrations between versions) or they can be managed as standalone components (i.e. they have loose coupling), then separate operators for c1, c2, and c3 might make more sense. Then the a1 operator would only need to be concerned with the high-level abstractions exposed by the CRDs of c1, c2, and c3 operators.

[gyliu513]

Thanks @camilamacedo86 and @joelanford , this really helps!!