-
Notifications
You must be signed in to change notification settings - Fork 264
Take init containers into account when getting pod resource request #638
Conversation
/approve LGTM overall, let's get it merged when CI is happy :) |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hex108, k82cn The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@k82cn I'll look into it. I checked the code of k8s scheduler again, and found it only consider init containers' resource request for the predicate Another question: is there any reason to use float64 instead of int64 to record pod resource? |
Yes; we allocate resources in
We used to use CPU instead of MillCPU, so float64 is there. |
691f73f
to
6de00e0
Compare
Addressed. PTAL.
Get it. Thanks. |
@@ -141,9 +141,10 @@ func (alloc *allocateAction) Execute(ssn *framework.Session) { | |||
} | |||
} | |||
selectedNodes := util.SelectBestNode(nodeScores) | |||
req := api.GetPodResourceRequest(task.Pod) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
task.Resreq
already includes initContainer
, why do we need to re-calculate it again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
task.Resreq
is calculated by GetPodResourceWithoutInitContainers
, it does not contain initContainer
. We only need consider initContainer
when Allocate
, do I understand it correctly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also need Resreq in reclaim, preemption and backfill. And predicates&priorities will use Pods instead of task info :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm.... can we update task.Resreq
directly, so we do not need to update different actions :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated it at first time. However a lot of functions(e.g. jobinfo.AddTaskInfo
, NodeInfo.AddTaskInfo
) will use task.Resq
that does not contain init container
. Maybe we could add another variable ResqWithInitContainers
in TaskInfo
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If so, prefer to update related code to consider initContainer
:)
hm.... maybe we need to distinguish them. In nodeInfo, it's not necessary to consider initContainer
if it's in running state.
ee19552
to
5bd2487
Compare
pkg/scheduler/api/job_info.go
Outdated
// To be consistent with kubernetes default scheduler, ResreqWithInitContainers is only used for predicates | ||
// of actions (e.g.allocate, backfill, preempt, reclaim), please use Resreq for other cases. | ||
Resreq *Resource | ||
ResreqWithInitContainers *Resource |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about InitResreq
? The Resreq
is the resource that used when task running; and the InitResreq
is the resource that used to launch a task.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, it is shorter :) Addressed.
/lgtm |
Priority: 1, | ||
Pod: pod, | ||
Resreq: req, | ||
InitResreq: initResreq, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we also need to update Clone()
:)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for it, forget to run test. Updated.
/retest |
Test errors are because namespace test is not deleted. |
/lgtm |
…#642-#638-#645-#647-#651-#652-#655-#658-#649-#660-#666-#671-#673-upstream-release-0.4 Automated cherry pick of #643: Return err in Allocate if any error occurs #642: Add event when task is scheduled #638: Take init containers into account when getting pod resource #645: Order task by CreationTimestamp first, then by UID #647: In allocate, skip adding Job if its queue is not found #651: Return err in functions of session.go if any error occurs #652: Change run option SchedulePeriod's type to make it clear #655: Do graceful eviction using default policy #658: Address helm install error in tutorial.md #649: Preempt lowest priority task first #660: Fix sub exception in reclaim and preempt #666: Fix wrong caculation for deserved in proportion plugin #671: Change base image to alphine to reduce image size #673: Do not create PodGroup and Job for task whose scheduler is
Take init containers into account when getting pod resource request
Take init containers into account when getting pod resource request
Take init containers into account when getting pod resource request
What this PR does / why we need it:
Take init containers into account when getting pod resource request. The code refers
k8s.io/kubernetes/pkg/scheduler/algorithm/predicates/predicates.go#GetResourceRequest
.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #
Special notes for your reviewer:
Release note: