Issue 1:
Using kubectl create with a list no longer works. We get the output:

$ _output/local/bin/linux/amd64/kubectl create -f /tmp/test.json
error validating "/tmp/test.json": error validating data: couldn't find type: v1.List; if you choose to ignore these errors, turn validation off with --validate=false

Issue 2:
Proposal to create a generic interface from kubelet to cadvisor

1. Background

cadvisor was integrated with kubernetes in issue #4798, which made

the deployment of kubernetes simpler and out-of-box UX smoother for new

users. However, at the same time, it created a tight coupling between

kubelet and cadvisor. We'd like create a generic interface so that other

container health checking tools can be used with kubernetes.

2. Motivation

It is great that there's a built-in cadvisor when a new user starts to

play around with kubernetes. For most users, continuing to use this

cadvisor, and then configure heapster, influxdb, and grafana is the natural

way to go. However, for other users, they might prefer to use other open

source tools for collecting this information or create their own custom tools.

As there is no way to disable cadvisor, one way is to run both cadvisor

and their custom tools at the same time, which is inefficient and wasteful.

Other use cases to further motivate this proposal are:

a) Deploying kubernetes in a public cloud, and the cloud provider already provides

similar health checking tools.

b) Deploying kubernetes on top of mesos, where there could be multiple frameworks

deployed on the same mesos node. If each framework is using its own health checking

tool, they would perform duplicate works.

c) The kubenetes-bundled cadvisor sometimes have performance issues where it is

consuming a much larger amount of resources than expected (see issues #10451, #16296).

In a production environment, one might want to run a stable version of cadvisor,

and have Kubernetes simply connecting to it instead of using the newer built-in one.

3. Planned work

We're planning to create a generic interface and a set of Kubernetes-based (instead of

cadvisor-based) health checking data structs, so that it can interface with different

health checking backends, including cadvisor. Integrating kubernetes with a new health

checking tool would involve writing a new driver that implements that generic interface.

3a. Phased approach

We'd like to phase this work to smaller steps. Initially, we are planning to create this

generic interface almost identical to what is defined in pkg/kubelet/cadvisor/types.go, and

the corresponding data structs directly from cadvisor. This allows us to put in the generic

health checking interface with minimal changes to the existing code.

In the 2nd phase, we would like to clean up the generic interface and the corresponding

data structs as not everything cadvisor collects are used by kubelet. Basically, we will make

the interface and data structs more generic so that new health check drivers can be more

easily written.

In the 3rd phase, we will add one or two additional cmd flags to allow alternative health

checking driver to be used when starting kubernetes. Of course, the default setting will be

to use the built-in cadvisor.