What would you like to be added?
Raised at #129698 (comment).
We should somehow tell end-users (i.e., not the cluster admin who has access to the scheduler logs) why pods are pending if PreEnqueue has been rejecting those pods.
That being said, we cannot simply make API calls for kube-apiserver within the scheduling queue because the queue is very performance sensitive.
Why is this needed?
Currently, when PreEnqueue rejects pods, pods are just kept in the scheduling queue without any visible changes to pod objects. i.e., users cannot see why pods are pending at pod condition, status, events etc. The only way to figure out is to look at the scheduler's logs.
The scheduling gate feature is avoiding this problem at kube-apiserver; add a condition to pods if the scheduling gate is specified.
|
func applySchedulingGatedCondition(pod *api.Pod) { |
We cannot do the same for any PreEnqueue plugins in general because kube-apiserver doesn't know which pods will be rejected by the scheduler's PreEnqueue plugins.
What would you like to be added?
Raised at #129698 (comment).
We should somehow tell end-users (i.e., not the cluster admin who has access to the scheduler logs) why pods are pending if
PreEnqueuehas been rejecting those pods.That being said, we cannot simply make API calls for kube-apiserver within the scheduling queue because the queue is very performance sensitive.
Why is this needed?
Currently, when PreEnqueue rejects pods, pods are just kept in the scheduling queue without any visible changes to pod objects. i.e., users cannot see why pods are pending at pod condition, status, events etc. The only way to figure out is to look at the scheduler's logs.
The scheduling gate feature is avoiding this problem at kube-apiserver; add a condition to pods if the scheduling gate is specified.
kubernetes/pkg/registry/core/pod/strategy.go
Line 821 in 3f26d00
We cannot do the same for any PreEnqueue plugins in general because kube-apiserver doesn't know which pods will be rejected by the scheduler's PreEnqueue plugins.