Access to CustomResourceCache

operator-framework / java-operator-sdk

Java SDK for building Kubernetes Operators

https://javaoperatorsdk.io/

Apache License 2.0

799 stars 215 forks source link

Access to CustomResourceCache #390

Open shawkins opened 3 years ago

shawkins commented 3 years ago

We are looking to implement metrics over the custom resource managed by the operator and would like to avoid k8s api calls if possible. It seems that the cache could be utilized either directly or indirectly for this purpose. Directly would look like having access in the Controller, possibly via the init method - then we could use that to drive simple metrics count, and checks based upon the resource Status. Indirect access would be related to https://github.com/java-operator-sdk/java-operator-sdk/issues/323 - such that count and other readily definable metrics are automatically exposed.

csviri commented 3 years ago

Hi @shawkins , it's an interesting idea, the cache is quite an internal thing, currently we are actually changing the implementation regarding to it. So it will be more extensible and replacable with custom implementation. However not sure if that is the best place to imeplement metrics. I agree that observability could be better in general. I think the best would be to implement metrics with micromete, seer: https://github.com/java-operator-sdk/java-operator-sdk/issues/64

What metrics you are interested in, could you provide some examples? Thx

shawkins commented 3 years ago

I think the best would be to implement metrics with micromete, seer: #64

Yes, that is the approach we are taking with the quarkus + micrometer integration.

What metrics you are interested in, could you provide some examples? Thx

Access to the cache was for things like:

count of the custom resource
other derived counts - number of resources with various condition states, such as ready. See also what they are doing with https://cloudark.medium.com/kubernetes-custom-resource-metrics-2a947dd4d954

Related to #64 and #323 in general we added Timed and Counted at the primary controller methods - see #393 (which I should have logged against the extension). Those as well could be handled by the operator framework itself.