-
Notifications
You must be signed in to change notification settings - Fork 40.3k
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
Reduce default gzip compression level from 4 to 1 in apiserver #112299
Conversation
defaultGzipContentEncodingLevel = 4 | ||
// defaultGzipContentEncodingLevel is set to 1 which uses least CPU compared to higher levels, yet offers | ||
// similar compression ratios (off by at most 1.5x, but typically within 1.1x-1.3x). For further details see - | ||
// https://docs.google.com/document/d/1rMlYKOVyujboAEG2epxSYdx7eyevC7dypkD_kUlBxn4 |
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 have a tiny preference for mentioning the date when the SIG discussed it, or the issue you filed? I don't mind it, we just don't usually link to docs in the comments.
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.
Changed to the gh issue link. That should have all the details
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lavalamp, shyamjvs 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 |
6770cc3
to
7cd5e65
Compare
/lgtm |
/triage accepted |
cc @mborsz |
I could go either way on a backport, it's not really a bug? @liggitt may have a stronger opinion one way or the other |
I agree that it's a gray area whether we should backport this or not, but given the relatively low risk and significant impact (we have seen a number of clusters hitting the "reflector unable to initialize within 60s timeout" due to unexpectedly low throughput of gzip with level=4) I personally would vote for backporting this. |
I could also go either way. I agree it's not exactly a functional bug, more an unexpected limitation. We know that at some point, creating enough objects will inevitably time out an unpaged request, even with gzip completely disabled. This change just increases the amount of headroom before we still hit a limit. That said, the risk does seem low, and there's not really a realistic workaround for someone hitting this limit on a cluster at large enough scale, so ~doubling the headroom is nice. I was going to ask if we were seeing LIST requests of sufficient size to manifest the timeout with object counts within the bounds described by https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md#kubernetes-thresholds, but then noticed that things like secrets and configmaps have TBD entries for count limits :-/ |
OK I finally thought of a way to decide: does this patch make it more or less likely to pass the conformance tests? I think the answer is "no change for most clusters; yes for clusters in particular resource constrained configurations". I therefore (just barely) support backporting. Since this has had no negative impact on the scalability tests at head. |
Created cherry-picks for all currently supported versions:
Daniel/Jordan - Could one of you help approve those please? |
…2299-upstream-release-1.22 Automated cherry pick of #112299: Reduce default gzip compression level from 4 to 1 in
…2299-upstream-release-1.23 Automated cherry pick of #112299: Reduce default gzip compression level from 4 to 1 in
…2299-upstream-release-1.24 Automated cherry pick of #112299: Reduce default gzip compression level from 4 to 1 in
…2299-upstream-release-1.25 Automated cherry pick of #112299: Reduce default gzip compression level from 4 to 1 in
…!720) PR112299-Reduce default gzip compression level from 4 to 1 in apiserver Reduce default gzip compression level from 4 to 1 in apiserver kubernetes#112299
Part-1 of the proposal here - #112296
/kind feature
(for lack of a better match?)
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
/assign @lavalamp @deads2k
/sig api-machinery