This is an automated email from the ASF dual-hosted git repository.
manirajv06 pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/yunikorn-site.git
The following commit(s) were added to refs/heads/master by this push:
new fbea42a3f9 [YUNIKORN-3265] Doc cleanup in yunikorn-site repo (#558)
fbea42a3f9 is described below
commit fbea42a3f94e748d3016de5f94761b6c1070c6a3
Author: Manikandan R <[email protected]>
AuthorDate: Wed Jun 10 16:08:37 2026 +0530
[YUNIKORN-3265] Doc cleanup in yunikorn-site repo (#558)
Cleaned up all plugin related docs, references etc
Closes: #558
Signed-off-by: Manikandan R <[email protected]>
---
.../scheduler_plugin.md | 3 ++
docs/developer_guide/build.md | 10 +----
docs/developer_guide/deployment.md | 5 ---
docs/developer_guide/env_setup.md | 30 ---------------
docs/user_guide/deployment_modes.md | 44 +++-------------------
docs/user_guide/service_config.md | 24 ++----------
sidebars.js | 2 +-
7 files changed, 14 insertions(+), 104 deletions(-)
diff --git a/docs/design/scheduler_plugin.md
b/docs/archived_design/scheduler_plugin.md
similarity index 97%
rename from docs/design/scheduler_plugin.md
rename to docs/archived_design/scheduler_plugin.md
index f26b86abc1..0adb38a38d 100644
--- a/docs/design/scheduler_plugin.md
+++ b/docs/archived_design/scheduler_plugin.md
@@ -21,6 +21,9 @@ title: K8s Scheduler Plugin
* limitations under the License.
-->
+
+NOTE: The plugin deployment mode is deprecated and no longer supported. Please
refer [deployment mode](user_guide/deployment_modes.md) section for more details
+
## Background
YuniKorn (on Kubernetes) is traditionally implemented as a ground-up
implementation of a Kubernetes scheduler.
diff --git a/docs/developer_guide/build.md b/docs/developer_guide/build.md
index 771046f6b6..88cca29676 100644
--- a/docs/developer_guide/build.md
+++ b/docs/developer_guide/build.md
@@ -60,8 +60,7 @@ Building the Docker images can be triggered by following
command:
make image
```
-This will generate images for the scheduler, scheduler plugin, and admission
-controller.
+This will generate images for the scheduler and admission controller.
The images created can be deployed directly on Kubernetes.
Some sample deployments that can be used are found under the
@@ -93,7 +92,6 @@ info in the image metadata. You can retrieve this information
with docker
```shell script
docker inspect apache/yunikorn:scheduler-amd64-latest
-docker inspect apache/yunikorn:scheduler-plugin-amd64-latest
docker inspect apache/yunikorn:admission-controller-amd64-latest
```
@@ -229,12 +227,6 @@ make run
This will launch a local scheduler and connect to the Kubernetes cluster
referenced in your `KUBECONFIG` or `$HOME/.kube/config`.
-To run YuniKorn in Kubernetes scheduler plugin mode instead, execute:
-
-```
-make run_plugin
-```
-
You can also use the same approach to run the scheduler locally but connecting
to a remote kubernetes cluster, as long as the `$HOME/.kube/config` file
is pointing to that remote cluster.
diff --git a/docs/developer_guide/deployment.md
b/docs/developer_guide/deployment.md
index a0feb723ad..b3b0dc7c22 100644
--- a/docs/developer_guide/deployment.md
+++ b/docs/developer_guide/deployment.md
@@ -85,11 +85,6 @@ The deployment will run 2 containers from your pre-built
docker images in 1 pod,
* yunikorn-scheduler-core (yunikorn scheduler core and shim for K8s)
* yunikorn-scheduler-web (web UI)
-Alternatively, the scheduler can be deployed as a K8S scheduler plugin:
-```
-kubectl create -f deployments/scheduler/plugin.yaml
-```
-
The pod is deployed as a customized scheduler, it will take the responsibility
to schedule pods which explicitly specifies `schedulerName: yunikorn` in pod's
spec. In addition to the `schedulerName`, you will also have to add a label
`applicationId` to the pod.
```yaml
metadata:
diff --git a/docs/developer_guide/env_setup.md
b/docs/developer_guide/env_setup.md
index 042ebaeb64..63390d18fe 100644
--- a/docs/developer_guide/env_setup.md
+++ b/docs/developer_guide/env_setup.md
@@ -225,36 +225,6 @@ Set the following values in the dialog (as shown):
Once the changes are done, click "Apply", then "Debug". You will need to
set proper breakpoints in order to debug the program.
-## Debug the scheduler plugin
-
-The scheduler may also be run in plugin mode. In this mode, the YuniKorn
-scheduler is built on top of the default scheduler and runs as a
-plugin (rather than completely standalone). Functionally, it performs the
-same tasks, but relies on the upstream Kubernetes scheduler codebase for
-common functionality.
-
-The run configuration for the scheduler in plugin mode is as follows:
-
-- Run Kind: Package
-- Package path: `github.com/apache/yunikorn-k8shim/pkg/cmd/schedulerplugin`
-- Working directory: Project base directory (`yunikorn-k8shim`)
-- Program arguments:
- ```
- --bind-address=0.0.0.0
- --leader-elect=false
- --config=conf/scheduler-config-local.yaml
- -v=2
- ```
-- Environment: If `KUBECONFIG` is not set globally, ensure it is set here.
- Additionally, you may want to set `NAMESPACE=yunikorn`, as otherwise
- YuniKorn will look for the `yunikorn-configs` ConfigMap under the
- `default` Kubernetes namespace.
-
-Additionally, before running for the first time, run `make init` from a
-terminal in the root of the `yunikorn-k8shim` repository. This will
-generate the contents of `conf/scheduler-config-local.yaml`, which is
-required.
-
## Access remote Kubernetes cluster
This setup assumes you have already installed a remote Kubernetes cluster.
diff --git a/docs/user_guide/deployment_modes.md
b/docs/user_guide/deployment_modes.md
index 9925374f41..f7f5d3e650 100644
--- a/docs/user_guide/deployment_modes.md
+++ b/docs/user_guide/deployment_modes.md
@@ -22,48 +22,14 @@ specific language governing permissions and limitations
under the License.
-->
-## YuniKorn deployment modes
+## YuniKorn deployment mode
-***NOTE:*** **This section is maintained largely for historical context.
-The plugin deployment mode is deprecated and no longer supported. The
-removal timeline agreed upon by the YuniKorn community is as follows:**
+YuniKorn can be deployed in "standard" mode, an only way to run the scheduler
as a standalone Kubernetes scheduler.
-* **YuniKorn 1.6**: Deprecation announced
-* **YuniKorn 1.7**: Scheduler will emit warnings if plugin mode is in use
-* **YuniKorn 1.8**: YuniKorn will no longer ship plugin mode binaries
-* **YuniKorn 1.9**: Implementation removed from codebase
-
-YuniKorn can be deployed in two different modes: standard and plugin.
-In standard mode, YuniKorn runs as a standalone Kubernetes scheduler.
-In plugin mode (now deprecated), YuniKorn is implemented as a set of
-plugins on top of the default Kubernetes scheduling framework.
+Standard mode is the only available option and set as default too. It is
stable, efficient, and very
+performant. It is well-suited for all YuniKorn deployments and is recommended.
-Regardless of the YuniKorn deployment mode in use, it is recommended to
-run the admission controller as well, as this will ensure that only a single
+It is recommended to run the admission controller as well, as this will ensure
that only a single
scheduler is active within your Kubernetes cluster. In this mode, the default
Kubernetes scheduler (which is always running) will be bypassed for all pods
except YuniKorn itself.
-
-### Standard mode
-
-Standard mode is currently the default. It is stable, efficient, and very
-performant. It is well-suited for all YuniKorn deployments and is recommended.
-
-### Plugin mode
-
-**Deprecated for removal**
-
-Plugin mode was an experimental deployment model where the scheduler was
-implemented on top of the default Kubernetes scheduler as a set of plugins.
-Originally, this was expected to help provide better compatibility with the
-default Kubernetes scheduler, but that did not end up being the case.
-Consequently, the plugin mode is now deprecated and will be removed from a
-future YuniKorn release.
-
-It is not recommended to use plugin mode for any new deployments, and existing
-users should migrate to standard mode as soon as practically possible. The
-standard mode is much more mature, providing excellent compatibility with the
-default Kubernetes scheduler (as it now uses the same scheduler plugins
-internally) while providing significantly better performance then either the
-default Kubernetes scheduler or the now deprecated YuniKorn plugin deployment
-mode.
diff --git a/docs/user_guide/service_config.md
b/docs/user_guide/service_config.md
index 0a65e6d7e7..453ec222ff 100644
--- a/docs/user_guide/service_config.md
+++ b/docs/user_guide/service_config.md
@@ -46,12 +46,6 @@ image:
tag: scheduler-{version} # default depends on YuniKorn version
pullPolicy: Always
-# Image information for the plugin scheduler
-pluginImage:
- repository: apache/yunikorn
- tag: scheduler-plugin-{version} # default depends on YuniKorn version
- pullPolicy: Always
-
# Image information for the web UI
web:
image:
@@ -402,15 +396,7 @@ Example:
```yaml
embedAdmissionController: false
```
-#### enableSchedulerPlugin
-Controls whether to run YuniKorn in scheduler plugin mode.
-
-Default: `false`
-Example:
-```yaml
-enableSchedulerPlugin: true
-```
#### enableWebService
Controls whether to enable the YuniKorn Web UI service.
@@ -973,9 +959,8 @@ all pods which are scheduled by YuniKorn will have an
`applicationId` label appl
When running YuniKorn using the standard deployment model, all pods should be
labeled,
as YuniKorn is unable to schedule pods without an `applicationId` defined.
-When running YuniKorn using the scheduler plugin deployment model, this
setting can
-be used to filter which namespaces should be scheduled via YuniKorn's queueing
model,
-and which should bypass queueing and be scheduled by the embedded default
scheduler.
+This setting can be used to filter which namespaces should be scheduled via
YuniKorn's queueing model,
+and which should bypass queueing and be scheduled by the default scheduler.
This setting is a comma-separated list of regular expressions. If this setting
is an empty string, all pods forwarded to YuniKorn will have an
`applicationId` label
@@ -997,9 +982,8 @@ acts as an exception list to
`admissionController.filtering.labelNamespaces`.
When running YuniKorn using the standard deployment model, all pods should be
labeled,
as YuniKorn is unable to schedule pods without an `applicationId` defined.
-When running YuniKorn using the scheduler plugin deployment model, this
setting can
-be used to filter which namespaces should be scheduled via YuniKorn's queueing
model,
-and which should bypass queueing and be scheduled by the embedded default
scheduler.
+This setting can be used to filter which namespaces should be scheduled via
YuniKorn's queueing model,
+and which should bypass queueing and be scheduled by the default scheduler.
This setting is a comma-separated list of regular expressions. If this setting
is an empty string, no exclusions to
`admissionController.filtering.labelNamespaces` will
diff --git a/sidebars.js b/sidebars.js
index 98a266fa11..a7ecb9ec5b 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -94,7 +94,6 @@ module.exports = {
label: 'Designs',
items: [
'design/architecture',
- 'design/scheduler_plugin',
'design/gang_scheduling',
'design/user_group',
'design/user_based_resource_usage_tracking',
@@ -124,6 +123,7 @@ module.exports = {
'archived_design/state_aware_scheduling',
'archived_design/cross_queue_preemption',
'archived_design/pluggable_app_management',
+ 'archived_design/scheduler_plugin',
]
},
],
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
