bootkube --asset-dir should be able to parse k8s objects directly

[aaronlevy]

Rather than needing a specific directory structure, we should teach bootkube how to parse the kubernetes objects directly. This way we could just parse "api-server flags" and "api-server secrets" for use in bootkube's temporary apiserver and we don't need to specify them (or etcd) separately

[kenan435]

@aaronlevy I was gonna have a go at this if you or somebody else isn't implementing it atm. I need a bit more explanation though on what exactly you need. So inside of --asset-dir we render api-server flags as files in respective folders. I guess bootkube should load these files as k8s objects instead? This also applies to the rest of the the control panel?

[aaronlevy]

@kenan435 sorry, this is really vague (and my thinking may have changed a bit).

This likely would be replaced in functionality similar to #106 (I had started working on the above issue a week or so ago, but haven't had a chance to go back to it).

The ultimate goal of both of these issues is that we should be able to consume all of our configuration from native upstream objects (configMaps). So I guess there are two parts of this:

1. Bootkube consumes configuration of its internal control-plane (e.g. https://github.com/kubernetes-incubator/bootkube/blob/fae0c88b328a334c6e1f7a73b6358f9070d15eb8/pkg/bootkube/bootkube.go#L56-L67) from configMaps.
2. All of our self-hosted components consume their configuration from configMaps (will require upstream changes (briefly discussed in the "Render" step: Provide a generic mechanism for flag customizations #106)

Hypothetically both the internal bootkube control-plane and the self-hosted control plane should be able to use similar / same configuration (although we still need to resolve: #127). However, there may be some cases that I'm not considering where that's not true.

It may be worthwhile closing this issue and having the discussion in one place in #106 -- as they likely will be very close in functionality.

@kenan435 interested in your thoughts - and if this has been a particular pain point for you?

[aaronlevy]

Closing this in favor of moving to static manifests in the future: #168

We wouldn't need the compiled-in control-plane to source any information from manifests -- because we would use the manifests directly.