Don't use reflection in KubernetesClientBuilder

[jamestpt]

Is your enhancement related to a problem? Please describe

I have some code where I'm loading and unloading classes into Thread.currentThread().getContextClassLoader() for the purposes of compatibility with various different spark versions. I'm running into reflection problems when using KubernetesClientBuilder, since its using the very same classloader and reflection to load the constructor for KubernetesClientImpl.

Describe the solution you'd like

Could we possibly move out KubernetesClientBuilder from the client-api into the client, and use the constructor directly new KubernetesClientImpl(...) rather than using reflection? I think this would make the code safer and more readable.

Describe alternatives you've considered

No response

Additional context

Thanks for this useful library! Let me know what you think about this proposal.

[manusa]

Hi @shawkins
I'm not sure why we used reflection instead of SPI to build the KubernetesClient instance.
Was there anything specific?
Would changing this to use SPI or other alternatives have any unexpected side-effects?