Enabling CPU Manager and CPU Pinning in OpenShift

By default, OpenShift is a greedy scheduler, when a Pod starts it grabs the first requested resource CPU/Memory. There is a reserved bit of memory and CPU for kubelet and System services saved. A Pod may end up spanning different NUMA domains

The CPU Manager packs each Pod onto NUMA domains:.

1. single-numa-node a pod might fail to schedule on a node that has enough total CPU capacity but lacks enough contiguous cores. If you go to schedule a 8 vCPU pod, and you have 4vcpu on one node, and 4 vcpu on another, it won’t be able to allocate ending with a TopologyAffinityError.
2. restricted packs it into as few NUMA nodes as possible. This one is probably preferred as it allows for rounding.

Keep in mind, this applies for the whole system, and you may want to isolate to only a few workers you can put them in a separate pool. You can see https://docs.redhat.com/en/documentation/openshift_container_platform/4.20/html/scalability_and_performance/using-cpu-manager#setting_up_cpu_manager_using-cpu-manager-and-topology-manager

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: cpumanager-enabled
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""
  kubeletConfig:
    cpuManagerPolicy: static 
    cpuManagerReconcilePeriod: 5s
    topologyManagerPolicy: single-numa-node 
    reservedSystemCPUs: "0,1" 
    memoryManagerPolicy: Static

If a Pod is idle, those cores sit idle. They won’t share the spare cycles of another Pod.

If a Pod used 100m, it’ll need to specificy round numbers now cpu: "2" in some cases.

For large workloads , CPU pinning is most effective when the pod is sized to fit within a single NUMA node. If your pod is so large that it spans multiple sockets, the benefits of pinning diminish unless the application itself is NUMA-aware.

You can see more details at OpenShift 4.20: Using CPU Manager and Topology Manager [docs.redhat.com]