Docs: Implement Plugins expandable dropdown submenu under Scheduler with visual hierarchy

config/_default/menus.toml

@@ -90,7 +90,7 @@
 
 [[docs]]
   name = "Contribution"
-  weight = 8
+  weight = 9
   identifier = "contribution"
 
 # Documentation version v1.12.0

content/en/docs/binpack.md

@@ -0,0 +1,26 @@
++++
+title = "Binpack Plugin"
+
+date = 2021-05-13
+lastmod = 2021-05-13
+
+draft = false  # Is this a draft? true/false
+toc = true  # Show table of contents? true/false
+type = "docs"  # Do not modify.
+
+# Add menu entry to sidebar.
+linktitle = "Binpack"
+[menu.docs]
+  parent = "plugins"
+  weight = 2
++++
+
+## Overview
+
+The goal of the BinPack scheduling algorithm is to fill as many existing nodes as possible (try not to allocate blank nodes). In the concrete implementation, BinPack scheduling algorithm scores the nodes that can be delivered, and the higher the score, the higher the resource utilization rate of nodes. Binpack algorithm can fill up the nodes as much as possible to close the application load to some nodes, which is very conducive to the automatic expansion capacity function of K8s cluster nodes.
+
+The BinPack algorithm is injected into the Volcano-Scheduler process as a plug-in and will be applied during the Pod stage of node selection. When calculating the Binpack algorithm, the Volcano-Scheduler considers the various resources requested by Pod and averages them according to the weights configured for each resource. The weight of each resource in the node score calculation is different, depending on the weight value configured by the administrator for each resource. Different plug-ins also need to assign different weights when calculating node scores, and the Scheduler also sets the score weights for BinPack plugins.
+
+## Scenario
+
+The BinPack algorithm is good for small jobs that can fill as many nodes as possible. For example, the single query job in the big data scene, the order generation in the e-commerce seckill scene, the single identification job in the AI scene, and the high concurrency service scene on the Internet, etc. This scheduling algorithm can reduce the fragmentation in the node as much as possible, and reserve enough resource space on the idle machine for Pod which has applied for more resource requests, so as to maximize the utilization of idle resources under the cluster.

content/en/docs/drf.md

@@ -0,0 +1,26 @@
++++
+title = "DRF Plugin"
+
+date = 2021-05-13
+lastmod = 2021-05-13
+
+draft = false  # Is this a draft? true/false
+toc = true  # Show table of contents? true/false
+type = "docs"  # Do not modify.
+
+# Add menu entry to sidebar.
+linktitle = "DRF"
+[menu.docs]
+  parent = "plugins"
+  weight = 4
++++
+
+{{<figure library="1" src="drfjob.png" title="Drf plugin">}}
+
+## Overview
+
+The full name of DRF scheduling algorithm is Dominant Resource Fairness, which is a scheduling algorithm based on the container group Dominant Resource. Dominant Resource is the largest percentage of all required resources for a container group. The DRF algorithm selects the Dominant Resource that is the smallest in a series of container groups for priority scheduling. This can meet more job, not because a fat business, starve a large number of small business. DRF scheduling algorithm can ensure that many types of resources coexist in the environment, as far as possible to meet the fair principle of allocation.
+
+## Scenario
+
+The DRF scheduling algorithm gives priority to the throughput of the business in the cluster and is suitable for batch small business scenarios such as a single AI training, a single big data calculation and a query.

content/en/docs/gang.md

@@ -0,0 +1,28 @@
++++
+title = "Gang Plugin"
+
+date = 2021-05-13
+lastmod = 2021-05-13
+
+draft = false  # Is this a draft? true/false
+toc = true  # Show table of contents? true/false
+type = "docs"  # Do not modify.
+
+# Add menu entry to sidebar.
+linktitle = "Gang"
+[menu.docs]
+  parent = "plugins"
+  weight = 1
++++
+
+{{<figure library="1" src="gang.png" title="gang plugin">}}
+
+## Overview
+
+The Gang scheduling strategy is one of the core scheduling algorithms of the Volcano-Scheduler. It meets the scheduling requirements of "All or nothing" in the scheduling process and avoids the waste of cluster resources caused by arbitrary scheduling of Pod. The Gang scheduler algorithm is to observe whether the scheduled number of Pods under Job meets the minimum number of runs. When the minimum number of runs of Job is satisfied, the scheduling action is executed for all Pods under Job; otherwise, it is not executed.
+
+## Scenario
+
+The Gang scheduling algorithm based on the container group concept is well suited for scenarios that require multi-process collaboration. AI scenes often contain complex processes. Data Ingestion, Data Analysts, Data Splitting, trainers, Serving, Logging, etc., which require a group of containers to work together, are suitable for container-based Gang scheduling strategies. Multi-thread parallel computing communication scenarios under MPI computing framework are also suitable for Gang scheduling because master and slave processes need to work together. Containers under the container group are highly correlated, and there may be resource contention. The overall scheduling allocation can effectively solve the deadlock.
+
+In the case of insufficient cluster resources, the scheduling strategy of Gang can significantly improve the utilization of cluster resources.

