We were not actually doing what the method names suggested we were
doing with respect to loading the config and initializing clients
in the k8s driver. The idea is to load the config from one of
the appropriate places, then pass that config around to get clients.
Due to the use of incorrect API methods in the driver, this was
only working for in-cluster configs, and that was only working
because the errors were masked by behind-the-scenes config loading.
This change corrects the errors and makes it much more explicit.
We instantiate our own k8s Configuration object (which is what
the library does behind the scenes), load data into it from one
of the sources, then use that to get an ApiClient which is then
used to get the various sub-clients. This avoids any implicit
storing of configuration in memory, and achieves the main goal of
this system: to be able to support multiple connections which
are loaded from multiple different config files simultaneously.
The new code has been manually tested with both in-cluster and
external config. Tests are added to exercise the code in simulated
environments for both of those cases, and the existing tests are
updated to exercise one of the code paths as well to ensure that
we have coverage during the normal launcher startup phase.
Change-Id: Ie9e12da1d9f3e6c5c0e734f2e5a1d380e4fb6c60
b329cbc3f8