-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
helm: Allow configuration of the install-cni container resources #27469
Conversation
Added @squeed as a reviewer to hopefully speed things along. |
This is an initContainer; we don't have configurable resources for any other initContainers -- what's the use-case? (In fact, no other initContainers have resources at all... I wonder which is the better practice?) |
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.
Helm changes LGTM, also interested about @squeed question.
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 PR. In principle I don't see why not to make this configurable if it's important for your deployment case, since this presumably would help to reserve additional required resources on the nodes, and perhaps in constrained environments that can be the difference between being able to reliably redeploy Cilium or not.
At the same time, I'm not sure I understand where the limits came from or how we could keep these accurately up to date over time. I'd suggest dropping the defaults and just making it configurable, then in your environment you can specify whatever limits you find to be viable.
I'm also curious like the others above if there's anything particular about your environments that motivate this change?
It looks like the smoke tests failed, see the error below.
|
Hello! Sorry for the lag! I'll fix the PR early September (I'm out of office until then). Our use case is that we run a pod at node initialization that runs checks on the node before releasing it for general scheduling. To do that it's currently configured to take all the resources of the node. Typically to support this use case we set out system daemonsets such that requests and limits are at 0. When we deploy cilium with this init container, because of the kubelet accounting strategy, the node does not have it's full resources available. Which then prevents our pod from scheduling 😅 |
Interesting use case! I'll mark the PR as draft for now while you address the feedback, then you can click "Ready for review" to notify us afresh when you've updated the PR. |
c941781
to
a450e46
Compare
Alright, I've update the PR with the specific changes, but I don't seem to have the ability to mark my PR out of draft Thanks a lot! |
@kaworu, @joestringer and @squeed gentle bump in your inbox :) |
I can run the testsuite to gather that feedback. |
/test |
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.
Looks to me like nothing is functionally changing for the defaults here, the PR just makes the resources for this particular container configurable 👍
a4a3b41
to
922aa1e
Compare
e7db7ed
to
bb9c747
Compare
bb9c747
to
e3c9a5e
Compare
/test |
/test |
@RenaudWasTaken this should go in, I'm just rebasing on |
Signed-off-by: Renaud Gaubert <renaud@openai.com>
/test |
Thanks for pushing this PR over the line! |
Please ensure your pull request adheres to the following guidelines:
description and a
Fixes: #XXX
line if the commit addresses a particularGitHub issue.
Fixes: <commit-id>
tag, thenplease add the commit author[s] as reviewer[s] to this issue.
The helm chart does not provide a way to specify how much resources this container uses.
This change adds a way to configure this field.