feat: add support to detect unused CRDs

[m-yosefpor]

fixes #103

[m-yosefpor]

would you please review this? @yonahd

It was a bit tricky.. the default generic kubernetes.Interface seems not to support working with api-extension.. so I needed to use api-extenion clientset ("k8s.io/apiextensions-apiserver/pkg/client/clientset/clientset") also as working with CRs is not possible with default clientset, I had to use dynamic clientset. I appreciate your inputs on this.

[yonahd]

I reviewed the code on a high level and it looks overall good.(we'll do a proper code review in the next few days hopefully)

The question here is whether presenting the user with individual unused CRDs adds value.

Take monitoring.coreos.com as an example, under it there are multiple CRDs e.g.

• Prometheus
• PrometheusRule
• ServiceMonitor

If only one of the above is not used can the user uninstall that individual CRD or is he bound by the higher level of monitoring.coreos.com?

Maybe we should be returning only the higher-level that all it's CRDs are not used, WDYT?

[m-yosefpor]

I reviewed the code on a high level and it looks overall good.(we'll do a proper code review in the next few days hopefully)

The question here is whether presenting the user with individual unused CRDs adds value.

Take monitoring.coreos.com as an example, under it there are multiple CRDs e.g.

* Prometheus

* PrometheusRule

* ServiceMonitor

If only one of the above is not used can the user uninstall that individual CRD or is he bound by the higher level of monitoring.coreos.com?

Maybe we should be returning only the higher-level that all it's CRDs are not used, WDYT?

It actually really depends.. for example for the monitoring.coreos.com, the prometheus operator neeeds all the CRDs to exist.. but for other project (e.g. argoproj.io) it has many components (argo-workflow, argo-events, argo-cd, argo-appset controller), which all of those CRDs are in the same higher level api group, but they can be deployed independently and each of those use their own set of CRDs in that api group. So I think to cover all such cases, it's better to left the decision on whether they can remove the CRDs or not, to user and we will only report on a per CRD basis.

[yonahd]

Looks good overall.
Please rebase and see the comment for making this code cleaner

[yonahd]

This is very similar code to GetKubeClient function
Let's create a function that gets the config and we can create different clientsets based off this function

Same for dynamic client

[yonahd]

Also if you can add a couple test for this that would be great!

[yonahd]

@m-yosefpor Do you intend to finish this MR?

[codecov-commenter]

Codecov Report

Attention: 152 lines in your changes are missing coverage. Please review.

Comparison is base (0210609) 42.82% compared to head (eb7536c) 39.52%.
Report is 11 commits behind head on unused_crds.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@               Coverage Diff               @@
##           unused_crds     #106      +/-   ##
===============================================
- Coverage        42.82%   39.52%   -3.30%     
===============================================
  Files               17       18       +1     
  Lines             1749     1895     +146     
===============================================
  Hits               749      749              
- Misses             898     1044     +146     
  Partials           102      102              

Files	Coverage Δ
pkg/kor/exporter.go	5.71% <0.00%> (ø)
pkg/kor/all.go	0.00% <0.00%> (ø)
pkg/kor/kor.go	27.89% <0.00%> (-12.88%)	⬇️
pkg/kor/crds.go	0.00% <0.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.