add docs about net-topology plugin

Signed-off-by: lowang-bh <[email protected]>

Author: lowang-bh

docs/design/net-topology-aware.md

@@ -0,0 +1,82 @@
+# Net Topology Aware Plugin
+
+- [Net Topology Aware Plugin](#net-topology-aware-plugin)
+  - [Backgrounds](#backgrounds)
+  - [Motivation](#motivation)
+  - [Proposal one](#proposal-one)
+    - [Goals](#goals)
+    - [Non-Goals](#non-goals)
+    - [Design Action](#design-action)
+      - [Pod scheduling process](#pod-scheduling-process)
+      - [Usage](#usage)
+    - [Drawbacks](#drawbacks)
+
+## Backgrounds
+
+Usually, a kubernetes cluster has many nodes, and those nodes are in different idc, chassis, and even different switches.
+Data transformations across different idc, chassis and switches has different performance. Some latency sensitive workloads are need to run in same idc, even in same topology devices, such as chassis and switch.
+
+## Motivation
+
+We target to make scheduler net-topology aware so as to achieve the following:
+
+- best effort to schedule same job to same topology devices, such as same idc, chassis or switch.
+
+## Proposal one
+
+This proposal need cluster administrator to manage the network topology labels on k8s nodes. They can label those nodes
+
+within same topologies a same label value.
+
+### Goals
+
+- Support single-key topology configuration, try to schedule job's all tasks to nodes which have same value with that key
+- Support multiple-key topology policies, the key at front get higher score
+
+### Non-Goals
+
+- Not to find the global solutions among nodes with all values of that key
+
+### Design Action
+
+#### Pod scheduling process
+
+1. when the first task of a job is allocated to a node, record the node's topology information in the plugin
+2. when scheduling other tasks, a node with same topology as the allocated tasks, get a higher score. Otherwise, get a zero score.
+3. If a node has multiple keys same as what's in the configured list, the first key matching the configured keys has higher score
+
+```go
+nodeOrderFn := func(task *api.TaskInfo, node *api.NodeInfo) (float64, error){
+    ...
+    score := 0
+    weight := np.weight
+    tlabels := tNode.Node.Labels
+    labels := node.Node.Labels
+    lenth := len(np.topologyKeys)
+    for i, key := range np.topologyKeys {
+        if tlabels[key] == labels[key] {
+            score += (lenth - i) //  key with more priority at front of which with less priority
+            break
+        }
+    }
+    return float64(score * weight), nil
+}
+```
+
+#### Usage
+
+1. label nodes with some key-value pairs, for example switch=NvLink-A100, rack=rack1,rack2, idc=bj,sh to partition nodes to different topology zones.
+2. add net-topology plugin in scheduler-configuration
+
+```yaml
+- plugins:
+   - name: net-topology
+     arguments:
+       net-topology.type: static
+       net-topology.keys: rack,switch,idc
+       net-topology.weight: 10
+```
+
+### Drawbacks
+
+It is not a global solution which put a job's all tasks in same topology nodes. For example, nodes list with key-value1 has not enough resource, but nodes list with key-value2 does, if first task was bind to nodes with key-value1, then other tasks will all try that nodes list.