-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Change kube-proxy & fluentd CPU request to 20m/80m. #23646
Conversation
Labelling this PR as size/XS |
I think this is a good compromise for right now. Unfortunately kube-proxy will still get starved when all the addons land on the same node, becaues they all have higher limits, which leads to a bad ux since services are a core part of our system, but this is cpu so it should be OK. We will have to bump up these limits sometime. I'm not sure how we'd do that yet. This might also result in test flake, but we can handle that as it comes, we can easily figure out a higher timeout till a roll-forward solution presents itself. |
GCE e2e build/test passed for commit 915b6c6513317078df500daa37d055646ebc9a97. |
I'm going to switch it to 80/20 for fluentd/kube-proxy. In 1.1.8, kube-proxy had no reservation, so this will still be strictly better for kube-proxy, while not constraining fluentd too much. |
9040ce4
to
20a51cb
Compare
@@ -17,7 +17,7 @@ | |||
- makedirs: true | |||
- dir_mode: 755 | |||
- context: | |||
cpurequest: '200m' | |||
cpurequest: '20m' |
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.
please add a comment with something like:
// 20m might cause cpu starvation for kube-proxy resulting in delayed service updates. However
// we can't given it more cpu till we have a way to do so without affecting existing Kubernetes clusters.
// Any change made here must reflect in a proportional change to the requests of other daemons on
// the node, eg fluentd.
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 meant # wherever I said //
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's that look?
And documenting for the record, @a-robinson mentioned that fluentd in 1.2 is more efficient than 1.1, so we suspect there won't be much if any regression in user-visible logging performance by downsizing it from 100m to 80m. |
Labelling this PR as size/S |
GCE e2e build/test passed for commit 20a51cb0e1eebb6bf4bbba8c63a2e37610f24464. |
GCE e2e build/test passed for commit 6386938d3e079994b142aa0c3a06aafadfb2a84f. |
@@ -14,7 +14,7 @@ spec: | |||
limits: | |||
memory: 200Mi | |||
requests: | |||
cpu: 100m | |||
cpu: 80m |
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.
please add the same note of caution here.
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.
Done.
GCE e2e build/test failed for commit 4c18769caca655eb74d8180c9d08d1b0f892c754. Please reference the list of currently known flakes when examining this failure. If you request a re-test, you must reference the issue describing the flake. |
Your bug is #23659 in case you really need to push this out and can't re-up |
Although that doesn't sound like a kube-proxy flake... |
1 similar comment
GCE e2e build/test passed for commit 26a6c66. |
Mergebot is blocked on unrelated kubemark test suite broken for past 5 hours. This PR passed tests, is low risk, and fixes a significant regression in the amount of cpu available to users on each node, so manually merging. |
@gmarek - FYI |
The cherrypick process is defined here. Hoping to get this PR merged today, but the details are here. You need to run the cherry pick tool yourself to get these onto the branch. @bgrant0607 will then approve them for merge. |
Every cherrypick needs a release note. |
This PR has no description and no reference to a P0 issue. |
Fixes the "failure to schedule kube-dns" part of #23556. |
Internal bugref: 27924350 |
…46-upstream-release-1.2 Automated cherry pick of #23646
Commit found in the "release-1.2" branch appears to be this PR. Removing the "cherrypick-candidate" label. If this is an error find help to get your PR picked. |
@cjcullen thanks for this PR, it helps a lot to get smaller clusters running smooth. I've tested with 1 master and 2 node hosts on AWS m3.medium machines and it works great! |
@vishh @dchen1107 how far are we from having a way to use docker's --cgroup-parent logic? This might make a cool intern project if we can spec it enough. Then we could have a handful of special cgroups (let's call it "sys" for things that need to run on each machine) that some pods can ask to be contained in. I doubt that is the right API but we can work on that as we spec... |
@thockin that's the plan. My intern is most likely working on cgroups.
|
BTW we already use cgroup parent, except that it is not configurable per
|
I don't think that will solve the problem of occasionally needing to increase the sys cgroup's size from time to time, though. |
…ck-of-#23646-upstream-release-1.2 Automated cherry pick of kubernetes#23646
…ck-of-#23646-upstream-release-1.2 Automated cherry pick of kubernetes#23646
On 1.1.8, our per-node CPU overhead was 100m (fluentd 100m, kube-proxy unaccounted). To stay at that number, we should adjust fluentd to 80m, and give kube-proxy 20m.
Fixes the "failure to schedule kube-dns" part of #23556.