content/en/docs/nodeorder.md

@@ -0,0 +1,24 @@
++++
+title = "Nodeorder Plugin"
+
+date = 2021-05-13
+lastmod = 2021-05-13
+
+draft = false  # Is this a draft? true/false
+toc = true  # Show table of contents? true/false
+type = "docs"  # Do not modify.
+
+# Add menu entry to sidebar.
+linktitle = "Nodeorder"
+[menu.docs]
+  parent = "plugins"
+  weight = 8
++++
+
+## Overview
+
+The NodeOrder Plugin is a scheduling optimization strategy that scores nodes from various dimensions through simulated assignments to find the node that is best suited for the current job. The scoring parameters are configured by the user. The parameter contains the Affinity、reqResource、LeastReqResource、MostResource、balanceReqResouce.
+
+## Scenario
+
+NodeOrder Plugin provides scoring criteria of multiple dimensions for scheduling, and the combination of different dimensions enables users to flexibly configure appropriate scheduling policies according to their own needs.

content/en/docs/numa-aware.md

@@ -0,0 +1,34 @@
++++
+title = "Numa-aware Plugin"
+
+date = 2021-05-13
+lastmod = 2021-05-13
+
+draft = false  # Is this a draft? true/false
+toc = true  # Show table of contents? true/false
+type = "docs"  # Do not modify.
+
+# Add menu entry to sidebar.
+linktitle = "Numa-aware"
+[menu.docs]
+  parent = "plugins"
+  weight = 11
++++
+
+## Overview
+
+When the node runs many CPU-bound pods, the workload can move to different CPU cores depending on whether the pod is throttled and which CPU cores are available at scheduling time. Many workloads are not sensitive to this migration and thus work fine without any intervention. However, in workloads where CPU cache affinity and scheduling latency significantly affect workload performance, the kubelet allows alternative CPU management policies to determine some placement preferences on the node.
+
+The CPU Manager and the Topology Manager are all Kubelet components, However There is the following limitation:
+
+- 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. this is unacceptable for TensorFlow job. If any worker or ps failed on node, the job will fail.
+- The managers are node-level that results in an inability to match the best node for NUMA topology in the whole cluster.
+
+The Numa-Aware Plugin aims to address these limitations.
+
+- Support cpu resource topology scheduling.
+- Support pod-level topology policies.
+
+## Scenario
+
+Common scenarios for NUMA-Aware are computation-intensive jobs that are sensitive to CPU parameters, scheduling delays. Such as scientific calculation, video decoding, animation rendering, big data offline processing and other specific scenes.

content/en/docs/plugins-overview.md

@@ -0,0 +1,34 @@
++++
+title = "Plugins Overview"
+
+date = 2021-05-13
+lastmod = 2021-05-13
+
+draft = false  # Is this a draft? true/false
+toc = false  # Show table of contents? true/false
+type = "docs"  # Do not modify.
+
+linktitle = "Plugins"
+[menu.docs]
+  parent = "scheduler"
+  weight = 3
+  identifier = "plugins"
++++
+
+Volcano scheduler provides a rich set of plugins to support various scheduling scenarios. Each plugin implements specific scheduling algorithms and policies.
+
+## Available Plugins
+
+- **Gang**: All-or-nothing scheduling for batch jobs
+- **Binpack**: Maximize node resource utilization  
+- **Priority**: Job and task priority-based scheduling
+- **DRF**: Dominant Resource Fairness scheduling
+- **Proportion**: Queue-based resource allocation
+- **Task-topology**: Affinity and anti-affinity based scheduling
+- **Predicates**: Job pre-selection and filtering
+- **Nodeorder**: Multi-dimensional node scoring
+- **SLA**: Service Level Agreement enforcement
+- **TDM**: Time Division Multiplexing for shared nodes
+- **Numa-aware**: NUMA topology-aware scheduling
+
+Please select a specific plugin from the submenu to learn more about its functionality and use cases.