One question, will this be reported as an error in the logs? It seems to me if the user disabled that, it should not be reported as an error.

Good point. I will change it to Debug

Reverted to nil

I would use affirmative name instead, so true means enabled, false - disabled, not vice versa
imagine checking in code c.KubeAdm = false would give an impression that it is disabled, it introduce obscurity. WDYT?
default value should be changed in this case

You are right, I was actually thinking about that. Reason that I chose not to is that the absence of setting the variable evaluates to false and it was quicker like that to implement the code. For eg. https://github.com/elastic/beats/blob/feef1138f809281ac0a70ec97be6ed782901c2ab/metricbeat/module/kubernetes/util/kubernetes.go#L1231 the absence here would mean that this will evaluate to false and all will work and wont have to initialise anything in beats

This would mean that in beats we will need to revert the logic.
In a nutshell,
So not setting use_kubeadm -> use_kubeadm: false in beats module but in here KubeAdm should be true

@tetianakravchenko I repeated the tests with use_kubeadm

Final PR has the logic reverted , I mean that use_kubeadm is true by default
Users need to disable (use_kubeadm: false) to see no api calls

I have run tests with metricbeat:

Initial run is with metricbeat-8.15.0-SNAPSHOT: 170 api calls
Second run is with new build of metricbeat and not setting the use_kubeadm variable (so is true): 170 api calls
3rd run is with new build of metricbeat and setting use_kubeadm variable=false: 0 api calls

Reverting back returns the calls

Thank you for reverting the logic and tests!