Forked from #3233, #1007, #1694, #1695, and other issues.

We've started to introduce a few configuration generators in kubectl: run-container, expose, ... They're not really built the way they should be.

It needs to be possible to access same generator functionality declaratively as is available imperatively using the CLI. The command-line arguments for imperative commands should be used to generate the config generator input schema, with as much of the intelligent defaulting inside the config generator (or even in the API e.g., #2643) as possible.

Furthermore, it should be possible to invoke generators via an API/URL rather than building them into kubectl, so that complex client libraries don’t need to be rewritten in multiple languages (e.g., Java, Ruby), and so that the abstractions are available through all interfaces: API, CLI, UI, logs, ...

This requires a schema registry, and some way to invoke the generator (e.g., using a container).

The config generator schema needs to be versioned. Otherwise, it will become unchangeable -- we've had this problem internally in spades. The default version can just be the latest one, but anyone who cares about reproducibility should be able to access any supported version of the generator via flag. That probably means the interpretation of the command-line flags needs to be versioned, also.

It needs to be straightforward to discover and manage (update, delete) the generated objects, using either the generator schema or the native objects.

It needs to be possible to just generate the primitive API objects without creating them (via dry run or somesuch).

There should be a path towards accessing a non-trivial amount of the power of the API, though via somewhat opinionated idioms.

Other planned config and deployment mechanisms should compose cleanly with it.

Not all of this needs to be supported out the gate, but whatever we build needs to be a compatible subset. For instance, we should decide how to specify schema fields on the command line, what flags we should use for a dry run (generation only), etc.

We could also add a new command, say expand, which just translates yaml to json, invokes generators, performs other transformations, populates other fields set by kubectl, such as namespace, apiVersion, kind, labels, annotations, etc., without creating the objects.

Config generators should otherwise be invoked similarly to real API objects: get, create, update, delete. The generators would be invoked prior to any of the API calls in order to expand to the set of API objects. Generators should support the standard object metadata, kind, apiVersion, name, labels, annotations. Other than for kind, the other fields will be propagated to all objects created. Not all apiVersions might be supported by a particular generator.