[k8s.io] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}

[k8s-github-robot]

https://storage.googleapis.com/kubernetes-jenkins/logs/kubernetes-e2e-gce-scalability/7993/

Failed: [k8s.io] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}

/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/test/e2e/load.go:182
creating rc load-big-rc-3
Expected error:
    <*errors.errorString | 0xc8283a7fb0>: {
        s: "Number of reported pods for load-big-rc-3 changed: 248 vs 250",
    }
    Number of reported pods for load-big-rc-3 changed: 248 vs 250
not to have occurred

[k8s-github-robot]

https://storage.googleapis.com/kubernetes-jenkins/logs/kubernetes-e2e-gce-scalability/7995/

Failed: [k8s.io] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}

/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/test/e2e/load.go:71
Expected
    <int>: 15
not to be >
    <int>: 0

[yujuhong]

/cc @kubernetes/sig-scalability

[wojtek-t]

The second run is just ridiculous - metrics are ~100x higher than they usually are - this had to be some GCE-related flake.

In the first one, it look something bad happened with either apiserver or nodes - I will take a look later this week.

[wojtek-t]

So unfortunately, we don't have any logs from that run, so we can't debug it further.

But we have thousands of logs like this one:

"May 30 13:58:07.305: INFO: Error while reading data from e2e-scalability-minion-group-gs4m: Unable to get server version: Get https://104.197.116.46/version: dial tcp 104.197.116.46:443: i/o timeout"

which suggests that something bad happened to apiserver.

My strong feeling is that this is because:
#26563

because that could have effect exactly like what happened here.

So I'm closing this as a duplicate of #26563