You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The example `Pod` specs below help illustrate pod interactions with Topology Manager.
8
+
The example `Pod` specs illustrate pod interactions with Topology Manager.
9
9
10
10
The following pod runs in the `BestEffort` QoS class because no resource requests or limits are specified.
11
11
@@ -32,9 +32,11 @@ spec:
32
32
memory: "100Mi"
33
33
----
34
34
35
-
If the selected policy is anything other than `none`, Topology Manager would not consider either of these `Pod` specifications.
35
+
If the selected policy is anything other than `none`, Topology Manager would consider either of the `BestEffort` or the `Burstable` QoS class `Pod` specifications.
36
+
When the Topology Manager policy is set to `none`, the relevant containers are pinned to any available CPU without considering NUMA affinity. This is the default behavior and does not optimize for performance-sensitive workloads.
37
+
Other values enable the use of topology awareness information from device plugins. The Topology Manager attempts to align the CPU, memory, and device allocations according to the topology of the node when the policy is set to other values than `none`. For more information about the available values, see _Additional resources_.
36
38
37
-
The last example pod below runs in the Guaranteed QoS class because requests are equal to limits.
39
+
The following example pod runs in the `Guaranteed` QoS class because requests are equal to limits.
38
40
39
41
[source,yaml]
40
42
----
@@ -53,6 +55,6 @@ spec:
53
55
example.com/device: "1"
54
56
----
55
57
56
-
Topology Manager would consider this pod. The Topology Manager would consult the hint providers, which are CPU Manager and Device Manager, to get topology hints for the pod.
58
+
Topology Manager would consider this pod. The Topology Manager would consult the Hint Providers, which are CPU Manager and Device Manager, to get topology hints for the pod.
57
59
58
-
Topology Manager will use this information to store the best topology for this container. In the case of this pod, CPU Manager and Device Manager will use this stored information at the resource allocation stage.
60
+
Topology Manager will use this information to store the best topology for this container. In the case of this pod, CPU Manager and Device Manager will use this stored information at the resource allocation stage.
Topology Manager aligns `Pod` resources of all Quality of Service (QoS) classes by collecting topology hints from Hint Providers, such as CPU Manager and Device Manager, and using the collected hints to align the `Pod` resources.
@@ -16,15 +16,12 @@ This is the default policy and does not perform any topology alignment.
16
16
17
17
`best-effort` policy::
18
18
19
-
For each container in a pod with the `best-effort` topology management policy, kubelet calls each Hint Provider to discover their resource
20
-
availability. Using this information, the Topology Manager stores the preferred NUMA Node affinity for that container. If the affinity is not preferred, Topology Manager stores this and admits the pod to the node.
19
+
For each container in a pod with the `best-effort` topology management policy, kubelet calls each Hint Provider to discover their resource availability. Using this information, the Topology Manager stores the preferred NUMA Node affinity for that container. If the affinity is not preferred, Topology Manager stores this and admits the pod to the node.
21
20
22
21
`restricted` policy::
23
22
24
-
For each container in a pod with the `restricted` topology management policy, kubelet calls each Hint Provider to discover their resource
25
-
availability. Using this information, the Topology Manager stores the preferred NUMA Node affinity for that container. If the affinity is not
26
-
preferred, Topology Manager rejects this pod from the node, resulting in a pod in a `Terminated` state with a pod admission failure.
23
+
For each container in a pod with the `restricted` topology management policy, kubelet calls each Hint Provider to discover their resource availability. Using this information, the Topology Manager stores the preferred NUMA Node affinity for that container. If the affinity is not preferred, Topology Manager rejects this pod from the node, resulting in a pod in a `Terminated` state with a pod admission failure.
27
24
28
25
`single-numa-node` policy::
29
26
30
-
For each container in a pod with the `single-numa-node` topology management policy, kubelet calls each Hint Provider to discover their resource availability. Using this information, the Topology Manager determines if a single NUMA Node affinity is possible. If it is, the pod is admitted to the node. If a single NUMA Node affinity is not possible, the Topology Manager rejects the pod from the node. This results in a pod in a Terminated state with a pod admission failure.
27
+
For each container in a pod with the `single-numa-node` topology management policy, kubelet calls each Hint Provider to discover their resource availability. Using this information, the Topology Manager determines if a single NUMA Node affinity is possible. If it is, the pod is admitted to the node. If a single NUMA Node affinity is not possible, the Topology Manager rejects the pod from the node. This results in a pod in a `Terminated` state with a pod admission failure.
0 commit comments