Kubernetes Topology Manager Policies

You can apply the kube-topology-mgr-policy host label from Horizon or the CLI to set the Kubernetes Topology Manager policy.

The kube-topology-mgr-policy host label has four supported values:

• none

• best-effort

  This is the default when the static CPU policy is enabled.

• restricted

• single-numa-node

For more information on these settings, see the Kubernetes Topology Manager policies described at https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/#how-topology-manager-works.

Limitations

• The scheduler is not NUMA-aware and can therefore make suboptimal pod scheduling decisions when the Topology Manager policy on the destination node is taken into account.

• If a pod fails with Topology Affinity Error because it can’t satisfy the Topology Manager policy on the node where the schedule placed it, it will remain in the error state and not be retried. If the pod is part of a manager object such as ReplicaSet, Deployment, etc., then a new pod will be created. If that new pod is placed on the same node, it can result in a series of pods with a status of Topology Affinity Error. For more information, see https://github.com/kubernetes/kubernetes/issues/84757.

In light of these limitations, StarlingX recommends using the best-effort policy, which will cause Kubernetes to try to provide NUMA-affined resources without generating any unexpected errors if the policy cannot be satisfied.