[topologymanager] whitespace cleanup
Signed-off-by: pprokop <pprokop@nvidia.com>pull/41718/head
parent
b96f68742a
commit
bd9fed6316
|
@ -28,7 +28,7 @@ disjoint set of components.
|
|||
|
||||
_Topology Manager_ is a Kubelet component that aims to coordinate the set of components that are
|
||||
responsible for these optimizations.
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
@ -174,7 +174,7 @@ each Hint Provider to discover their resource availability. Using this informati
|
|||
Manager stores the preferred NUMA Node affinity for that container. If the affinity is not
|
||||
preferred, Topology Manager will store this and admit the pod to the node anyway.
|
||||
|
||||
The *Hint Providers* can then use this information when making the
|
||||
The *Hint Providers* can then use this information when making the
|
||||
resource allocation decision.
|
||||
|
||||
### restricted policy {#policy-restricted}
|
||||
|
@ -190,7 +190,7 @@ reschedule the pod. It is recommended to use a ReplicaSet or Deployment to trigg
|
|||
the pod. An external control loop could be also implemented to trigger a redeployment of pods that
|
||||
have the `Topology Affinity` error.
|
||||
|
||||
If the pod is admitted, the *Hint Providers* can then use this information when making the
|
||||
If the pod is admitted, the *Hint Providers* can then use this information when making the
|
||||
resource allocation decision.
|
||||
|
||||
### single-numa-node policy {#policy-single-numa-node}
|
||||
|
@ -318,7 +318,7 @@ spec:
|
|||
This pod runs in the `BestEffort` QoS class because there are no CPU and memory requests.
|
||||
|
||||
The Topology Manager would consider the above pods. The Topology Manager would consult the Hint
|
||||
Providers, which are CPU and Device Manager to get topology hints for the pods.
|
||||
Providers, which are CPU and Device Manager to get topology hints for the pods.
|
||||
|
||||
In the case of the `Guaranteed` pod with integer CPU request, the `static` CPU Manager policy
|
||||
would return topology hints relating to the exclusive CPU and the Device Manager would send back
|
||||
|
@ -337,7 +337,7 @@ of the requested devices.
|
|||
|
||||
Using this information the Topology Manager calculates the optimal hint for the pod and stores
|
||||
this information, which will be used by the Hint Providers when they are making their resource
|
||||
assignments.
|
||||
assignments.
|
||||
|
||||
### Known Limitations
|
||||
|
||||
|
@ -346,4 +346,4 @@ assignments.
|
|||
generating their hints.
|
||||
|
||||
2. The scheduler is not topology-aware, so it is possible to be scheduled on a node and then fail
|
||||
on the node due to the Topology Manager.
|
||||
on the node due to the Topology Manager.
|
Loading…
Reference in New Issue