Change:
https://k8s- Failed: [] Rescheduler [Serial] should ensure that critical pod is scheduled in case there is no resources available {Kubernetes e2e suite} Previous issues for this test:
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Rescheduler [Serial] should ensure that critical pod is scheduled in case there is no resources available {Kubernetes e2e suite}
https://k8s- Failed: [] Rescheduler [Serial] should ensure that critical pod is scheduled in case there is no resources available {Kubernetes e2e suite}
This test always failed in 1.5 upgrade builds for the similar reason as . In previous version it will try to retrieve the ReplicationController of kube-dns during this test(). But since kube-dns started to use Deployment but not RC and leads to this failure in upgrade builds.
This is not a sig/apps issue, relabeling to sig/scheduling
I'd like to follow up for this flaky test :).
This test has been failing consistently since Saturday, which may indicate a release-blocking regression. Will you be able to prioritize investigating the problem?
sure
Check the log at re-scheduler evict pods at ; but did not get scheduler's event. At , the e2e test report error and start to clear up test environment.
And after checking the log, there're only 46 of 60 pods are scheduled. Created a PR that reduced the pods number to see what will happen.
/cc , , for comments.
I have been able to reproduce this, but I still don't have a good answer as why this is happening. I will keep looking at the code and will update here if I find anything.
Can you share some logs? I can not run it locally/or gce because of network; just check the log on the server :).
In the latest run of the test that has failed, I see that scheduler attempts to schedule the critical pod after rescheduler evicts other pods to create room, but the critical pod still does not fit on the nodes: scheduler log (look for "-2n3g2"): rescheduler log: (I will look at the test code later to see what's going on)
Wow, yes, similar conclusion yesterday (). If you can reproduce it, maybe we can add some instrument/debug log to see in scheduler; that'll be helpful :).
cc/
please correct me if I'm wrong but tolerations/taints is already migrated to fields in HEAD. This means that to fix this issue we need to migrate rescheduler to use fields. I'll do it very soon.
Do you think this issue indicates a regression that should block 1.6, which would require that a fix be available asap? Or is it a test-only issue that can be moved to the 1.6.1 or 1.7 milestone?
the former one. See
yes taints and tolerations are already moved to api fields, and the related PRs are already merged for 1.6. Also this looks duplicate of , I think we should close one.
+1
was closed in favor of this issue, since we expect the bot to re-open this
Status: is working on a fix

Discussion:
apiVersion: v1 kind: Pod metadata: <del> name: rescheduler-v0.2.2 </del> <ins> name: rescheduler-v0.3.0 </ins> namespace: kube-system labels: k8s-app: rescheduler <del> version: v0.2.2 </del> <ins> version: v0.3.0 </ins> kubernetes.io/cluster-service: "true" kubernetes.io/name: "Rescheduler" spec: hostNetwork: true containers: <del> - image: gcr.io/google-containers/rescheduler:v0.2.2 </del> <ins> - image: gcr.io/google-containers/rescheduler:v0.3.0 </ins> name: rescheduler volumeMounts: - mountPath: /var/log/rescheduler.log