Topology Manager Scopes and Policies
Topology Manager provides two distinct knobs: scope and policy.
The scope defines the granularity at which you would like resource alignment to be performed (e.g. at the pod or container level). And the policy defines the actual strategy used to carry out the alignment (e.g. best-effort, restricted, single-numa-node, etc.).
Topology Manager Scopes
The Topology Manager can deal with the alignment of resources in a couple of distinct scopes:
container(default)pod
Either option can be selected at a time of the kubelet startup, with --topology-manager-scope flag.
Using the pod scope in tandem with single-numa-node Topology Manager policy is specifically valuable for workloads that are latency sensitive or for high-throughput applications that perform IPC. By combining both options, you are able to place all containers in a pod onto a single NUMA node; hence, the inter-NUMA communication overhead can be eliminated for that pod.
In the case of single-numa-node policy, a pod is accepted only if a suitable set of NUMA nodes is present among possible allocations. Reconsider the example above:
- a set containing only a single NUMA node - it leads to pod being admitted,
- whereas a set containing more NUMA nodes - it results in pod rejection (because instead of one NUMA node, two or more NUMA nodes are required to satisfy the allocation).
To recap, Topology Manager first computes a set of NUMA nodes and then tests it against Topology Manager policy, which either leads to the rejection or admission of the pod.
Topology Manager Policies
You can set a policy via a Kubelet flag, --topology-manager-policy. There are four supported policies:
none(default)best-effortrestrictedsingle-numa-node
Ref
https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/
