Merge pull request #29709 from fromanirh/cpumanager-policy-options-feature-gates
node: cpumanager: policy options to beta: document the options graduation process
This commit is contained in:
@@ -60,6 +60,13 @@ duration as `--node-status-update-frequency`.
|
|||||||
|
|
||||||
The behavior of the static policy can be fine-tuned using the `--cpu-manager-policy-options` flag.
|
The behavior of the static policy can be fine-tuned using the `--cpu-manager-policy-options` flag.
|
||||||
The flag takes a comma-separated list of `key=value` policy options.
|
The flag takes a comma-separated list of `key=value` policy options.
|
||||||
|
This feature can be disabled completely using the `CPUManagerPolicyOptions` feature gate.
|
||||||
|
|
||||||
|
The policy options are split into two groups: alpha quality (hidden by default) and beta quality
|
||||||
|
(visible by default). The groups are guarded respectively by the `CPUManagerPolicyAlphaOptions`
|
||||||
|
and `CPUManagerPolicyBetaOptions` feature gates. Diverging from the Kubernetes standard, these
|
||||||
|
feature gates guard groups of options, because it would have been too cumbersome to add a feature
|
||||||
|
gate for each individual option.
|
||||||
|
|
||||||
### None policy
|
### None policy
|
||||||
|
|
||||||
@@ -218,6 +225,12 @@ equal to one. The `nginx` container is granted 2 exclusive CPUs.
|
|||||||
|
|
||||||
#### Static policy options
|
#### Static policy options
|
||||||
|
|
||||||
|
You can toggle groups of options on and off based upon their maturity level
|
||||||
|
using the following feature gates:
|
||||||
|
* `CPUManagerPolicyBetaOptions` default enabled. Disable to hide beta-level options.
|
||||||
|
* `CPUManagerPolicyAlphaOptions` default disabled. Enable to show alpha-level options.
|
||||||
|
You will still have to enable each option using the `CPUManagerPolicyOptions` kubelet option.
|
||||||
|
|
||||||
The following policy options exist for the static `CPUManager` policy:
|
The following policy options exist for the static `CPUManager` policy:
|
||||||
* `full-pcpus-only` (beta, visible by default)
|
* `full-pcpus-only` (beta, visible by default)
|
||||||
* `distribute-cpus-across-numa` (alpha, hidden by default)
|
* `distribute-cpus-across-numa` (alpha, hidden by default)
|
||||||
@@ -237,7 +250,7 @@ one NUMA node is required to satisfy the allocation.
|
|||||||
By default, the `CPUManager` will pack CPUs onto one NUMA node until it is
|
By default, the `CPUManager` will pack CPUs onto one NUMA node until it is
|
||||||
filled, with any remaining CPUs simply spilling over to the next NUMA node.
|
filled, with any remaining CPUs simply spilling over to the next NUMA node.
|
||||||
This can cause undesired bottlenecks in parallel code relying on barriers (and
|
This can cause undesired bottlenecks in parallel code relying on barriers (and
|
||||||
similar synchronization primitivies), as this type of code tends to run only as
|
similar synchronization primitives), as this type of code tends to run only as
|
||||||
fast as its slowest worker (which is slowed down by the fact that fewer CPUs
|
fast as its slowest worker (which is slowed down by the fact that fewer CPUs
|
||||||
are available on at least one NUMA node).
|
are available on at least one NUMA node).
|
||||||
By distributing CPUs evenly across NUMA nodes, application developers can more
|
By distributing CPUs evenly across NUMA nodes, application developers can more
|
||||||
|
|||||||
Reference in New Issue
Block a user