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
Fix APF width estimate for creating service account's token #113206
Fix APF width estimate for creating service account's token #113206
Conversation
/assign @wojtek-t @tkashem @MikeSpreitzer |
99c4183
to
41a9d89
Compare
/retest |
(1) Why are we talking about events here? (2) We know that the current treatment of requests is approximate. It will always be approximate, no matter how finely we tune it. Do we have evidence that the current treatment of service account token creation requests is causing a problem? |
/triage accepted |
(1) Why are we talking about events here? I am talking about events, because we are estimating width and additional latency based on number of watches that are watching modified resource and assumption that each modification generates event. In case of tokens for serviceaccounts, creating token for service account does not modify serviceaccount and therefore does not produce event. (2) We know that the current treatment of requests is approximate. It will always be approximate, no matter how finely we tune it. Do we have evidence that the current treatment of service account token creation requests is causing a problem? Yes, that's why I created PR. From log that I attached you can see that request took 10 seats and ~260 ms of additional latency -
but they cannot be watched. |
func isRequestExemptFromEvents(requestInfo *apirequest.RequestInfo) bool { | ||
// Creating token for service account does not produce any event, | ||
// but still serviceaccounts can have multiple watchers. | ||
if requestInfo.Resource == "serviceaccounts" && requestInfo.Subresource == "token" { |
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.
so "/api/v1/namespaces/kube-system/serviceaccounts/default/token" does not change the underlying service account object, and clients watching service accounts in this namespace would receive no watch event, right?
so, are there other requests with sub resource that does not produce watch events?
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.
so "/api/v1/namespaces/kube-system/serviceaccounts/default/token" does not change the underlying service account object, and clients watching service accounts in this namespace would receive no watch event, right?
correct
so, are there other requests with sub resource that does not produce watch events?
I wasn't able to find any other (there are still some long running subresources like proxy/logs etc, but they are exempt from P&F). Similarly there is also tokenreviews api, but you can only create tokens and not watch this resource.
staging/src/k8s.io/apiserver/pkg/util/flowcontrol/request/mutating_work_estimator.go
Outdated
Show resolved
Hide resolved
.. and this is why I hate talking about "events". There are so many kinds to choose from! Remember that Kubernetes has other kinds of "events". You will note I have been talking about "watch notifications", but everyone else calls them "events". Maybe we can say "watch events"? So I think @tkashem is trying to suggest that the proper generality here is exemption from watch events, right? |
staging/src/k8s.io/apiserver/pkg/util/flowcontrol/request/mutating_work_estimator.go
Outdated
Show resolved
Hide resolved
41a9d89
to
029eb79
Compare
029eb79
to
2f7b4ca
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.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: marseel, MikeSpreitzer 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 |
For posterity - LGTM thanks for fixing this! |
What type of PR is this?
/kind bug
What this PR does / why we need it:
Creating token for service account does not modify serviceaccount and does not produce any event. Because of that it shouldn't be considered as such request, example:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: