This test tracks kubelet resource usage over a long period of time (1hr)
when running N pods (e.g., N=0,50), and prints out the resource usage. This
would give us an idea how much kubelet's management overhead is in a stable
cluster.
Some followup items:
* Use a more realistic workload (e.g., including probing)
* Fail the test if the resource usage is too high.
Caveat:
* We assume the scheduler would do a decent job distributing the pause pods,
but we should double check.
* Cluster addon pods could be unevenly distributed and skews the resource
usage on nodes.
Other cluster provider than gce or gke might have different cgroup layouts.
From outside we cannot know how these look like (especially in conformance test
which do not know the cluster provider at all).
Hence, this PR defaults to only the "/" cgroup to collect stats for. In the case
of gce or gke the full container list is tested.
Fixes https://github.com/mesosphere/kubernetes-mesos/issues/436
As discussed @gmarek the given test does not belong into the conformance test
suite because it makes a lot of static assumptions about the cgroup setup of the
nodes which cannot be fulfilled by all cluster providers. Depending on the
installation the kubelet is not allowed to move around process
into specific containers.
Fixes https://github.com/mesosphere/kubernetes-mesos/issues/439.
Increase the supported controls on pod logging. Add validaiton to pod
log options. Ensure the Kubelet is using a consistent, structured way to
process pod log arguments.
Add ?sinceSeconds=<durationInSeconds>, &sinceTime=<RFC3339>, ?timestamps=<bool>,
?tailLines=<number>, and ?limitBytes=<number>
In many cases clients may wish to view not ready addresses for endpoints
in order to do set membership prior to a pod being ready. For instance,
a pod that uses the service endpoints to connect to other pods under
the same service, but does not want to signal ready before it has
contacted at least a minimal number of other pods.
This is backwards compatible with old servers and clients. There is
an additional cost in size of endpoints before services ramp up, which
will add minor CPU and memory use for services that have a significant
number of pods which have not become ready.