whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Revert v1.17 release changes on v1.16 branch (#18123)

Browse Source 
This reverts commits:
  1131f8603e.
  cf5b8b200c.
  75de70a431.
  dff2f7b960.
  cf925bb688.
  ffd1363c0e.
  87a2cafb20.
  ffe259d6f2.
This commit is contained in:
Tim Bannister
2019-12-13 19:51:36 +00:00
committed by Kubernetes Prow Robot
parent 5733771d62
commit 065ccd94be
74 changed files with 647 additions and 63699 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/administer-cluster/topology-manager.md
+5 -38
View File
@@ -1,6 +1,5 @@
---
title: Control Topology Management Policies on a node
reviewers:
- ConnorDoyle
- klueska
@@ -49,9 +48,9 @@ The hint is then stored in the Topology Manager for use by the *Hint Providers*
The Topology Manager currently:
- Works on Nodes with the `static` CPU Manager Policy enabled. See [control CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/)
- Works on Pods making CPU requests or Device requests via extended resources
- Works on Pods in the `Guaranteed` {{< glossary_tooltip text="QoS class" term_id="qos-class" >}}
If these conditions are met, Topology Manager will align the requested resources.
If these conditions are met, Topology Manager will align CPU and device requests.
Topology Manager supports four allocation policies. You can set a policy via a Kubelet flag, `--topology-manager-policy`.
There are four supported policies:
@@ -84,9 +83,6 @@ Using this information, the Topology Manager stores the
preferred NUMA Node affinity for that container. If the affinity is not preferred,
Topology Manager will reject this pod from the node. This will result in a pod in a `Terminated` state with a pod admission failure.
Once the pod is in a `Terminated` state, the Kubernetes scheduler will **not** attempt to reschedule the pod. It is recommended to use a ReplicaSet or Deployment to trigger a redeploy of 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
resource allocation decision.
@@ -99,8 +95,6 @@ If it is, Topology Manager will store this and the *Hint Providers* can then use
resource allocation decision.
If, however, this is not possible then the Topology Manager will reject the pod from the node. This will result in a pod in a `Terminated` state with a pod admission failure.
Once the pod is in a `Terminated` state, the Kubernetes scheduler will **not** attempt to reschedule the pod. It is recommended a Deployment with Replicas to trigger a redeploy of the pod.
An external control loop could be also implemented to trigger a redeployment of pods that have the `Topology Affinity` error.
### Pod Interactions with Topology Manager Policies
@@ -152,36 +146,9 @@ spec:
This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
Topology Manager would consider this Pod. The Topology Manager consults the CPU Manager `static` policy, which returns the topology of available CPUs.
Topology Manager also consults Device Manager to discover the topology of available devices for example.com/device.
```yaml
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
example.com/deviceA: "1"
example.com/deviceB: "1"
requests:
example.com/deviceA: "1"
example.com/deviceB: "1"
```
This pod runs in the `BestEffort` QoS class because there are no CPU and memory requests.
The Topology Manager would consider both of the above pods. The Topology Manager would consult the Hint Providers, which are CPU and Device Manager to get topology hints for the pods.
In the case of the `Guaranteed` pod the `static` CPU Manager policy would return hints relating to the CPU request and the Device Manager would send back hints for the requested device.
In the case of the `BestEffort` pod the CPU Manager would send back the default hint as there is no CPU request and the Device Manager would send back the hints for each 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.
### Known Limitations
1. As of K8s 1.16 the Topology Manager is currently only guaranteed to work if a *single* container in the pod spec requires aligned resources. This is due to the hint generation being based on current resource allocations, and all containers in a pod generate hints before any resource allocation has been made. This results in unreliable hints for all but the first container in a pod.
*Due to this limitation if multiple pods/containers are considered by Kubelet in quick succession they may not respect the Topology Manager policy.
2. The maximum number of NUMA nodes that Topology Manager will allow is 8, past this there will be a state explosion when trying to enumerate the possible NUMA affinities and generating their hints.
3. 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.
Topology Manager will use this information to store the best Topology for this container. In the case of this Pod, CPU and Device Manager will use this stored information at the resource allocation stage.
{{% /capture %}}