1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Files
openshift-docs/modules/pod-interactions-with-topology-manager.adoc
2025-10-30 04:59:21 +00:00

62 lines
2.3 KiB
Plaintext

// Module included in the following assemblies:
//
// * scaling_and_performance/using-topology-manager.adoc
:_mod-docs-content-type: REFERENCE
[id="pod-interactions-with-topology-manager_{context}"]
= Pod interactions with Topology Manager policies
The example `Pod` specs illustrate pod interactions with Topology Manager.
The following pod runs in the `BestEffort` QoS class because no resource requests or limits are specified.
[source,yaml]
----
spec:
containers:
- name: nginx
image: nginx
----
The next pod runs in the `Burstable` QoS class because requests are less than limits.
[source,yaml]
----
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "200Mi"
requests:
memory: "100Mi"
----
If the selected policy is anything other than `none`, Topology Manager would process all the pods and it enforces resource alignment only for the `Guaranteed` Qos `Pod` specification.
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 it does not optimize for performance-sensitive workloads.
Other values enable the use of topology awareness information from device plugins core resources, such as CPU and memory. 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 _Topology Manager policies_.
The following example pod runs in the `Guaranteed` QoS class because requests are equal to limits.
[source,yaml]
----
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "200Mi"
cpu: "2"
example.com/device: "1"
requests:
memory: "200Mi"
cpu: "2"
example.com/device: "1"
----
Topology Manager would consider this pod. The Topology Manager would consult the Hint Providers, which are the CPU Manager, the Device Manager, and the Memory Manager, to get topology hints for the pod.
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.