Skip to content
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

support giving less resources to init containers #565

Closed
joel-bluedata opened this issue Mar 11, 2022 · 4 comments · Fixed by #572
Closed

support giving less resources to init containers #565

joel-bluedata opened this issue Mar 11, 2022 · 4 comments · Fixed by #572
Assignees
Labels

Comments

@joel-bluedata
Copy link
Member

joel-bluedata commented Mar 11, 2022

Currently the init container for setting up the PV gets a hardcoded 1 CPU and 512Mi memory.

An annoying-in-some-circumstances effect of this: the reserved resources for a kdcluster pod is the max of the init container request and whatever the pod requests. It's not uncommon for a smaller kdapp (perhaps with numerous kdcluster instances) to want to use less than 1 CPU per pod, but if it uses a PV then it will effectively not be able to use less than 1 CPU per pod because of the init container.

If we move to a lower hardcoded value e.g. 250m, that may be an improvement in many cases... but in other cases this might cause the PV init to run slower for big apps that have a lot of data to copy in that phase. Which is bad!

So we may want to change the hardcoded amounts here, and we almost certainly want the amounts to be user-tunable, in the KD config and/or in the kdcluster spec. Easy enough to implement any such solution; just need to make sure we choose to do the right thing.

Cc @swamibluedata

@joel-bluedata joel-bluedata added this to the 0.9.0 milestone Mar 11, 2022
@swamibluedata
Copy link

We can also make "250m" dynamic based on requests/limit at role level?

@joel-bluedata
Copy link
Member Author

Mmm good point, we could default to whatever the role is requesting.

If we do that, I wonder if we do need to make it customizable? I.e. are there any realistic situations where you actually WOULD want the init container to get more resources than the app container?

@swamibluedata
Copy link

If we do that, I wonder if we do need to make it customizable? I.e. are there any realistic situations where you actually WOULD want the init container to get more resources than the app container?

The point you made about copying large amount of data. So yes makes sense to be configurable, which can say

"initcontainer resources should use role Resources or MUST use globally defined Resources"?

@joel-bluedata
Copy link
Member Author

You know... if the pod is going to always claim the max resources from among the init/app requests, then if someone wants more init resources they might as well go ahead and request that larger amount for the app as well. There doesn't seem to be any benefit from having large init resources and then smaller app resources.

I'm kind of inclined just to make BOTH the init resources and the app resources be set to the amount requested for the role, and leave it at that.

@joel-bluedata joel-bluedata self-assigned this Mar 15, 2022
joel-bluedata added a commit to joel-bluedata/kubedirector that referenced this issue Mar 15, 2022
joel-bluedata added a commit to joel-bluedata/kubedirector that referenced this issue Mar 22, 2022
joel-bluedata added a commit to joel-bluedata/kubedirector that referenced this issue Mar 22, 2022
joel-bluedata added a commit to joel-bluedata/kubedirector that referenced this issue Mar 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants