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

Add configurable option on resource requirements for jaeger componenets #70

Closed
mathspanda opened this issue Oct 17, 2018 · 12 comments
Closed
Labels
enhancement New feature or request question Further information is requested

Comments

@mathspanda
Copy link

We need to make resource requests and limits configurable for all jaeger pods.

@jpkrohling
Copy link
Contributor

How would that work? Would you define one set of resource limits and it would be applied to all pods? Would that apply also for agents that are injected as sidecars? Or would you need a more granular configuration, so that the collector has one set of limits, the query another and so on?

@mathspanda
Copy link
Author

mathspanda commented Oct 17, 2018

A more granular configuration. The collector and the query have different set of requests and limits.

@jpkrohling
Copy link
Contributor

How about the agent? Should the agent as sidecar have different constraints as an agent running as daemonset?

@mathspanda
Copy link
Author

Yep. Agents with different deployment strategy should have different set of limits. Even so, one Jaeger CR cannot have two different deployment strategy of the agent at the same time. The resource limits for agent with different strategy can be just stored in one uniform field in struct JaegerAgentSpec.

@jpkrohling
Copy link
Contributor

Even so, one Jaeger CR cannot have two different deployment strategy of the agent at the same time

That's not entirely true. IIRC, if the strategy is "DaemonSet", we deploy the agent as daemonset, but we still inject agent sidecars if the appropriate annotation is in place. So, while I probably wouldn't call it "best practice", it's possible to have both daemonsets and sidecars for the same Jaeger instance.

@mathspanda
Copy link
Author

I see. Temporarily i haven't any ideas about how to apply different set of resource limits for agents with different deployment strategy. Maybe setting resource limits for the agents that are injected as sidecars is in extremely low demand levels. Do you have any thoughts on that?

@jpkrohling
Copy link
Contributor

Not really, I'm open to hear about concrete use cases :) My feeling is that the sidecar indeed should require far less resources than a daemon set, but every new configuration switch we add is potentially more complexity for the end user (and to maintain/test/document).

@mathspanda
Copy link
Author

I agree with you. And more use cases and discussion on this issue are needed.

@jpkrohling jpkrohling added enhancement New feature or request question Further information is requested labels Oct 17, 2018
@jpkrohling
Copy link
Contributor

I'm marking this as "question" for now, until we know what we need :)

@pavolloffay
Copy link
Member

pavolloffay commented May 2, 2019

Has this been resolved?

JaegerCommonSpec contains Resources v1.ResourceRequirements which is part of every jaeger spec - query, collector, agent.

However, the Resourcesare not applied to the agent sidecar. Related to #169

cc @killcity

@killcity
Copy link

killcity commented May 2, 2019

An issue we are running into with sidecar injection is that there is no way to set requests/limits on the sidecar agent, so any deployments/statefulsets, etc that require a certain QoS (we require Guaranteed) get changed to Burstable. I will have to manually add the sidecars until this feature is added. Thanks for all the hard work on this project!

@jpkrohling
Copy link
Contributor

@killcity, @mathspanda, I believe this is supported for some time already. I'm closing this, but please check it out and reopen if there's still something missing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants