Allow control plane components to specify concurrency #12643
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Concurrency in Linkerd is configured globally through a
proxy.cores
value or it can be configured through the injector. Control plane components cannot be configured through the injector since they come with the proxy pre-configured. In certain cases, it is necessary for proxies to specify their concurrency. Even though a global value exists, that directly influences all workloads in the cluster which can have other implications.Each control plane component has a
<component>ProxyResources
field that is used to configure limits and requests. We overload this field and allowcores
to be specified. We do not expect this value to be used often since directly specifying the number of cores might not make a lot of sense -- this does offer an escape hatch when the control plane components can't scale up to meet bursty workloads.Note for reviewers
Click me for
dig
function docsOverloading the operator with an additional field does not lead to failures. I have a couple of scenarios I tested and instructions on how to test locally.
To test:
bin/docker-build
bin/image-import --k3d --cluster <name>
I tested the following scenarios:
(1) Per-component default is applied
(2) When nothing is specified (globally or per-component) we roll with the default.
(3) When choosing between global and per-component, per-component is the override
(4) Specifying only a global means components respect the global
(5) We can upgrade and specify a per-component value to override the global
The tests show some of the basic install / upgrade flows that people would follow. Since the value will override only when specified (and is not documented) it should not affect existing installations unless users explicitly opt-in.