-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KEP-2879: Add count of ready Pods in Job status #2880
Conversation
3516e4a
to
d114be1
Compare
/label api-review |
9bca8ec
to
afbd037
Compare
afbd037
to
0de12d1
Compare
@gaocegege I would appreciate your feedback |
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.
Thanks for the proposal. I think it is helpful.
when the Pod doesn't define a readiness probe.
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.
LGTM. thanks for the enhancement.
/assign |
API lgtm if you can not have the first / second version difference. |
b13d1c9
to
2684cc5
Compare
858e302
to
a38669a
Compare
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.
Mostly nits.
/lgtm
/approve
from sig-apps perspective
latest-milestone: "v1.23" | ||
|
||
milestone: | ||
beta: "v1.23" |
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.
1.24
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.
Oops. Fixed
a38669a
to
14358c4
Compare
- The job controller is updating other status fields. | ||
- The number of ready Pods equals `Job.spec.parallelism`. | ||
- The increase of ready Pods is greater than or equal to 10% of | ||
`Job.spec.parallelism`. |
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.
Let's say that because of cluster capacity, 100% of my jobs will never have place to run. But let's say 99% has.
With the policies above it may happen that we update ready to 90%, but we will never change that to 99%. So the system isn't eventually consistent, which I think is problematic.
I think that you need another rule, i.e. when something changes, it will be applied with X seconds/minutes (i.e. we batch it for such period).
[FWIW - such logic is super simple to implement, e.g. https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/endpoint/endpoints_controller.go#L224 ]
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.
True, being eventually consistent should be a requirement.
Could the solution for the job controller be the same? We would delay/accumulate any sync coming from Pod creation/updates/deletions. This might actually be good for the overall performance of the controller. The delay for endpoint slices is configurable. Should we do the same? I'm proposing a 100ms window otherwise.
|
||
###### Are there any tests for feature enablement/disablement? | ||
|
||
Yes, at unit and integration level. |
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'm assuming "they will be added", right?
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.
Yes, changed wording.
|
||
###### What are the reasonable SLOs (Service Level Objectives) for the enhancement? | ||
|
||
The 99% percentile of Job status updates below 1s, when the controller doesn't |
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.
Are you talking about API calls or about the processing logic in the controller? It's not clear to me.
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.
the E2E latency of a sync. Reworded. Maybe it should be 2s, because just the API call is 1s.
aa9e6fe
to
f86af30
Compare
### Risks and Mitigations | ||
|
||
- An increase in Job status updates. To mitigate this, the job controller holds | ||
the Pod updates that happen in 100ms before syncing a Job. |
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.
100ms is negligible imho;
I would use at least 1s as a batching period
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 I leave it open until I have the integration tests to do some experiments?
1s starts to sound a bit too long considering that we have to hold any Pod updates. See updated KEP
f86af30
to
24e1c4c
Compare
@@ -0,0 +1,3 @@ | |||
kep-number: 2879 | |||
alpha: |
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.
beta
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.
beta - yes, but we need to make sure that this is properly linked with #2307 which expands.
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.
make sure to add that ref in the kep.yaml, pls.
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 forgot to update the description: I'm no longer proposing to start at beta.
I don't see this KEP as an expansion of #2307.
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.
Yeah - I think this should be alpha.
|
||
- An increase in Job status updates. To mitigate this, the job controller holds | ||
the Pod updates that happen in X ms before syncing a Job. X will be determined | ||
from experiments on integration tests, but we expect it to be between 100ms |
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 think 100ms delay isn't meaningful as it's way below the SLO for API call.
I personally recommend not even considering anything lower than 0.5s.
TBH, in this particular case I would say that even couple seconds might be fine, but I can imagine counterarguments too, so let's maybe stick to 500ms-1s interval for now.
WDYT?
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.
Sounds good. Updated to 500ms-1s.
24e1c4c
to
5ee7b73
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alculquicondor, soltysh, wojtek-t 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 |
|
||
## Implementation History | ||
|
||
- 2021-08-19: Proposed KEP starting in beta status. |
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.
shouldn't this be marked as starting at Alpha
status? @alculquicondor
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.
It should. I'll fix it in the next update.
Ref #2879
Proposed the addition of field
Job.status.ready
.Includes PRR