Fix en language misspell (#18201)
* fix misspell Signed-off-by: Xiang Dai <764524258@qq.com> * clean white noise Signed-off-by: Xiang Dai <764524258@qq.com>
This commit is contained in:
committed by
Kubernetes Prow Robot
parent
746a659723
commit
f21f4b2257
@@ -188,7 +188,7 @@ Support for the "PodResources service" requires `KubeletPodResources` [feature g
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
|
||||
|
||||
The Topology Manager is a Kubelet component that allows resources to be co-ordintated in a Topology aligned manner. In order to do this, the Device Plugin API was extended to include a `TopologyInfo` struct.
|
||||
The Topology Manager is a Kubelet component that allows resources to be co-ordintated in a Topology aligned manner. In order to do this, the Device Plugin API was extended to include a `TopologyInfo` struct.
|
||||
|
||||
|
||||
```gRPC
|
||||
@@ -200,7 +200,7 @@ message NUMANode {
|
||||
int64 ID = 1;
|
||||
}
|
||||
```
|
||||
Device Plugins that wish to leverage the Topology Manager can send back a populated TopologyInfo struct as part of the device registration, along with the device IDs and the health of the device. The device manager will then use this information to consult with the Topology Manager and make resource assingment decisions.
|
||||
Device Plugins that wish to leverage the Topology Manager can send back a populated TopologyInfo struct as part of the device registration, along with the device IDs and the health of the device. The device manager will then use this information to consult with the Topology Manager and make resource assignment decisions.
|
||||
|
||||
`TopologyInfo` supports a `nodes` field that is either `nil` (the default) or a list of NUMA nodes. This lets the Device Plugin publish that can span NUMA nodes.
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ By using Node label matching between the source and destination, the operator
|
||||
may designate groups of Nodes that are "closer" and "farther" from one another,
|
||||
using whatever metric makes sense for that operator's requirements. For many
|
||||
operators in public clouds, for example, there is a preference to keep service
|
||||
traffic withing the same zone, because interzonal traffic has a cost associated
|
||||
traffic within the same zone, because interzonal traffic has a cost associated
|
||||
with it, while intrazonal traffic does not. Other common needs include being able
|
||||
to route traffic to a local Pod managed by a DaemonSet, or keeping traffic to
|
||||
Nodes connected to the same top-of-rack switch for the lowest latency.
|
||||
|
||||
Reference in New Issue
Block a user