You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@yunikorn.apache.org by cc...@apache.org on 2023/06/12 14:47:31 UTC
[yunikorn-site] branch master updated: [YUNIKORN-1760] Update website for v1.3.0 release (#311)
This is an automated email from the ASF dual-hosted git repository.
ccondit 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 4ba90ef293 [YUNIKORN-1760] Update website for v1.3.0 release (#311)
4ba90ef293 is described below
commit 4ba90ef2932d6b50a53c886a714033bff1bd09be
Author: 0yukali0 <a0...@gmail.com>
AuthorDate: Mon Jun 12 09:46:59 2023 -0500
[YUNIKORN-1760] Update website for v1.3.0 release (#311)
Closes: #311
Signed-off-by: Craig Condit <cc...@apache.org>
---
docusaurus.config.js | 3 +-
.../version-1.3.0/api/cluster.md | 73 +
.../version-1.3.0/api/scheduler.md | 1484 +++++++++++++++
.../version-1.3.0/api/system.md | 225 +++
.../version-1.3.0/assets | 1 +
.../version-1.3.0/developer_guide/env_setup.md | 192 ++
.../version-1.3.0/developer_guide/translation.md | 127 ++
.../version-1.3.0/get_started/core_features.md | 71 +
.../version-1.3.0/get_started/get_started.md | 76 +
.../evaluate_perf_function_with_kubemark.md | 120 ++
.../version-1.3.0/performance/metrics.md | 105 ++
.../performance/performance_tutorial.md | 451 +++++
.../version-1.3.0/performance/profiling.md | 115 ++
.../version-1.3.0/user_guide/deployment_modes.md | 48 +
.../version-1.3.0/user_guide/gang_scheduling.md | 297 +++
.../version-1.3.0/user_guide/placement_rules.md | 296 +++
.../version-1.3.0/user_guide/prometheus.md | 82 +
.../version-1.3.0/user_guide/queue_config.md | 382 ++++
.../user_guide/resource_quota_mgmt.md | 336 ++++
.../version-1.3.0/user_guide/service_config.md | 792 ++++++++
.../version-1.3.0/user_guide/sorting_policies.md | 190 ++
.../version-1.3.0/user_guide/troubleshooting.md | 189 ++
.../user_guide/usergroup_resolution.md | 121 ++
.../user_guide/workloads/run_flink.md | 66 +
.../version-1.3.0/user_guide/workloads/run_mpi.md | 107 ++
.../user_guide/workloads/run_spark.md | 159 ++
.../user_guide/workloads/run_tensorflow.md | 229 +++
.../user_guide/workloads/workload_overview.md | 56 +
.../community/download.md | 12 +-
.../release-announce/1.3.0.md | 87 +
src/pages/community/download.md | 12 +-
src/pages/release-announce/1.3.0.md | 2 +-
versioned_docs/version-1.3.0/api/cluster.md | 73 +
versioned_docs/version-1.3.0/api/scheduler.md | 1890 ++++++++++++++++++++
versioned_docs/version-1.3.0/api/system.md | 225 +++
.../archived_design/cross_queue_preemption.md | 126 ++
.../version-1.3.0/archived_design/k8shim.md | 74 +
.../archived_design/namespace_resource_quota.md | 183 ++
.../version-1.3.0/archived_design/predicates.md | 80 +
.../archived_design/scheduler_core_design.md | 401 +++++
.../version-1.3.0/assets/RunningSparkOnK8s.png | Bin 0 -> 25878 bytes
.../version-1.3.0/assets/allocation_4k.png | Bin 0 -> 68868 bytes
.../version-1.3.0/assets/application-state.png | Bin 0 -> 117964 bytes
.../version-1.3.0/assets/architecture.png | Bin 0 -> 188534 bytes
.../version-1.3.0/assets/cpu_profile.jpg | Bin 0 -> 259919 bytes
.../version-1.3.0/assets/dashboard_secret.png | Bin 0 -> 31815 bytes
.../assets/dashboard_token_select.png | Bin 0 -> 47533 bytes
.../assets/docker-dektop-minikube.png | Bin 0 -> 249095 bytes
.../version-1.3.0/assets/docker-desktop.png | Bin 0 -> 247891 bytes
.../version-1.3.0/assets/external_userinfo.png | Bin 0 -> 112563 bytes
.../version-1.3.0/assets/fifo-state-example.png | Bin 0 -> 239302 bytes
.../version-1.3.0/assets/gang_clean_up.png | Bin 0 -> 169887 bytes
.../version-1.3.0/assets/gang_generic_flow.png | Bin 0 -> 222524 bytes
.../version-1.3.0/assets/gang_scheduling_intro.png | Bin 0 -> 43907 bytes
.../version-1.3.0/assets/gang_timeout.png | Bin 0 -> 179466 bytes
.../version-1.3.0/assets/gang_total_ask.png | Bin 0 -> 22557 bytes
.../version-1.3.0/assets/goland_debug.jpg | Bin 0 -> 198845 bytes
.../version-1.3.0/assets/grafana_dashboard.png | Bin 0 -> 215232 bytes
.../version-1.3.0/assets/grafana_login_page.png | Bin 0 -> 1785895 bytes
.../version-1.3.0/assets/import_dashboard_01.png | Bin 0 -> 701141 bytes
.../version-1.3.0/assets/import_dashboard_02.png | Bin 0 -> 283108 bytes
.../assets/k8shim-application-state.png | Bin 0 -> 129912 bytes
.../version-1.3.0/assets/k8shim-node-state.png | Bin 0 -> 52316 bytes
.../assets/k8shim-scheduler-state.png | Bin 0 -> 53283 bytes
.../version-1.3.0/assets/k8shim-task-state.png | Bin 0 -> 144820 bytes
.../version-1.3.0/assets/namespace-mapping.png | Bin 0 -> 327547 bytes
.../version-1.3.0/assets/node-bin-packing.png | Bin 0 -> 232909 bytes
versioned_docs/version-1.3.0/assets/node-fair.png | Bin 0 -> 462310 bytes
.../version-1.3.0/assets/node_fairness_conf.png | Bin 0 -> 12287 bytes
.../version-1.3.0/assets/object-state.png | Bin 0 -> 39732 bytes
.../version-1.3.0/assets/perf-tutorial-build.png | Bin 0 -> 53518 bytes
.../assets/perf-tutorial-resultDiagrams.png | Bin 0 -> 251263 bytes
.../assets/perf-tutorial-resultLog.png | Bin 0 -> 204787 bytes
.../version-1.3.0/assets/perf_e2e_test.png | Bin 0 -> 3957 bytes
.../version-1.3.0/assets/perf_e2e_test_conf.png | Bin 0 -> 25200 bytes
.../version-1.3.0/assets/perf_node_fairness.png | Bin 0 -> 26614 bytes
.../version-1.3.0/assets/perf_throughput.png | Bin 0 -> 13024 bytes
.../version-1.3.0/assets/pluggable-app-mgmt.jpg | Bin 0 -> 79170 bytes
.../version-1.3.0/assets/predicateComaparation.png | Bin 0 -> 182417 bytes
.../version-1.3.0/assets/predicate_4k.png | Bin 0 -> 86281 bytes
.../version-1.3.0/assets/preemption_fence.png | Bin 0 -> 105855 bytes
.../version-1.3.0/assets/priority-flows.png | Bin 0 -> 233513 bytes
.../version-1.3.0/assets/priority-tree.png | Bin 0 -> 142135 bytes
.../version-1.3.0/assets/prometheus-cmd.png | Bin 0 -> 542991 bytes
.../version-1.3.0/assets/prometheus-web-ui.png | Bin 0 -> 324110 bytes
versioned_docs/version-1.3.0/assets/prometheus.png | Bin 0 -> 88021 bytes
.../version-1.3.0/assets/queue-fairness.png | Bin 0 -> 173299 bytes
.../version-1.3.0/assets/queue-resource-quotas.png | Bin 0 -> 283689 bytes
.../version-1.3.0/assets/quota_check.png | Bin 0 -> 235186 bytes
.../assets/resilience-node-recovery.jpg | Bin 0 -> 319477 bytes
.../version-1.3.0/assets/resilience-workflow.jpg | Bin 0 -> 441551 bytes
.../assets/scheduling_no_predicate_4k.png | Bin 0 -> 96404 bytes
.../assets/scheduling_with_predicate_4k_.png | Bin 0 -> 107557 bytes
.../version-1.3.0/assets/simple_preemptor.png | Bin 0 -> 81655 bytes
.../version-1.3.0/assets/sparkResult.png | Bin 0 -> 38170 bytes
.../version-1.3.0/assets/tf-job-gpu-on-logs.png | Bin 0 -> 221691 bytes
.../version-1.3.0/assets/tf-job-gpu-on-ui.png | Bin 0 -> 101211 bytes
.../version-1.3.0/assets/tf-job-on-ui.png | Bin 0 -> 327800 bytes
versioned_docs/version-1.3.0/assets/throughput.png | Bin 0 -> 252615 bytes
.../version-1.3.0/assets/throughput_3types.png | Bin 0 -> 173025 bytes
.../version-1.3.0/assets/throughput_conf.png | Bin 0 -> 26837 bytes
.../version-1.3.0/assets/translationBuilding.png | Bin 0 -> 152552 bytes
.../version-1.3.0/assets/translationDemo.png | Bin 0 -> 4243960 bytes
versioned_docs/version-1.3.0/assets/ug_lookup.png | Bin 0 -> 106036 bytes
.../version-1.3.0/assets/yk-ui-screenshots.gif | Bin 0 -> 813848 bytes
.../assets/yunikorn-gpu-time-slicing.png | Bin 0 -> 40653 bytes
.../version-1.3.0/assets/yunirkonVSdefault.png | Bin 0 -> 156100 bytes
.../version-1.3.0/design/architecture.md | 62 +
.../version-1.3.0/design/cache_removal.md | 456 +++++
versioned_docs/version-1.3.0/design/config_v2.md | 346 ++++
.../version-1.3.0/design/gang_scheduling.md | 605 +++++++
.../version-1.3.0/design/generic_resource.md | 75 +
.../design/interface_message_simplification.md | 309 ++++
.../design/pluggable_app_management.md | 75 +
versioned_docs/version-1.3.0/design/preemption.md | 581 ++++++
.../version-1.3.0/design/priority_scheduling.md | 408 +++++
versioned_docs/version-1.3.0/design/resilience.md | 144 ++
.../design/scheduler_configuration.md | 246 +++
.../design/scheduler_object_states.md | 127 ++
.../version-1.3.0/design/scheduler_plugin.md | 112 ++
.../version-1.3.0/design/simple_preemptor.md | 114 ++
.../version-1.3.0/design/state_aware_scheduling.md | 112 ++
.../version-1.3.0/design/user_group_enforcement.md | 478 +++++
.../version-1.3.0/design/user_group_handling.md | 290 +++
.../version-1.3.0/design/user_group_manager.md | 410 +++++
.../version-1.3.0/developer_guide/build.md | 192 ++
.../version-1.3.0/developer_guide/dependencies.md | 124 ++
.../version-1.3.0/developer_guide/deployment.md | 166 ++
.../version-1.3.0/developer_guide/env_setup.md | 190 ++
.../developer_guide/openshift_development.md | 182 ++
.../version-1.3.0/developer_guide/translation.md | 126 ++
.../version-1.3.0/get_started/core_features.md | 91 +
.../version-1.3.0/get_started/get_started.md | 83 +
.../evaluate_perf_function_with_kubemark.md | 120 ++
.../version-1.3.0/performance/metrics.md | 109 ++
.../performance/performance_tutorial.md | 522 ++++++
.../version-1.3.0/performance/profiling.md | 122 ++
versioned_docs/version-1.3.0/user_guide/acls.md | 119 ++
.../version-1.3.0/user_guide/deployment_modes.md | 51 +
.../version-1.3.0/user_guide/gang_scheduling.md | 296 +++
.../labels_and_annotations_in_yunikorn.md | 55 +
.../version-1.3.0/user_guide/placement_rules.md | 355 ++++
.../version-1.3.0/user_guide/priorities.md | 220 +++
.../version-1.3.0/user_guide/prometheus.md | 169 ++
.../version-1.3.0/user_guide/queue_config.md | 467 +++++
.../user_guide/resource_quota_mgmt.md | 334 ++++
.../version-1.3.0/user_guide/service_config.md | 915 ++++++++++
.../version-1.3.0/user_guide/sorting_policies.md | 193 ++
.../version-1.3.0/user_guide/troubleshooting.md | 221 +++
.../version-1.3.0/user_guide/use_case.md | 483 +++++
.../user_guide/usergroup_resolution.md | 120 ++
.../user_guide/workloads/run_flink.md | 66 +
.../version-1.3.0/user_guide/workloads/run_mpi.md | 112 ++
.../user_guide/workloads/run_nvidia.md | 346 ++++
.../user_guide/workloads/run_spark.md | 166 ++
.../user_guide/workloads/run_tensorflow.md | 228 +++
.../user_guide/workloads/workload_overview.md | 60 +
versioned_sidebars/version-1.3.0-sidebars.json | 94 +
versions.json | 1 +
159 files changed, 21591 insertions(+), 15 deletions(-)
diff --git a/docusaurus.config.js b/docusaurus.config.js
index 92d6ae6eb4..2be5a96967 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -61,8 +61,7 @@ module.exports = {
announcementBar: {
id: 'new_release',
content:
- 'Apache YuniKorn @KubeCon and CloudnativeCon Amsterdam 2023. ' +
- 'See the <a rel="noopener noreferrer" href="/community/events">events page</a> !',
+ '1.3.0 has been released, check the <a href="community/download">DOWNLOADS</a>.',
backgroundColor: '#fafbfc',
textColor: '#091E42',
},
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/api/cluster.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/api/cluster.md
new file mode 100644
index 0000000000..1f354d3b60
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/api/cluster.md
@@ -0,0 +1,73 @@
+---
+id: cluster
+title: 集群
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+## 集群
+
+将回传Yunikorn所管理的集群的信息。信息包括应用程序的数量（包含总数、失败、挂起、正在运行、已完成）和容器的数量，以及资源管理器的构建信息。
+
+**位置(URL)** : `/ws/v1/clusters`
+
+**方法(Method)** : `GET`
+
+**需求权限**：无
+
+### 成功时的响应
+
+**回传代码**：`200 OK`
+
+**示例**
+
+在本示例中，响应的内容来自一个群集，拥有一个资源管理器。
+
+```json
+[
+ {
+ "startTime": 1649167576110754000,
+ "rmBuildInformation": [
+ {
+ "buildDate": "2022-02-21T19:09:16+0800",
+ "buildVersion": "latest",
+ "isPluginVersion": "false",
+ "rmId": "rm-123"
+ }
+ ],
+ "partition": "default",
+ "clusterName": "kubernetes"
+ }
+]
+```
+
+### 出错时的响应
+
+**回传代码**：`500 Internal Server Error`
+
+**示例**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/api/scheduler.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/api/scheduler.md
new file mode 100644
index 0000000000..19b9327958
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/api/scheduler.md
@@ -0,0 +1,1484 @@
+---
+id: scheduler
+title: 调度器
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# 概要
+
+Yunikorn调度器能透过REST API来返回多个对象的信息
+其中许多API将回传资源集合。在内部中，所有资源被「有符号的64位整数类型」所表示。当解析REST API的响应时，类型为`memory`的资源以bytes作为单位，而`vcore`则以一千表示一个CPU核心。而这两类之外的其他资源种类则没有具体指定。
+
+在与app/node相关调用的响应中，包含一个`allocations`字段，而该字段中也包含多个字段。如`placeholderUsed`指的是分配是否是取代占位符（placeholder）。如果为true，`requestTime`将代表的是占位符的创建时间，如果为false，则就是代表这个分配（allocation）被询问时的时间。`allocationTime`则为分配被创建的时间，`allocationDelay`，则为`allocationTime`和`requestTime `相差的时间。
+
+## 分区（Partitions）
+
+显示有关分区的一般信息和统计数据。
+
+**位置（URL）**：`/ws/v1/partitions`
+
+**方法（Method）**：`GET`
+
+**需求权限**：无
+
+### 成功时的响应
+
+**返回代码**：`200 OK`
+
+**示例**
+
+```json
+[
+ {
+ "clusterId": "mycluster",
+ "name": "default",
+ "state": "Active",
+ "lastStateTransitionTime": 1649167576110754000,
+ "capacity": {
+ "capacity": {
+ "ephemeral-storage": 188176871424,
+ "hugepages-1Gi": 0,
+ "hugepages-2Mi": 0,
+ "memory": 1000000000,
+ "pods": 330,
+ "vcore": 1000
+ },
+ "usedCapacity": {
+ "memory": 800000000,
+ "vcore": 500
+ },
+ "utilization": {
+ "memory": 80,
+ "vcore": 50
+ }
+ },
+ "nodeSortingPolicy": {
+ "type": "fair",
+ "resourceWeights": {
+ "memory": 1.5,
+ "vcore": 1.3
+ }
+ },
+ "applications": {
+ "New": 5,
+ "Pending": 5,
+ "total": 10
+ },
+ "totalContainers": "0",
+ "totalNodes": "2"
+ },
+ {
+ "clusterId": "mycluster",
+ "name": "gpu",
+ "state": "Active",
+ "lastStateTransitionTime": 1649167576111236000,
+ "capacity": {
+ "capacity": {
+ "memory": 2000000000,
+ "vcore": 2000
+ },
+ "usedCapacity": {
+ "memory": 500000000,
+ "vcore": 300
+ },
+ "utilization": {
+ "memory": 25,
+ "vcore": 15
+ }
+ },
+ "nodeSortingPolicy": {
+ "type": "binpacking",
+ "resourceWeights": {
+ "memory": 0,
+ "vcore": 4.11
+ }
+ },
+ "applications": {
+ "New": 5,
+ "Running": 10,
+ "Pending": 5,
+ "total": 20
+ },
+ "totalContainers": "20",
+ "totalNodes": "5"
+ }
+]
+```
+
+### 错误时的响应
+
+**返回代码**：`500 Internal Server Error`
+
+**示例**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## 队列（Queues）
+
+### 分区队列
+
+获取给定分区中的队列，及队列相关的信息，其中包含名称、状态、容量和属性。
+队列层次结构（hierarchy）被保留在响应的json档中。
+
+**位置（URL）**：`/ws/v1/partition/{partitionName}/queues`
+
+**方法（Method）**：`GET`
+
+**需求权限**：无
+
+### 成功时的响应
+
+**返回代码**：`200 OK`
+
+**示例**
+
+在预设的队列层次结构中（仅`root.default`），将会向客户端发送与以下相似的响应。
+
+```json
+[
+ {
+ "queuename": "root",
+ "status": "Active",
+ "maxResource": {
+ "ephemeral-storage": 188176871424,
+ "hugepages-1Gi": 0,
+ "hugepages-2Mi": 0,
+ "memory": 8000000000,
+ "pods": 330,
+ "vcore": 8000
+ },
+ "guaranteedResource": {
+ "memory": 54000000,
+ "vcore": 80
+ },
+ "allocatedResource": {
+ "memory": 54000000,
+ "vcore": 80
+ },
+ "isLeaf": "false",
+ "isManaged": "false",
+ "properties": {
+ "application.sort.policy": "stateaware"
+ },
+ "parent": "",
+ "template": {
+ "maxResource": {
+ "memory": 8000000000,
+ "vcore": 8000
+ },
+ "guaranteedResource": {
+ "memory": 54000000,
+ "vcore": 80
+ },
+ "properties": {
+ "application.sort.policy": "stateaware"
+ }
+ },
+ "partition": "default",
+ "children": [
+ {
+ "queuename": "root.default",
+ "status": "Active",
+ "maxResource": {
+ "memory": 8000000000,
+ "vcore": 8000
+ },
+ "guaranteedResource": {
+ "memory": 54000000,
+ "vcore": 80
+ },
+ "allocatedResource": {
+ "memory": 54000000,
+ "vcore": 80
+ },
+ "isLeaf": "true",
+ "isManaged": "false",
+ "properties": {
+ "application.sort.policy": "stateaware"
+ },
+ "parent": "root",
+ "template": null,
+ "children": [],
+ "absUsedCapacity": {
+ "memory": 1,
+ "vcore": 0
+ },
+ "maxRunningApps": 12,
+ "runningApps": 4,
+ "allocatingAcceptedApps": [
+ "app-1",
+ "app-2"
+ ]
+ }
+ ],
+ "absUsedCapacity": {
+ "memory": 1,
+ "vcore": 0
+ }
+ }
+]
+```
+
+### 错误时的响应
+
+**返回代码**：`500 Internal Server Error`
+
+**示例**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## 多个应用程序
+
+### 队列中多个应用程序
+
+获取给定分区/队列组合的所有应用程序，并显示有关应用程序的信息，如使用的资源、队列名称、提交时间和分配。
+
+**位置（URL）**：`/ws/v1/partition/{partitionName}/queue/{queueName}/applications`
+
+**方法（Method）**：`GET`
+
+**需求权限**：无
+
+### 成功时的响应
+
+**返回代码**：`200 OK`
+
+**示例**
+
+在下面的示例中，有三个分配属于两个应用程序，其中一个具有挂起（Pending）的请求。
+
+```json
+[
+ {
+ "applicationID": "application-0001",
+ "usedResource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "maxUsedResource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "partition": "default",
+ "queueName": "root.default",
+ "submissionTime": 1648754032076020293,
+ "requests": [
+ {
+ "allocationKey": "f137fab6-3cfa-4536-93f7-bfff92689382",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0001",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task2"
+ },
+ "requestTime": 16487540320812345678,
+ "resource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "pendingCount": 1,
+ "priority": "0",
+ "requiredNodeId": "",
+ "applicationId": "application-0001",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderTimeout": 0,
+ "taskGroupName": "",
+ "allocationLog": [
+ {
+ "message": "node(s) didn't match Pod's node affinity, node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate",
+ "lastOccurrence": 16487540320812346001,
+ "count": 81
+ },
+ {
+ "message": "node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, node(s) didn't match Pod's node affinity",
+ "lastOccurrence": 16487540320812346002,
+ "count": 504
+ },
+ {
+ "message": "node(s) didn't match Pod's node affinity",
+ "lastOccurrence": 16487540320812346003,
+ "count": 1170
+ }
+ ]
+ }
+ ],
+ "allocations": [
+ {
+ "allocationKey": "deb12221-6b56-4fe9-87db-ebfadce9aa20",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0001",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task0"
+ },
+ "requestTime": 1648754034098912461,
+ "allocationTime": 1648754035973982920,
+ "allocationDelay": 1875070459,
+ "uuid": "9af35d44-2d6f-40d1-b51d-758859e6b8a8",
+ "resource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "priority": "0",
+ "nodeId": "node-0001",
+ "applicationId": "application-0001",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderUsed": true
+ }
+ ],
+ "applicationState": "Running",
+ "user": "system:serviceaccount:kube-system:deployment-controller",
+ "groups": [
+ "system:serviceaccounts",
+ "system:serviceaccounts:kube-system",
+ "system:authenticated"
+ ],
+ "rejectedMessage": "",
+ "stateLog": [
+ {
+ "time": 1648741409145224000,
+ "applicationState": "Accepted"
+ },
+ {
+ "time": 1648741409145509400,
+ "applicationState": "Starting"
+ },
+ {
+ "time": 1648741409147432100,
+ "applicationState": "Running"
+ }
+ ],
+ "placeholderData": [
+ {
+ "taskGroupName": "task-group-example",
+ "count": 2,
+ "minResource": {
+ "memory": 1000000000,
+ "vcore": 100
+ },
+ "replaced": 1,
+ "timedout": 1
+ }
+ ]
+ },
+ {
+ "applicationID": "application-0002",
+ "usedResource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "maxUsedResource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "partition": "default",
+ "queueName": "root.default",
+ "submissionTime": 1648754032076020293,
+ "requests": [],
+ "allocations": [
+ {
+ "allocationKey": "54e5d77b-f4c3-4607-8038-03c9499dd99d",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0002",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task0"
+ },
+ "requestTime": 1648754034098912461,
+ "allocationTime": 1648754035973982920,
+ "allocationDelay": 1875070459,
+ "uuid": "08033f9a-4699-403c-9204-6333856b41bd",
+ "resource": {
+ "memory": 2000000000,
+ "vcore": 2000
+ },
+ "priority": "0",
+ "nodeId": "node-0001",
+ "applicationId": "application-0002",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderUsed": false
+ },
+ {
+ "allocationKey": "af3bd2f3-31c5-42dd-8f3f-c2298ebdec81",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0002",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task1"
+ },
+ "requestTime": 1648754034098912461,
+ "allocationTime": 1648754035973982920,
+ "allocationDelay": 1875070459,
+ "uuid": "96beeb45-5ed2-4c19-9a83-2ac807637b3b",
+ "resource": {
+ "memory": 2000000000,
+ "vcore": 2000
+ },
+ "priority": "0",
+ "nodeId": "node-0002",
+ "applicationId": "application-0002",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderUsed": false
+ }
+ ],
+ "applicationState": "Running",
+ "user": "system:serviceaccount:kube-system:deployment-controller",
+ "groups": [
+ "system:serviceaccounts",
+ "system:serviceaccounts:kube-system",
+ "system:authenticated"
+ ],
+ "rejectedMessage": "",
+ "stateLog": [
+ {
+ "time": 1648741409145224000,
+ "applicationState": "Accepted"
+ },
+ {
+ "time": 1648741409145509400,
+ "applicationState": "Starting"
+ },
+ {
+ "time": 1648741409147432100,
+ "applicationState": "Running"
+ }
+ ],
+ "placeholderData": []
+ }
+]
+```
+
+### 错误时的响应
+
+**返回代码**：`500 Internal Server Error`
+
+**示例**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## 单一应用程序
+
+### 队列中单一应用程序
+
+从给定分区、队列和应用程序ID来获取应用程序，并显示有关应用程序的信息，如使用的资源、队列名称、提交时间和分配。
+
+**位置（URL）**：`/ws/v1/partition/{partitionName}/queue/{queueName}/application/{appId}`
+
+**方法（Method）**：`GET`
+
+**需求权限**：无
+
+### 成功时的响应
+
+**返回代码**：`200 OK`
+
+**示例**
+
+```json
+{
+ "applicationID": "application-0001",
+ "usedResource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "maxUsedResource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "partition": "default",
+ "queueName": "root.default",
+ "submissionTime": 1648754032076020293,
+ "requests": [
+ {
+ "allocationKey": "f137fab6-3cfa-4536-93f7-bfff92689382",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0001",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task2"
+ },
+ "requestTime": 16487540320812345678,
+ "resource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "pendingCount": 1,
+ "priority": "0",
+ "requiredNodeId": "",
+ "applicationId": "application-0001",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderTimeout": 0,
+ "taskGroupName": "",
+ "allocationLog": [
+ {
+ "message": "node(s) didn't match Pod's node affinity, node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate",
+ "lastOccurrence": 16487540320812346001,
+ "count": 81
+ },
+ {
+ "message": "node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, node(s) didn't match Pod's node affinity",
+ "lastOccurrence": 16487540320812346002,
+ "count": 504
+ },
+ {
+ "message": "node(s) didn't match Pod's node affinity",
+ "lastOccurrence": 16487540320812346003,
+ "count": 1170
+ }
+ ]
+ }
+ ],
+ "allocations": [
+ {
+ "allocationKey": "deb12221-6b56-4fe9-87db-ebfadce9aa20",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0001",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task0"
+ },
+ "requestTime": 1648754034098912461,
+ "allocationTime": 1648754035973982920,
+ "allocationDelay": 1875070459,
+ "uuid": "9af35d44-2d6f-40d1-b51d-758859e6b8a8",
+ "resource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "priority": "0",
+ "nodeId": "node-0001",
+ "applicationId": "application-0001",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderUsed": true
+ }
+ ],
+ "applicationState": "Running",
+ "user": "system:serviceaccount:kube-system:deployment-controller",
+ "groups": [
+ "system:serviceaccounts",
+ "system:serviceaccounts:kube-system",
+ "system:authenticated"
+ ],
+ "rejectedMessage": "",
+ "stateLog": [
+ {
+ "time": 1648741409145224000,
+ "applicationState": "Accepted"
+ },
+ {
+ "time": 1648741409145509400,
+ "applicationState": "Starting"
+ },
+ {
+ "time": 1648741409147432100,
+ "applicationState": "Running"
+ }
+ ],
+ "placeholderData": [
+ {
+ "taskGroupName": "task-group-example",
+ "count": 2,
+ "minResource": {
+ "memory": 1000000000,
+ "vcore": 100
+ },
+ "replaced": 1,
+ "timedout": 1
+ }
+ ]
+}
+```
+
+### 错误时的响应
+
+**返回代码**：`500 Internal Server Error`
+
+**示例**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## 多个节点
+
+### 分区中多个节点
+
+获取给定分区的所有节点，并显示由YuniKorn管理的节点的信息。
+节点详细信息包括主机和机架名称、容量、资源、利用率和分配。
+
+**位置（URL）**：`/ws/v1/partition/{partitionName}/nodes`
+
+**方法（Method）**：`GET`
+
+**需求权限**：无
+
+### 成功时的响应
+
+**返回代码**：`200 OK`
+
+**示例**
+
+这个示例的响应，来自一个群集，其中包含2个节点和3个分配。
+
+```json
+[
+ {
+ "nodeID": "node-0001",
+ "hostName": "",
+ "rackName": "",
+ "capacity": {
+ "ephemeral-storage": 75850798569,
+ "hugepages-1Gi": 0,
+ "hugepages-2Mi": 0,
+ "memory": 14577000000,
+ "pods": 110,
+ "vcore": 10000
+ },
+ "allocated": {
+ "memory": 6000000000,
+ "vcore": 6000
+ },
+ "occupied": {
+ "memory": 154000000,
+ "vcore" :750
+ },
+ "available": {
+ "ephemeral-storage": 75850798569,
+ "hugepages-1Gi": 0,
+ "hugepages-2Mi": 0,
+ "memory": 6423000000,
+ "pods": 110,
+ "vcore": 1250
+ },
+ "utilized": {
+ "memory": 3,
+ "vcore": 13
+ },
+ "allocations": [
+ {
+ "allocationKey": "54e5d77b-f4c3-4607-8038-03c9499dd99d",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0001",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task0"
+ },
+ "requestTime": 1648754034098912461,
+ "allocationTime": 1648754035973982920,
+ "allocationDelay": 1875070459,
+ "uuid": "08033f9a-4699-403c-9204-6333856b41bd",
+ "resource": {
+ "memory": 2000000000,
+ "vcore": 2000
+ },
+ "priority": "0",
+ "nodeId": "node-0001",
+ "applicationId": "application-0001",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderUsed": false
+ },
+ {
+ "allocationKey": "deb12221-6b56-4fe9-87db-ebfadce9aa20",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0002",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task0"
+ },
+ "requestTime": 1648754034098912461,
+ "allocationTime": 1648754035973982920,
+ "allocationDelay": 1875070459,
+ "uuid": "9af35d44-2d6f-40d1-b51d-758859e6b8a8",
+ "resource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "priority": "0",
+ "nodeId": "node-0001",
+ "applicationId": "application-0002",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderUsed": false
+ }
+ ],
+ "schedulable": true
+ },
+ {
+ "nodeID": "node-0002",
+ "hostName": "",
+ "rackName": "",
+ "capacity": {
+ "ephemeral-storage": 75850798569,
+ "hugepages-1Gi": 0,
+ "hugepages-2Mi": 0,
+ "memory": 14577000000,
+ "pods": 110,
+ "vcore": 10000
+ },
+ "allocated": {
+ "memory": 2000000000,
+ "vcore": 2000
+ },
+ "occupied": {
+ "memory": 154000000,
+ "vcore" :750
+ },
+ "available": {
+ "ephemeral-storage": 75850798569,
+ "hugepages-1Gi": 0,
+ "hugepages-2Mi": 0,
+ "memory": 6423000000,
+ "pods": 110,
+ "vcore": 1250
+ },
+ "utilized": {
+ "memory": 8,
+ "vcore": 38
+ },
+ "allocations": [
+ {
+ "allocationKey": "af3bd2f3-31c5-42dd-8f3f-c2298ebdec81",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0001",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task1"
+ },
+ "requestTime": 1648754034098912461,
+ "allocationTime": 1648754035973982920,
+ "allocationDelay": 1875070459,
+ "uuid": "96beeb45-5ed2-4c19-9a83-2ac807637b3b",
+ "resource": {
+ "memory": 2000000000,
+ "vcore": 2000
+ },
+ "priority": "0",
+ "nodeId": "node-0002",
+ "applicationId": "application-0001",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderUsed": false
+ }
+ ],
+ "schedulable": true
+ }
+]
+```
+
+### 错误时的响应
+
+**返回代码**：`500 Internal Server Error`
+
+**示例**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## 单一节点
+
+### 分区中单一节点
+
+从给定分区和节点ID来获取节点，并显示有关节点的信息，节点详细信息包括主机和机架名称、容量、资源、利用率和分配。
+
+**位置（URL）** : `/ws/v1/partition/{partitionName}/node/{nodeId}`
+
+**方法（Method）** : `GET`
+
+**需求权限** : NO
+
+### 成功时的响应
+
+**返回代码** : `200 OK`
+
+**示例**
+
+```json
+{
+ "nodeID":"node-0001",
+ "hostName":"",
+ "rackName":"",
+ "capacity":{
+ "ephemeral-storage":75850798569,
+ "hugepages-1Gi":0,
+ "hugepages-2Mi":0,
+ "memory":14577000000,
+ "pods":110,
+ "vcore":10000
+ },
+ "allocated":{
+ "memory":6000000000,
+ "vcore":6000
+ },
+ "occupied":{
+ "memory":154000000,
+ "vcore":750
+ },
+ "available":{
+ "ephemeral-storage":75850798569,
+ "hugepages-1Gi":0,
+ "hugepages-2Mi":0,
+ "memory":6423000000,
+ "pods":110,
+ "vcore":1250
+ },
+ "utilized":{
+ "memory":3,
+ "vcore":13
+ },
+ "allocations":[
+ {
+ "allocationKey":"54e5d77b-f4c3-4607-8038-03c9499dd99d",
+ "allocationTags":{
+ "kubernetes.io/label/app":"sleep",
+ "kubernetes.io/label/applicationId":"application-0001",
+ "kubernetes.io/label/queue":"root.default",
+ "kubernetes.io/meta/namespace":"default",
+ "kubernetes.io/meta/podName":"task0"
+ },
+ "requestTime":1648754034098912461,
+ "allocationTime":1648754035973982920,
+ "allocationDelay":1875070459,
+ "uuid":"08033f9a-4699-403c-9204-6333856b41bd",
+ "resource":{
+ "memory":2000000000,
+ "vcore":2000
+ },
+ "priority":"0",
+ "nodeId":"node-0001",
+ "applicationId":"application-0001",
+ "partition":"default",
+ "placeholder":false,
+ "placeholderUsed":false
+ },
+ {
+ "allocationKey":"deb12221-6b56-4fe9-87db-ebfadce9aa20",
+ "allocationTags":{
+ "kubernetes.io/label/app":"sleep",
+ "kubernetes.io/label/applicationId":"application-0002",
+ "kubernetes.io/label/queue":"root.default",
+ "kubernetes.io/meta/namespace":"default",
+ "kubernetes.io/meta/podName":"task0"
+ },
+ "requestTime":1648754034098912461,
+ "allocationTime":1648754035973982920,
+ "allocationDelay":1875070459,
+ "uuid":"9af35d44-2d6f-40d1-b51d-758859e6b8a8",
+ "resource":{
+ "memory":4000000000,
+ "vcore":4000
+ },
+ "priority":"0",
+ "nodeId":"node-0001",
+ "applicationId":"application-0002",
+ "partition":"default",
+ "placeholder":false,
+ "placeholderUsed":false
+ }
+ ],
+ "schedulable":true
+}
+```
+
+### 错误时的响应
+
+**返回代码** : `500 Internal Server Error`
+
+**示例**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## Goroutines信息
+
+获取当前运行的goroutines的堆栈跟踪（stack traces）
+
+**位置（URL）**：`/ws/v1/stack`
+
+**方法（Method）**：`GET`
+
+**需求权限**：无
+
+### 成功时的响应
+
+**返回代码**：`200 OK`
+
+**示例**
+
+```text
+goroutine 356 [running
+]:
+github.com/apache/yunikorn-core/pkg/webservice.getStackInfo.func1(0x30a0060,
+0xc003e900e0,
+0x2)
+ /yunikorn/go/pkg/mod/github.com/apache/yunikorn-core@v0.0.0-20200717041747-f3e1c760c714/pkg/webservice/handlers.go: 41 +0xab
+github.com/apache/yunikorn-core/pkg/webservice.getStackInfo(0x30a0060,
+0xc003e900e0,
+0xc00029ba00)
+ /yunikorn/go/pkg/mod/github.com/apache/yunikorn-core@v0.0.0-20200717041747-f3e1c760c714/pkg/webservice/handlers.go: 48 +0x71
+net/http.HandlerFunc.ServeHTTP(0x2df0e10,
+0x30a0060,
+0xc003e900e0,
+0xc00029ba00)
+ /usr/local/go/src/net/http/server.go: 1995 +0x52
+github.com/apache/yunikorn-core/pkg/webservice.Logger.func1(0x30a0060,
+0xc003e900e0,
+0xc00029ba00)
+ /yunikorn/go/pkg/mod/github.com/apache/yunikorn-core@v0.0.0-20200717041747-f3e1c760c714/pkg/webservice/webservice.go: 65 +0xd4
+net/http.HandlerFunc.ServeHTTP(0xc00003a570,
+0x30a0060,
+0xc003e900e0,
+0xc00029ba00)
+ /usr/local/go/src/net/http/server.go: 1995 +0x52
+github.com/gorilla/mux.(*Router).ServeHTTP(0xc00029cb40,
+0x30a0060,
+0xc003e900e0,
+0xc0063fee00)
+ /yunikorn/go/pkg/mod/github.com/gorilla/mux@v1.7.3/mux.go: 212 +0x140
+net/http.serverHandler.ServeHTTP(0xc0000df520,
+0x30a0060,
+0xc003e900e0,
+0xc0063fee00)
+ /usr/local/go/src/net/http/server.go: 2774 +0xcf
+net/http.(*conn).serve(0xc0000eab40,
+0x30a61a0,
+0xc003b74000)
+ /usr/local/go/src/net/http/server.go: 1878 +0x812
+created by net/http.(*Server).Serve
+ /usr/local/go/src/net/http/server.go: 2884 +0x4c5
+
+goroutine 1 [chan receive,
+ 26 minutes
+]:
+main.main()
+ /yunikorn/pkg/shim/main.go: 52 +0x67a
+
+goroutine 19 [syscall,
+ 26 minutes
+]:
+os/signal.signal_recv(0x1096f91)
+ /usr/local/go/src/runtime/sigqueue.go: 139 +0x9f
+os/signal.loop()
+ /usr/local/go/src/os/signal/signal_unix.go: 23 +0x30
+created by os/signal.init.0
+ /usr/local/go/src/os/signal/signal_unix.go: 29 +0x4f
+
+...
+```
+
+### 错误时的响应
+
+**返回代码** : `500 Internal Server Error`
+
+**示例**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## 指标(Metrics)
+
+从Prometheus服务器检索指标的端点。
+指标中包含帮助消息和类型信息(type information)。
+
+**位置(URL)** : `/ws/v1/metrics`
+
+**方法(Method)** : `GET`
+
+**需求权限**：无
+
+### 成功时的响应
+
+**返回代码** : `200 OK`
+
+**示例**
+
+```text
+# HELP go_gc_duration_seconds 作为垃圾收集周期的暂停期间的摘要。
+# TYPE go_gc_duration_seconds summary
+go_gc_duration_seconds{quantile="0"} 2.567e-05
+go_gc_duration_seconds{quantile="0.25"} 3.5727e-05
+go_gc_duration_seconds{quantile="0.5"} 4.5144e-05
+go_gc_duration_seconds{quantile="0.75"} 6.0024e-05
+go_gc_duration_seconds{quantile="1"} 0.00022528
+go_gc_duration_seconds_sum 0.021561648
+go_gc_duration_seconds_count 436
+# HELP go_goroutines 当前存在的goroutines数量。
+# TYPE go_goroutines gauge
+go_goroutines 82
+# HELP go_info 关于Golang环境的信息。
+# TYPE go_info gauge
+go_info{version="go1.12.17"} 1
+# HELP go_memstats_alloc_bytes 已经被分配且正在使用的记忆体位元（bytes）数。
+# TYPE go_memstats_alloc_bytes gauge
+go_memstats_alloc_bytes 9.6866248e+07
+
+...
+
+# HELP yunikorn_scheduler_vcore_nodes_usage 节点的CPU使用量
+# TYPE yunikorn_scheduler_vcore_nodes_usage gauge
+yunikorn_scheduler_vcore_nodes_usage{range="(10%, 20%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="(20%,30%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="(30%,40%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="(40%,50%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="(50%,60%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="(60%,70%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="(70%,80%]"} 1
+yunikorn_scheduler_vcore_nodes_usage{range="(80%,90%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="(90%,100%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="[0,10%]"} 0
+```
+
+## 配置验证
+
+**位置(URL)** : `/ws/v1/validate-conf`
+
+**方法(Method)** : `POST`
+
+**需求权限**：无
+
+### 成功时的响应
+
+无论配置是否被允许，如果服务器能够处理请求，它都将生成一个200HTTP状态代码。
+
+**返回代码** : `200 OK`
+
+#### 允许的配置
+
+发送以下简单配置会被接受
+
+```yaml
+partitions:
+ - name: default
+ queues:
+ - name: root
+ queues:
+ - name: test
+```
+
+返回
+
+```json
+{
+ "allowed": true,
+ "reason": ""
+}
+```
+
+#### 不允许的配置
+
+由于以下的的yaml档案中包含了“wrong_text”字段，因此是不允许的配置。
+
+```yaml
+partitions:
+ - name: default
+ queues:
+ - name: root
+ queues:
+ - name: test
+ - wrong_text
+```
+
+返回
+
+```json
+{
+ "allowed": false,
+ "reason": "yaml: unmarshal errors:\n line 7: cannot unmarshal !!str `wrong_text` into configs.PartitionConfig"
+}
+```
+
+## 配置
+
+检索当前调度器配置的端点
+
+**位置(URL)** : `/ws/v1/config`
+
+**方法(Method)** : `GET`
+
+**需求权限**：无
+
+### 成功时的响应
+
+**返回代码** : `200 OK`
+
+**示例**
+
+```yaml
+partitions:
+- name: default
+ queues:
+ - name: root
+ parent: true
+ submitacl: '*'
+ placementrules:
+ - name: tag
+ create: true
+ value: namespace
+checksum: D75996C07D5167F41B33E27CCFAEF1D5C55BE3C00EE6526A7ABDF8435DB4078E
+```
+
+## 应用程序历史
+
+检索历史数据的端点，依据时间来条列应用程序的总数。
+
+**位置(URL)** : `/ws/v1/history/apps`
+
+**方法(Method)** : `GET`
+
+**需求权限**：无
+
+### 成功时的响应
+
+**返回代码** : `200 OK`
+
+**示例**
+
+```json
+[
+ {
+ "timestamp": 1595939966153460000,
+ "totalApplications": "1"
+ },
+ {
+ "timestamp": 1595940026152892000,
+ "totalApplications": "1"
+ },
+ {
+ "timestamp": 1595940086153799000,
+ "totalApplications": "2"
+ },
+ {
+ "timestamp": 1595940146154497000,
+ "totalApplications": "2"
+ },
+ {
+ "timestamp": 1595940206155187000,
+ "totalApplications": "2"
+ }
+]
+```
+
+### 错误时的响应
+
+**返回代码** : `500 Internal Server Error`
+
+**示例**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## 容器历史
+
+检索历史数据的端点，依据时间来条列容器的总数。
+
+**位置(URL)** : `/ws/v1/history/containers`
+
+**方法(Method)** : `GET`
+
+**需求权限**：无
+
+### 成功时的响应
+
+**返回代码** : `200 OK`
+
+**示例**
+
+```json
+[
+ {
+ "timestamp": 1595939966153460000,
+ "totalContainers": "1"
+ },
+ {
+ "timestamp": 1595940026152892000,
+ "totalContainers": "1"
+ },
+ {
+ "timestamp": 1595940086153799000,
+ "totalContainers": "3"
+ },
+ {
+ "timestamp": 1595940146154497000,
+ "totalContainers": "3"
+ },
+ {
+ "timestamp": 1595940206155187000,
+ "totalContainers": "3"
+ }
+]
+```
+
+### 错误时的响应
+
+**返回代码** : `500 Internal Server Error`
+
+**示例**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+
+## 健康检查的端点
+
+用来检索历史数据的端点，其中包含关键日志，以及节点、集群、应用程序中资源量为负的资源。
+
+**位置(URL)** : `/ws/v1/scheduler/healthcheck`
+
+**方法(Method)** : `GET`
+
+**需求权限**：无
+
+### 成功时的响应
+
+**返回代码** : `200 OK`
+
+**示例**
+
+```json
+{
+ "Healthy": true,
+ "HealthChecks": [
+ {
+ "Name": "Scheduling errors",
+ "Succeeded": true,
+ "Description": "Check for scheduling error entries in metrics",
+ "DiagnosisMessage": "There were 0 scheduling errors logged in the metrics"
+ },
+ {
+ "Name": "Failed nodes",
+ "Succeeded": true,
+ "Description": "Check for failed nodes entries in metrics",
+ "DiagnosisMessage": "There were 0 failed nodes logged in the metrics"
+ },
+ {
+ "Name": "Negative resources",
+ "Succeeded": true,
+ "Description": "Check for negative resources in the partitions",
+ "DiagnosisMessage": "Partitions with negative resources: []"
+ },
+ {
+ "Name": "Negative resources",
+ "Succeeded": true,
+ "Description": "Check for negative resources in the nodes",
+ "DiagnosisMessage": "Nodes with negative resources: []"
+ },
+ {
+ "Name": "Consistency of data",
+ "Succeeded": true,
+ "Description": "Check if a node's allocated resource <= total resource of the node",
+ "DiagnosisMessage": "Nodes with inconsistent data: []"
+ },
+ {
+ "Name": "Consistency of data",
+ "Succeeded": true,
+ "Description": "Check if total partition resource == sum of the node resources from the partition",
+ "DiagnosisMessage": "Partitions with inconsistent data: []"
+ },
+ {
+ "Name": "Consistency of data",
+ "Succeeded": true,
+ "Description": "Check if node total resource = allocated resource + occupied resource + available resource",
+ "DiagnosisMessage": "Nodes with inconsistent data: []"
+ },
+ {
+ "Name": "Consistency of data",
+ "Succeeded": true,
+ "Description": "Check if node capacity >= allocated resources on the node",
+ "DiagnosisMessage": "Nodes with inconsistent data: []"
+ },
+ {
+ "Name": "Reservation check",
+ "Succeeded": true,
+ "Description": "Check the reservation nr compared to the number of nodes",
+ "DiagnosisMessage": "Reservation/node nr ratio: [0.000000]"
+ }
+ ]
+}
+```
+
+## 检索所有状态
+
+能在单一响应包含以下的信息：
+
+* 分区清单
+* 应用程序清单（`运行中` 和 `已完成`）
+* 应用程序历史
+* 节点
+* 节点的使用率
+* 集群的基本信息
+* 集群的使用率
+* 容器的历史
+* 队列
+* RM 诊断
+
+**位置(URL)** : `/ws/v1/fullstatedump`
+
+**方法(Method)** : `GET`
+
+**需求权限**：无
+
+### 成功时的响应
+
+**返回代码** : `200 OK`
+
+**示例**
+
+该REST请求的输出将会很巨大，且为前面演示过的输出的组合。
+
+RM 诊断显示 K8Shim 缓存的内容。确切内容取决于版本并且尚未稳定。
+当前内容显示缓存的对象：
+* 节点
+* pods
+* 优先等级
+* 调度状态（pod状态）
+
+### 错误时的响应
+
+**代码**：`500 Internal Server Error`
+
+## 启用或禁用定期写入状态信息
+
+为允许状态周期性地写入的端点。
+
+**状态**：自v1.2.0以来已弃用并被忽略，无替代品。
+
+**位置(URL)** : `/ws/v1/periodicstatedump/{switch}/{periodSeconds}`
+
+**方法(Method)** : `PUT`
+
+**需求权限**：无
+
+### 成功时的响应
+
+无
+
+### 错误时的响应
+
+**代码**: `400 Bad Request`
+
+## 获取日志级别
+接收当前Yunikorn的日志级别。
+
+**URL** : `/ws/v1/loglevel`
+
+**方法** : `GET`
+
+**需求权限** : 无
+
+### 成功时的响应
+
+**代码**: `200 OK`
+
+**示例**
+
+```
+info%
+```
+
+## 设置日志级别
+设置Yunikorn日志级别。
+
+**URL** : `/ws/v1/loglevel/{level}`
+
+**方法** : `PUT`
+
+**需求权限** : NO
+
+### 成功时的响应
+
+**代码**: `200 OK`
+
+### 错误时的响应
+
+**代码**: `400 Bad Request`
+
+**示例**
+
+```json
+{
+ "status_code":400,
+ "message":"failed to change log level, old level active",
+ "description":"failed to change log level, old level active"
+}
+```
+
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/api/system.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/api/system.md
new file mode 100644
index 0000000000..83337cf4bc
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/api/system.md
@@ -0,0 +1,225 @@
+---
+id: system
+title: 系統
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+这些端点是用于提供資訊給[pprof](https://github.com/google/pprof)分析工具。
+
+## pprof
+
+**位置(URL)** : `/debug/pprof/`
+
+**方法(Method)** : `GET`
+
+### 成功时的响应
+
+**回传代码** : `200 OK`
+
+**示例**
+
+```text
+/debug/pprof/
+
+Types of profiles available:
+Count Profile
+273 allocs
+0 block
+0 cmdline
+78 goroutine
+273 heap
+0 mutex
+0 profile
+29 threadcreate
+0 trace
+full goroutine stack dump
+Profile Descriptions:
+
+allocs: A sampling of all past memory allocations
+block: Stack traces that led to blocking on synchronization primitives
+cmdline: The command line invocation of the current program
+goroutine: Stack traces of all current goroutines
+heap: A sampling of memory allocations of live objects. You can specify the gc GET parameter to run GC before taking the heap sample.
+mutex: Stack traces of holders of contended mutexes
+profile: CPU profile. You can specify the duration in the seconds GET parameter. After you get the profile file, use the go tool pprof command to investigate the profile.
+threadcreate: Stack traces that led to the creation of new OS threads
+trace: A trace of execution of the current program. You can specify the duration in the seconds GET parameter. After you get the trace file, use the go tool trace command to investigate the trace.
+```
+
+## 堆 (Heap)
+
+**位置(URL)** : `/debug/pprof/heap`
+
+**方法(Method)** : `GET`
+
+### 成功时的响应
+
+**回传代码** : `200 OK`
+
+**示例**
+
+```proto
+// 来自proto的二进制数据
+```
+
+## 线程创建
+
+**位置(URL)** : `/debug/pprof/threadcreate`
+
+**方法(Method)** : `GET`
+
+### 成功时的响应
+
+**回传代码** : `200 OK`
+
+**示例**
+
+```proto
+// 来自proto的二进制数据
+```
+
+## Goroutine
+
+**位置(URL)** : `/debug/pprof/goroutine`
+
+**方法(Method)** : `GET`
+
+### 成功时的响应
+
+**回传代码** : `200 OK`
+
+**示例**
+
+```proto
+// 来自proto的二进制数据
+```
+
+## 分配 (Allocations)
+
+**位置(URL)** : `/debug/pprof/allocs`
+
+**方法(Method)** : `GET`
+
+### 成功时的响应
+
+**回传代码** : `200 OK`
+
+**示例**
+
+```proto
+// 来自proto的二进制数据
+```
+
+## 阻塞分析 (Block)
+
+**位置(URL)** : `/debug/pprof/block`
+
+**方法(Method)** : `GET`
+
+### 成功时的响应
+
+**回传代码** : `200 OK`
+
+**示例**
+
+```proto
+// 来自proto的二进制数据
+```
+
+## 互斥锁分析 (Mutex)
+
+**位置(URL)** : `/debug/pprof/mutex`
+
+**方法(Method)** : `GET`
+
+### 成功时的响应
+
+**回传代码** : `200 OK`
+
+**示例**
+
+```proto
+// 来自proto的二进制数据
+```
+
+## 命令行参数 (Cmdline)
+
+**位置(URL)** : `/debug/pprof/cmdline`
+
+**方法(Method)** : `GET`
+
+### 成功时的响应
+
+**回传代码** : `200 OK`
+
+**示例**
+
+```proto
+// 来自proto的二进制数据
+```
+
+## 简介
+
+**位置(URL)** : `/debug/pprof/profile`
+
+**方法(Method)** : `GET`
+
+### 成功时的响应
+
+**回传代码** : `200 OK`
+
+**示例**
+
+```proto
+// 来自proto的二进制数据
+```
+
+## Symbol
+
+**位置(URL)** : `/debug/pprof/symbol`
+
+**方法(Method)** : `GET`
+
+### 成功时的响应
+
+**回传代码** : `200 OK`
+
+**示例**
+
+```proto
+// 来自proto的二进制数据
+```
+
+## 跟踪(Trace)
+
+**位置(URL)** : `/debug/pprof/trace`
+
+**方法(Method)** : `GET`
+
+### 成功时的响应
+
+**回传代码** : `200 OK`
+
+**示例**
+
+```proto
+// 来自proto的二进制数据
+```
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/assets b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/assets
new file mode 120000
index 0000000000..778d0f8e47
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/assets
@@ -0,0 +1 @@
+../../../../docs/assets
\ No newline at end of file
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/developer_guide/env_setup.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/developer_guide/env_setup.md
new file mode 100644
index 0000000000..9a1f7d2eea
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/developer_guide/env_setup.md
@@ -0,0 +1,192 @@
+---
+id: env_setup
+title: 开发环境的设置
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+有很多种方法可以在本地设置Kubernetes开发环境，其中最常见的三种方法是`Minikube`([docs](https://kubernetes.io/docs/setup/minikube/))、`docker-desktop`和`kind`([kind](https://kind.sigs.k8s.io/)
+`Minikube`通过数个虚拟机提供一个本地Kubernetes集群（通过VirtualBox或类似的东西）。`docker-desktop`能在docker容器中设置Kubernetes集群。 `kind`为Windows、Linux和Mac提供轻量级的Kubernetes集群。
+
+## 使用Docker Desktop设置本地的Kubernetes集群
+
+在本教程中，我们将基于Docker Desktop进行所有的安装。
+我们也可以使用轻量级的[minikube](#使用minikube设置本地的kubernetes集群)设置，它可以提供同样的功能，且需要的资源较小。
+
+### 安装
+
+在你的笔记本电脑上下载并安装[Docker-Desktop](https://www.docker.com/products/docker-desktop)。其中，最新版本包含了Kubernetes，所以不需要额外安装。
+只需按照[这里](https://docs.docker.com/docker-for-mac/#kubernetes)的步骤，就可以在docker-desktop中启动和运行Kubernetes。
+
+一旦Kubernetes在docker桌面中启动，你应该看到类似以下的画面：
+
+
+
+这意味着：
+1. Kubernetes正在运行。
+2. 命令行工具`kubctl`安装在`/usr/local/bin`目录下。
+3. Kubernetes的被设置到`docker-desktop`中。
+
+### 部署和访问仪表板
+
+设置好本地Kubernetes后，你需要使用以下步骤部署仪表盘：
+1. 按照[Kubernetes dashboard doc](https://github.com/kubernetes/dashboard)中的说明来部署仪表盘。
+2. 从终端启动Kubernetes代理，让我们能存取本地主机上的仪表板：
+ ```shell script
+ kubectl proxy &
+ ```
+3. 通过以下网址访问仪表板： [链接](http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/#!/login)
+
+### 访问本地Kubernetes集群
+
+上一步部署的仪表板需要一个令牌或配置来登录。这里我们使用令牌来登录。该令牌是自动生成的，可以从系统中检索到。
+
+1. 检索仪表板令牌的名称：
+ ```shell script
+ kubectl -n kube-system get secret | grep kubernetes-dashboard-token
+ ```
+2. 检索令牌的内容，注意令牌名称以随机的5个字符代码结尾，需要用步骤1的结果替换。例如：
+ ```shell script
+ kubectl -n kube-system describe secret kubernetes-dashboard-token-tf6n8
+ ```
+3. 複製`Data`中标签为 `token`的值。
+4. 在用户介面仪表板中选择 **Token**：<br/>
+ 
+5. 在输入框中粘贴`token`的值，然后登录：<br/>
+ 
+
+## 使用Minikube设置本地的Kubernetes集群
+
+Minikube 可以被添加到现有的 Docker Desktop 中。Minikube 既可以使用预装的虚拟机管理程序(hypervisor)，也可以自己选择。预设是由[HyperKit](https://github.com/moby/hyperkit)所提供的虚拟化，它已被嵌入到 Docker Desktop 中。
+
+如果你不想使用 HyperKit 的虚拟机管理程序，请确保你遵循通用的minikube安装说明。如果需要的话，不要忘记为所选择的虚拟机管理程序安装正确的驱动程序。
+基本说明在[minikube install](https://kubernetes.io/docs/tasks/tools/install-minikube/)中提供。
+
+如果要检查 Docker Desktop 是否安装了 HyperKit。在终端上运行： `hyperkit`来确认。除了 `hyperkit: command not found` 以外的任何响应都证实了 HyperKit 已经安装并且在路径上。如果没有找到，你可以选择一个不同的虚拟机管理程序或修复Docker Desktop。
+
+### 安装 Minikube
+1. 你可以使用 brew 或是以下的步骤来安装 minikube：
+ ```shell script
+ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64
+ chmod +x minikube
+ sudo mv minikube /usr/local/bin
+ ```
+2. 你可以使用 brew 或是以下的步骤来安装 HyperKit 的驱动程序(必要)：
+ ```shell script
+ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit
+ sudo install -o root -g wheel -m 4755 docker-machine-driver-hyperkit /usr/local/bin/
+ ```
+3. 更新 minikube 配置，使其默认虚拟机管理程序为HyperKit：`minikube config set vm-driver hyperkit`。
+4. 修改 docker desktop 以使用 Kubernetes 的 minikube：<br/>
+ 
+
+### 部署和访问集群
+安装完成后，你可以开始启动一个新的集群。
+1. 启动 minikube 集群： `minikube start --kubernetes-version v1.24.7`
+2. 启动 minikube 仪表板： `minikube dashboard &`
+
+### 开发环境对构建的影响
+在创建映像之前，确保你的 minikube 运行在正确的环境中。
+如果没有设定 minikube 环境，就会在部署调度器的时候找不到docker映像。
+1. 确保 minikube 已启动。
+2. 在你要运行构建的终端中，执行： `eval $(minikube docker-env)`
+3. 在 yunikorn-k8shim 的根目录创建映像： `make image`
+4. 按照正常指令部署调度器。
+
+## 使用 Kind 的设置本地的 Kubernetes 集群
+
+Kind（Kubernetes in Docker）是一个轻量级的工具，主要用来运行轻量级Kubernetes环境。 用kind测试不同的Kubernetes版本是非常容易的，只需选择你想要的映像。
+
+### 安装
+
+如果你已经安装过go，可以直接运行`go install sigs.k8s.io/kind@latest`。
+
+可在[Kind](https://kind.sigs.k8s.io/docs/user/quick-start/#installation)的文件上找到其他方法。
+
+要在Kubernetes 1.25中使用Kind，你需要使用kind@v0.15 或以上版本。 有些kind版本仅支持特定版本的Kubernetes，您可以从Kind发布的说明中获取该信息。
+
+### 使用 Kind
+
+若要要测试新版本的Kubernetes，你可以从kind的repo中拉出一个相应的映像。
+
+创建版本为 v1.24.7 的 Kubernetes 集群： `kind create cluster --name test --image kindest/node:v1.24.7`
+
+删除 kind 集群： `kind delete cluster --name test`
+
+### 载入你的映像
+
+为了使用本地镜像，你必须将你的映像加载到kind的注册表(registry)中。 如果你运行`make image`，你可以使用下面的命令来加载你的kind映像。 以下假设为AMD64架构。
+
+下面是调度器、网页UI和存取控制器的例子：
+
+调度器：
+`kind load docker-image apache/yunikorn:scheduler-amd64-latest`
+
+网页UI：
+`kind load docker-image apache/yunikorn:web-amd64-latest`
+
+存取控制器：
+`kind load docker-image apache/yunikorn:admission-amd64-latest`
+
+## 在本地调试代码
+
+注意，这个指令要求你在 GoLand IDE 进行开发。
+
+在GoLand中，进入yunikorn-k8shim项目。然后点击 "Run" -> "Debug..." -> "Edit Configuration..." 获取弹出的配置窗口。
+注意，如果第一次没有 "Go Build "选项，你需要点击 "+"来创建一个新的配置文件。
+
+
+
+强调的字段是你需要添加的配置。包括以下：
+
+- Run Kind： package
+- Package path： 指向 `pkg/shim` 的路径
+- Working directory： 指向`conf`目录的路径，这是程序加载配置文件的地方。
+- Program arguments： 指定运行程序的参数，如 `-kubeConfig=/path/to/.kube/config -interval=1s -clusterId=mycluster -clusterVersion=0.1 -name=yunikorn -policyGroup=queues -logEncoding=console -logLevel=-1`.
+注意，你需要把`/path/to/.kube/config`替换为kubeconfig文件的本地路径。如果你想改变或添加更多的选项，你可以运行`_output/bin/k8s-yunikorn-scheduler -h`来了解。
+
+修改完成后，点击 "Apply"，然后点击 "Debug"。你将需要设置适当的断点，以便调试程序。
+
+## 存取远端的 Kubernetes 集群
+
+这个设置的前提是你已经安装了一个远程Kubernetes集群。
+关于如何访问多个集群并将其整合，请参考Kubernetes的[访问多个集群](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)文档。
+
+或者按照这些简化的步骤：
+1. 从远程集群获取Kubernetes的`config`文件，将其复制到本地机器上，并给它一个唯一的名字，即`config-remote`。
+2. 更新 `KUBECONFIG` 环境变量（如果已设置）。
+ ```shell script
+ export KUBECONFIG_SAVED=$KUBECONFIG
+ ```
+3. 将新文件添加到环境变量中。
+ ```shell script
+ export KUBECONFIG=$KUBECONFIG:config-remote
+ ```
+4. 运行`kubectl config view`命令，检查是否可以访问这两个配置。
+5. 透过以下命令切换配置 `kubectl config use-context my-remote-cluster`
+6. 确认是否切换到了远程集群的配置：
+ ```text
+ kubectl config get-contexts
+ CURRENT NAME CLUSTER AUTHINFO NAMESPACE
+ docker-for-desktop docker-for-desktop-cluster docker-for-desktop
+ * my-remote-cluster kubernetes kubernetes-admin
+ ```
+
+更多的文件可以在[这里](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)找到。
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/developer_guide/translation.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/developer_guide/translation.md
new file mode 100644
index 0000000000..2e74494ed8
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/developer_guide/translation.md
@@ -0,0 +1,127 @@
+---
+id: translation
+title: 翻译
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+Yunikorn网站采用Docusaurus管理文档。
+[Docusaurus国际化系统(i18n)](https://docusaurus.io/docs/i18n/tutorial)允许开发人员翻译文档。
+为网站添加新的语言翻译时，开发者应进行如下操作。
+
+## 修改docusaurus.config.js以支持新语言
+假设通过**新语言关键字**进行翻译。
+预期的结果会像这个图(右上方的<新语言关键字>為test)。
+
+
+当前的Yunikorn网站包括**en**和**zh-cn**文档。
+如果开发者想添加一个新的带有**新语言关键字**的翻译，如fr, jp。
+则开发者需要修改`docusaurus.config.js`中的`i18n`栏位。
+```
+i18n: {
+ defaultLocale: 'en',
+ locales: ['en', 'zh-cn', '<新语言关键字>'],
+ localeConfigs: {
+ en: {
+ label: 'English',
+ },
+ "zh-cn": {
+ label: '中文',
+ },
+ "<新语言关键字>": {
+ label: 'test',
+ }
+ },
+ },
+```
+## 更新local-build.sh中的帮助信息
+将**新语言关键字**添加到`print_usage`函数的语言环境列表中。
+```
+Usage: $(basename "$0") run [locale] | build | clean | help
+ run build the website, and launch the server in a docker image.
+ a locale can be specified, currently supported: "en", "zh-cn", "<新语言关键字>"
+```
+
+## 将最新文件复制到i18n资料夹
+```
+mkdir -p i18n/<新语言关键字>/docusaurus-plugin-content-docs/current
+cp -r docs/** i18n/<新语言关键字>/docusaurus-plugin-content-docs/current
+mkdir -p i18n/<新语言关键字>/docusaurus-plugin-content-pages
+cp -r src/pages/** i18n/<新语言关键字>/docusaurus-plugin-content-pages
+mkdir -p i18n/<新语言关键字>/docusaurus-theme-classic
+```
+
+## 在sidebar.json和footer.json中添加翻译后的信息
+在docusaurus-theme-classic资料夹中创建sidebar.json和footer.json档案。
+例如，添加的footer.json内容如下。
+```
+{
+ "link.item.label.Get Involved": {
+ "message": "参与"
+ },
+ "link.title.Code Repositories": {
+ "message": "代码库"
+ },
+ "link.item.label.People": {
+ "message": "人们"
+ },
+ "link.title.Blog": {
+ "message": "博客"
+ },
+ "link.title.Community": {
+ "message": "社区"
+ }
+}
+```
+
+
+
+## 链接img、assest与styles.module.css
+在`i18n/new language keyword/docusaurus-plugin-content-pages`中创建链接文件。
+
+```
+# 清理重复文件
+rm -rf img
+rm styles.module.css
+# 链接
+ln -s ../../../static/img
+ln -s ../../../src/pages/styles.module.css
+```
+
+在`i18n/new language keyword/docusaurus-plugin-content-docs/current`中创建链接文件。
+```
+# 清理重复文件
+rm -rf assests
+# 链接
+ln -s ../../../../docs/assets
+```
+
+## 采用相对路径
+`src/pages/index.js`中有部分图片url采用绝对路径，采用绝对路径会导致png丢失。
+开发人员需要确保`/i18n/new language keyword/docusaurus-plugin-content-pages/index.js`中的图链接有效。
+例如，在`index.js`中有一个`resource-scheduling.png`图像，图像链接是`/img/resource-scheduling.png`。
+```
+/img/resource-scheduling.png -> ./img/resource-scheduling.png
+```
+## 测试
+```
+./local-build.sh run <新语言关键字>
+```
+
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/get_started/core_features.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/get_started/core_features.md
new file mode 100644
index 0000000000..d6d3c49799
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/get_started/core_features.md
@@ -0,0 +1,71 @@
+---
+id: core_features
+title: 特征
+keywords:
+ - 特征
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+YuniKorn的主要特点包括：
+
+## 应用感知调度
+
+YuniKorn的关键特性之一就是支持应用感知。在默认的K8s调度程序中，它只能根据Pod进行调度，而不能基于用户、作业或者队列进行更细粒度的调度。
+与之不同的是，YuniKorn可以识别用户、作业或者队列，并在做出调度决策时，考虑更多与它们相关的因素，如资源、排序等。
+这使我们能够对资源配额、资源公平性和优先级进行细粒度控制，这是多租户计算系统最重要的需求。
+
+## 层次资源队列
+
+层次队列提供了一种有效的机制来管理集群资源。
+队列的层次结构可以在逻辑上映射到组织结构。这为不同租户提供了对资源的细粒度控制。
+YuniKorn UI 提供了一个集中的视图来监视资源队列的使用情况，它可以帮助您了解不同租户是如何使用资源的。
+此外，用户可以利用设置最小/最大队列容量来为每个租户设定其弹性资源配额。
+
+## 作业排序和排队
+
+YuniKorn将每个资源队列中的队列进行排队，排序策略决定哪个应用程序可以首先获得资源。
+这个策略可以是多种多样的，例如简单的 `FIFO`、`Fair`、`StateAware` 或基于 `Priority` 的策略。
+队列可以维持应用的顺序，调度器根据不同的策略为作业分配相应的资源。这种行为更容易被理解和控制。
+
+此外，当配置队列最大容量时，作业和任务可以在资源队列中正确排队。
+如果剩余的容量不够，它们可以排队等待，直到释放一些资源。这就简化了客户端操作。
+而在默认调度程序中，资源由命名空间资源配额限制：如果命名空间没有足够的配额，Pod就不能被创建。这是由配额许可控制器强制执行的。
+客户端需要更复杂的逻辑来处理此类场景，例如按条件重试。
+
+## 资源公平性
+
+在多租户环境中，许多用户共享集群资源。
+为了避免租户争夺资源或者可能的资源不足，需要做到更细粒度的公平性需求，以此来实现跨用户以及跨团队/组织的公平性。
+考虑到权重或优先级，一些更重要的应用可以获得超过其配额的更多的需求资源。
+这往往与资源预算有关，更细粒度的公平模式可以进一步提高资源控制。
+
+## 资源预留
+
+YuniKorn会自动为未完成的请求进行资源预留。
+如果Pod无法分配，YuniKorn将尝试把它预留在一个满足条件的节点上，并在这个节点上暂时分配该 pod（在尝试其他节点之前）。
+这种机制可以避免这个 Pod 需要的资源被后来提交的更小的、更不挑剔的 Pod 所挤占。
+此功能在批处理工作负载场景中非常重要，因为当对集群提交大量异构 Pod 时，很有可能一些 Pod 会处于“饥饿”状态，即使它们提交得更早。
+
+## 吞吐量
+
+吞吐量是衡量调度器性能的关键标准。这对于一个大规模的分布式系统来说是至关重要的。
+如果吞吐量不好，应用程序可能会浪费时间等待调度，并进一步影响服务的 SLA（服务级别协议）。
+集群越大，对吞吐量的要求也越高。[基于Kube标记的运行评估](performance/evaluate_perf_function_with_kubemark.md) 章节显示了一些性能数据。
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/get_started/get_started.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/get_started/get_started.md
new file mode 100644
index 0000000000..fcf009f0f5
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/get_started/get_started.md
@@ -0,0 +1,76 @@
+---
+id: user_guide
+title: 开始
+slug: /
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+在阅读本指南之前，我们假设您有一个Kubernetes集群或本地 Kubernetes 开发环境，例如 MiniKube。
+还假定 `kubectl` 在您的环境路径内，并且配置正确。
+遵循此 [指南](developer_guide/env_setup.md) 来讲述如何使用 docker-desktop 设置本地Kubernetes集群。
+
+## 安装
+
+最简单的方法是使用我们的 Helm Chart 在现有的Kubernetes集群上部署YuniKorn。
+我们建议使用 Helm 3 或更高版本。
+
+```shell script
+helm repo add yunikorn https://apache.github.io/yunikorn-release
+helm repo update
+kubectl create namespace yunikorn
+helm install yunikorn yunikorn/yunikorn --namespace yunikorn
+```
+
+默认情况下，Helm Chart 将在集群中安装调度器、web服务器和 admission-controller。
+`admission-controller` 一旦安装，它将把所有集群流量路由到YuniKorn。
+这意味着资源调度会委托给YuniKorn。在Helm安装过程中，可以通过将 `embedAdmissionController` 标志设置为 `false` 来禁用它。
+通过将Helm的 `enableSchedulerPlugin` 标志设置为 `true`，YuniKorn调度器也可以以Kubernetes的调度器插件的方式进行部署。
+这种方式将会部署一个包含与默认调度器一起编译的YuniKorn备用Docker镜像。
+这种新模式借助默认的Kubernetes调度器提供了更好的兼容性，并且适合与将所有调度委托给YuniKorn的 admission-controller 协同使用。
+因为这个模式还是很新的，所以默认没有开启。
+
+如果您不确定应该使用哪种部署模式，请参阅我们 [并列比较](user_guide/deployment_modes) 章节的内容。
+
+如果你不想使用 Helm Chart，您可以找到我们的细节教程 [点击这里](developer_guide/deployment.md) 。
+
+## 卸载
+
+运行如下的命令卸载 YuniKorn:
+
+```shell script
+helm uninstall yunikorn --namespace yunikorn
+```
+
+## 访问 Web UI
+
+当部署调度程序时，Web UI 也会部署在容器中。
+我们可以通过以下方式在标准端口上打开 Web 界面的端口转发：
+
+```shell script
+kubectl port-forward svc/yunikorn-service 9889:9889 -n yunikorn
+```
+
+`9889` 是 Web UI 的默认端口。
+完成此操作后，web UI将在以下地址可用: http://localhost:9889 。
+
+
+
+YuniKorn UI 提供了集群资源容量、利用率和所有应用信息的集中视图。
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/performance/evaluate_perf_function_with_kubemark.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/performance/evaluate_perf_function_with_kubemark.md
new file mode 100644
index 0000000000..44f4c67ebd
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/performance/evaluate_perf_function_with_kubemark.md
@@ -0,0 +1,120 @@
+---
+id: evaluate_perf_function_with_kubemark
+title: 使用 Kubemark 评估 YuniKorn 的性能
+keywords:
+ - 性能
+ - 吞吐量
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+YuniKorn 社区关注调度程序的性能，并继续在发布时对其进行优化。 社区已经开发了一些工具来反复测试和调整性能。
+
+## 环境设置
+
+我们利用[Kubemark](https://github.com/kubernetes/kubernetes/blob/release-1.3/docs/devel/kubemark-guide.md#starting-a-kubemark-cluster)评估调度器的性能。 Kubemark是一个模拟大规模集群的测试工具。 它创建空节点，运行空kubelet以假装原始kubelet行为。 这些空节点上的调度pod不会真正执行。它能够创建一个满足我们实验要求的大集群，揭示yunikorn调度器的性能。 请参阅有关如何设置环境的[详细步骤](performance/performance_tutorial.md)。
+
+## 调度程序吞吐量
+
+我们在模拟的大规模环境中设计了一些简单的基准测试场景，以评估调度器的性能。 我们的工具测量[吞吐量](https://en.wikipedia.org/wiki/Throughput)并使用这些关键指标来评估性能。 简而言之，调度程序吞吐量是处理pod从在集群上发现它们到将它们分配给节点的速率。
+
+在本实验中，我们使用 [Kubemark](https://github.com/kubernetes/kubernetes/blob/release-1.3/docs/devel/kubemark-guide.md#starting-a-kubemark-cluster) 设置了一个模拟的2000/4000节点集群。然后我们启动10个[部署](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)，每个部署分别设置5000个副本。 这模拟了大规模工作负载同时提交到K8s集群。 我们的工具会定期监控和检查pod状态，随着时间的推移，根据 `podSpec.StartTime` 计算启动的pod数量。 作为对比，我们将相同的实验应用到相同环境中的默认调度程序。 我们看到了YuniKorn相对于默认调度程序的性能优势，如下图所示：
+
+
+<p align="center">图 1. Yunikorn 和默认调度器吞吐量 </p>
+
+图表记录了集群上所有 Pod 运行所花费的时间：
+
+| 节点数 | yunikorn | k8s 默认调度器 | 差异 |
+|------------------ |:--------------: |:---------------------: |:-----: |
+| 2000(节点) | 204(pods/秒) | 49(pods/秒) | 416% |
+| 4000(节点) | 115(pods/秒) | 48(pods/秒) | 240% |
+
+为了使结果标准化，我们已经运行了几轮测试。 如上所示，与默认调度程序相比，YuniKorn实现了`2 倍`~`4 倍`的性能提升。
+
+:::note
+
+与其他性能测试一样，结果因底层硬件而异，例如服务器CPU/内存、网络带宽、I/O速度等。为了获得适用于您的环境的准确结果，我们鼓励您运行这些测试在靠近生产环境的集群上。
+
+:::
+
+## 性能分析
+
+我们从实验中得到的结果是有希望的。 我们通过观察更多的YuniKorn内部指标进一步深入分析性能，我们能够找到影响性能的几个关键区域。
+
+### K8s 限制
+
+我们发现整体性能实际上受到了K8s主服务的限制，例如api-server、controller-manager和etcd，在我们所有的实验中都没有达到YuniKorn的限制。 如果您查看内部调度指标，您可以看到：
+
+
+<p align="center">图 2. 4k 节点中的 Yunikorn 指标 </p>
+
+图2是Prometheus的截图，它记录了YuniKorn中的[内部指标](performance/metrics.md) `containerAllocation`。 它们是调度程序分配的 pod 数量，但不一定绑定到节点。 完成调度50k pod大约需要122秒，即410 pod/秒。 实际吞吐量下降到115个 Pod/秒，额外的时间用于绑定不同节点上的Pod。 如果K8s方面能赶上来，我们会看到更好的结果。 实际上，当我们在大规模集群上调整性能时，我们要做的第一件事就是调整API-server、控制器管理器中的一些参数，以提高吞吐量。 在[性能教程文档](performance/performance_tutorial.md)中查看更多信息。
+
+### 节点排序
+
+当集群大小增加时，我们看到YuniKorn的性能明显下降。 这是因为在YuniKorn中，我们对集群节点进行了完整排序，以便为给定的pod找到 **“best-fit”** 节点。 这种策略使Pod分布更加优化，基于所使用的 [节点排序策略](./../user_guide/sorting_policies#node-sorting)。 但是，对节点进行排序很昂贵，在调度周期中这样做会产生很多开销。 为了克服这个问题，我们在 [YUNIKORN-807](https://issues.apache.org/jira/browse/YUNIKORN-807) 中改进了我们的节点排序机制，其背后的想法是使用 [B-Tree ](https://en.wikipedia.org/wiki/B-tree)来存储所有节点并在必要时应用增量更新。 这显着改善了延迟，根据我们的基准测试，这在500、1000、2000 和 5000个节点的集群上分别提高了 35 倍、42 倍、51 倍、74 倍。
+
+### 每个节点的前提条件检查
+
+在每个调度周期中，另一个耗时的部分是节点的“前提条件检查”。 在这个阶段，YuniKorn评估所有K8s标准断言(Predicates)，例如节点选择器、pod亲和性/反亲和性等，以确定pod是否适合节点。 这些评估成本很高。
+
+我们做了两个实验来比较启用和禁用断言评估的情况。 请参阅以下结果：
+
+
+<p align="center">图 3. Yunikorn 中的断言效果比较 </p>
+
+当断言评估被禁用时，吞吐量会提高很多。 我们进一步研究了整个调度周期的延迟分布和断言评估延迟。 并发现：
+
+
+<p align="center">图 4. 断言延迟 </p>
+
+
+<p align="center">图 5. 启用断言的调度时间 </p>
+
+
+<p align="center">图 6. 不启用断言的调度时间 </p>
+
+总体而言，YuniKorn 调度周期运行得非常快，每个周期的延迟下降在 **0.001s - 0.01s** 范围内。 并且大部分时间用于断言评估，10倍于调度周期中的其他部分。
+
+| | 调度延迟分布（秒） | 断言-评估延迟分布（秒） |
+|----------------------- |:---------------------: |:---------------------: |
+| 启用断言 | 0.01 - 0.1 | 0.01-0.1 |
+| 不启用断言 | 0.001 - 0.01 | 无 |
+
+## 为什么 YuniKorn 更快?
+
+默认调度器被创建为面向服务的调度器； 与YuniKorn相比，它在吞吐量方面的敏感性较低。 YuniKorn社区非常努力地保持出色的性能并不断改进。 YuniKorn可以比默认调度器运行得更快的原因是：
+
+* 短调度周期
+
+YuniKorn 保持调度周期短而高效。 YuniKorn 使用所有异步通信协议来确保所有关键路径都是非阻塞调用。 大多数地方只是在进行内存计算，这可能非常高效。 默认调度器利用 [调度框架](https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/)，它为扩展调度器提供了很大的灵活性，但是，权衡是性能。 调度周期变成了一条很长的链，因为它需要访问所有这些插件。
+
+* 异步事件处理
+
+YuniKorn利用异步事件处理框架来处理内部状态。 这使得核心调度周期可以快速运行而不会被任何昂贵的调用阻塞。 例如，默认调度程序需要将状态更新、事件写入pod对象，这是在调度周期内完成的。 这涉及将数据持久化到etcd，这可能很慢。 YuniKorn将所有此类事件缓存在一个队列中，并以异步方式写回pod。
+
+* 更快的节点排序
+
+[YUNIKORN-807](https://issues.apache.org/jira/browse/YUNIKORN-807)之后，YuniKorn进行了高效的增量节点排序。 这是建立在所谓的基于“资源权重”的节点评分机制之上的，它也可以通过插件进行扩展。 所有这些一起减少了计算节点分数时的开销。 相比之下，默认调度器提供了一些计算节点分数的扩展点，例如`PreScore`、`Score`和`NormalizeScore`。 这些计算量很大，并且在每个调度周期中都会调用它们。 请参阅[代码行](https://github.com/kubernetes/kubernetes/blob/481459d12dc82ab88e413886e2130c2a5e4a8ec4/pkg/scheduler/framework/runtime/framework.go#L857)中的详细信息。
+
+## 概括
+
+在测试过程中，我们发现YuniKorn的性能非常好，尤其是与默认调度程序相比。 我们已经确定了YuniKorn中可以继续提高性能的主要因素，并解释了为什么YuniKorn的性能优于默认调度程序。 我们还意识到将Kubernetes扩展到数千个节点时的局限性，可以通过使用其他技术（例如联合）来缓解这些局限性。 因此，YuniKorn是一个高效、高吞吐量的调度程序，非常适合在Kubernetes上运行批处理/混合工作负载。
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/performance/metrics.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/performance/metrics.md
new file mode 100644
index 0000000000..7d6fa73e5b
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/performance/metrics.md
@@ -0,0 +1,105 @@
+---
+id: metrics
+title: 调度程序指标
+keywords:
+ - 指标
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+YuniKorn利用[Prometheus](https://prometheus.io/) 记录指标。 度量系统不断跟踪调度程序的关键执行路径，以揭示潜在的性能瓶颈。 目前，这些指标分为三类：
+
+- 调度器：调度器的通用指标，例如分配延迟、应用程序数量等。
+- 队列：每个队列都有自己的指标子系统，跟踪队列状态。
+- 事件：记录YuniKorn中事件的各种变化。
+
+所有指标都在`yunikorn`命名空间中声明。
+### 调度程序指标
+
+| 指标名称 | 指标类型 | 描述 |
+| --------------------- | ------------ | ------------ |
+| containerAllocation | Counter | 尝试分配容器的总次数。 尝试状态包括`allocated`, `rejected`, `error`, `released`。 该指标只会增加。 |
+| applicationSubmission | Counter | 提交申请的总数。 尝试的状态包括 `accepted`和`rejected`。 该指标只会增加。 |
+| applicationStatus | Gauge | 申请状态总数。 应用程序的状态包括`running`和`completed`。 |
+| totalNodeActive | Gauge | 活动节点总数。 |
+| totalNodeFailed | Gauge | 失败节点的总数。 |
+| nodeResourceUsage | Gauge | 节点的总资源使用情况，按资源名称。 |
+| schedulingLatency | Histogram | 主调度例程的延迟，以秒为单位。 |
+| nodeSortingLatency | Histogram | 所有节点排序的延迟，以秒为单位。 |
+| appSortingLatency | Histogram | 所有应用程序排序的延迟，以秒为单位。 |
+| queueSortingLatency | Histogram | 所有队列排序的延迟，以秒为单位。 |
+| tryNodeLatency | Histogram | 节点条件检查容器分配的延迟，例如放置约束，以秒为单位。 |
+
+### 队列指标
+
+| 指标名称 | 指标类型 | 描述 |
+| ------------------------- | ------------- | ----------- |
+| appMetrics | Counter | 应用程序指标，记录申请总数。 应用程序的状态包括`accepted`、`rejected`和`Completed`。 |
+| usedResourceMetrics | Gauge | 排队使用的资源。 |
+| pendingResourceMetrics | Gauge | 排队等待的资源。 |
+| availableResourceMetrics | Gauge | 与队列等相关的已用资源指标。 |
+
+### 事件指标
+
+| 指标名称 | 指标类型 | 描述 |
+| ------------------------ | ------------ | ----------- |
+| totalEventsCreated | Gauge | 创建的事件总数。 |
+| totalEventsChanneled | Gauge | 引导的事件总数。 |
+| totalEventsNotChanneled | Gauge | 引导的事件总数。 |
+| totalEventsProcessed | Gauge | 处理的事件总数。 |
+| totalEventsStored | Gauge | 存储的事件总数。 |
+| totalEventsNotStored | Gauge | 未存储的事件总数。 |
+| totalEventsCollected | Gauge | 收集的事件总数。 |
+
+## 访问指标
+
+YuniKorn指标通过Prometheus客户端库收集，并通过调度程序RESTful服务公开。
+启动后，可以通过端点http://localhost:9080/ws/v1/metrics访问它们。
+
+## Prometheus 的聚合指标
+
+设置 Prometheus 服务器以定期获取 YuniKorn 指标很简单。 按着这些次序：
+
+- 设置Prometheus（从[Prometheus 文档](https://prometheus.io/docs/prometheus/latest/installation/)了解更多信息）
+
+- 配置Prometheus规则：示例配置
+
+```yaml
+global:
+ scrape_interval: 3s
+ evaluation_interval: 15s
+
+scrape_configs:
+ - job_name: 'yunikorn'
+ scrape_interval: 1s
+ metrics_path: '/ws/v1/metrics'
+ static_configs:
+ - targets: ['docker.for.mac.host.internal:9080']
+```
+
+- 启动 Prometheus
+
+```shell script
+docker pull prom/prometheus:latest
+docker run -p 9090:9090 -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus
+```
+
+如果您在Mac OS上的本地docker容器中运行Prometheus，请使用`docker.for.mac.host.internal`而不是`localhost`。 启动后，打开Prometheus网页界面：http://localhost:9090/graph。 您将看到来自YuniKorn调度程序的所有可用指标。
+
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/performance/performance_tutorial.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/performance/performance_tutorial.md
new file mode 100644
index 0000000000..8180fa0716
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/performance/performance_tutorial.md
@@ -0,0 +1,451 @@
+---
+id: performance_tutorial
+title: 基准测试教程
+keywords:
+ - 性能
+ - 教程
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+## 概述
+
+YuniKorn社区不断优化调度器的性能，确保YuniKorn满足大规模批处理工作负载的性能要求。 因此，社区为性能基准测试构建了一些有用的工具，可以跨版本重用。 本文档介绍了所有这些工具和运行它们的步骤。
+
+## 硬件
+
+请注意，性能结果因底层硬件而异。 文档中发布的所有结果只能作为参考。 我们鼓励每个人在自己的环境中运行类似的测试，以便根据您自己的硬件获得结果。 本文档仅用于演示目的。
+
+本次测试中使用的服务器列表是（非常感谢[国立台中教育大学](http://www.ntcu.edu.tw/newweb/index.htm), [Kuan-Chou Lai](http://www.ntcu.edu.tw/kclai/) 为运行测试提供这些服务器):
+
+| 机型 | CPU | 内存 | 下载/上传(Mbps) |
+| --------------------- | --- | ------ | --------------------- |
+| HP | 16 | 36G | 525.74/509.86 |
+| HP | 16 | 30G | 564.84/461.82 |
+| HP | 16 | 30G | 431.06/511.69 |
+| HP | 24 | 32G | 577.31/576.21 |
+| IBM blade H22 | 16 | 38G | 432.11/4.15 |
+| IBM blade H22 | 16 | 36G | 714.84/4.14 |
+| IBM blade H22 | 16 | 42G | 458.38/4.13 |
+| IBM blade H22 | 16 | 42G | 445.42/4.13 |
+| IBM blade H22 | 16 | 32G | 400.59/4.13 |
+| IBM blade H22 | 16 | 12G | 499.87/4.13 |
+| IBM blade H23 | 8 | 32G | 468.51/4.14 |
+| WS660T | 8 | 16G | 87.73/86.30 |
+| ASUSPRO D640MB_M640SA | 4 | 8G | 92.43/93.77 |
+| PRO E500 G6_WS720T | 16 | 8G | 90/87.18 |
+| WS E500 G6_WS720T | 8 | 40G | 92.61/89.78 |
+| E500 G5 | 8 | 8G | 91.34/85.84 |
+| WS E500 G5_WS690T | 12 | 16G | 92.2/93.76 |
+| WS E500 G5_WS690T | 8 | 32G | 91/89.41 |
+| WS E900 G4_SW980T | 80 | 512G | 89.24/87.97 |
+
+每个服务器都需要执行以下步骤，否则由于用户/进程/打开文件的数量有限，大规模测试可能会失败。
+
+### 1. 设置/etc/sysctl.conf
+```
+kernel.pid_max=400000
+fs.inotify.max_user_instances=50000
+fs.inotify.max_user_watches=52094
+```
+### 2. 设置/etc/security/limits.conf
+
+```
+* soft nproc 4000000
+* hard nproc 4000000
+root soft nproc 4000000
+root hard nproc 4000000
+* soft nofile 50000
+* hard nofile 50000
+root soft nofile 50000
+root hard nofile 50000
+```
+---
+
+## 部署工作流
+
+在进入细节之前，这里是我们测试中使用的一般步骤：
+
+- [步骤 1](#Kubernetes): 正确配置Kubernetes API服务器和控制器管理器，然后添加工作节点。
+- [步骤 2](#Setup-Kubemark): 部署空pod，将模拟工作节点，命名空节点。 在所有空节点都处于就绪状态后，我们需要封锁(cordon)所有本地节点，这些本地节点是集群中的物理存在，而不是模拟节点，以避免我们将测试工作负载 pod 分配给本地节点。
+- [步骤 3](#Deploy-YuniKorn): 在主节点上使用Helm chart部署YuniKorn，并将 Deployment 缩减为 0 副本，并在`prometheus.yml`中 [修改端口](#Setup-Prometheus) 以匹配服务的端口。
+- [步骤 4](#Run-tests): 部署50k Nginx pod进行测试，API服务器将创建它们。 但是由于YuniKorn调度程序Deployment已经被缩减到0个副本，所有的Nginx pod都将停留在等待状态。
+- [步骤 5](../user_guide/troubleshooting.md#restart-the-scheduler): 将YuniKorn部署扩展回1个副本，并封锁主节点以避免YuniKorn 在那里分配Nginx pod。 在这一步中，YuniKorn将开始收集指标。
+- [步骤 6](#Collect-and-Observe-YuniKorn-metrics): 观察Prometheus UI中公开的指标。
+---
+
+## 设置 Kubemark
+
+[Kubemark](https://github.com/kubernetes/kubernetes/tree/master/test/kubemark)是一个性能测试工具，允许用户在模拟集群上运行实验。 主要用例是可扩展性测试。 基本思想是在一个物理节点上运行数十或数百个假kubelet节点，以模拟大规模集群。 在我们的测试中，我们利用 Kubemark 在少于20个物理节点上模拟多达4K节点的集群。
+
+### 1. 构建镜像
+
+##### 克隆kubernetes仓库，并构建kubemark二进制文件
+
+```
+git clone https://github.com/kubernetes/kubernetes.git
+```
+```
+cd kubernetes
+```
+```
+KUBE_BUILD_PLATFORMS=linux/amd64 make kubemark GOFLAGS=-v GOGCFLAGS="-N -l"
+```
+
+##### 将kubemark二进制文件复制到镜像文件夹并构建kubemark docker镜像
+
+```
+cp _output/bin/kubemark cluster/images/kubemark
+```
+```
+IMAGE_TAG=v1.XX.X make build
+```
+完成此步骤后，您可以获得可以模拟集群节点的kubemark镜像。 您可以将其上传到Docker-Hub或仅在本地部署。
+
+### 2. 安装Kubermark
+
+##### 创建kubemark命名空间
+
+```
+kubectl create ns kubemark
+```
+
+##### 创建configmap
+
+```
+kubectl create configmap node-configmap -n kubemark --from-literal=content.type="test-cluster"
+```
+
+##### 创建secret
+
+```
+kubectl create secret generic kubeconfig --type=Opaque --namespace=kubemark --from-file=kubelet.kubeconfig={kubeconfig_file_path} --from-file=kubeproxy.kubeconfig={kubeconfig_file_path}
+```
+### 3. 标签节点
+
+我们需要给所有的原生节点打上标签，否则调度器可能会将空pod分配给其他模拟的空节点。 我们可以利用yaml中的节点选择器将空pod分配给本地节点。
+
+```
+kubectl label node {node name} tag=tagName
+```
+
+### 4. 部署Kubemark
+
+hollow-node.yaml如下所示，我们可以配置一些参数。
+
+```
+apiVersion: v1
+kind: ReplicationController
+metadata:
+ name: hollow-node
+ namespace: kubemark
+spec:
+ replicas: 2000 # 要模拟的节点数
+ selector:
+ name: hollow-node
+ template:
+ metadata:
+ labels:
+ name: hollow-node
+ spec:
+ nodeSelector: # 利用标签分配给本地节点
+ tag: tagName
+ initContainers:
+ - name: init-inotify-limit
+ image: docker.io/busybox:latest
+ imagePullPolicy: IfNotPresent
+ command: ['sysctl', '-w', 'fs.inotify.max_user_instances=200'] # 设置为与实际节点中的max_user_instance相同
+ securityContext:
+ privileged: true
+ volumes:
+ - name: kubeconfig-volume
+ secret:
+ secretName: kubeconfig
+ - name: logs-volume
+ hostPath:
+ path: /var/log
+ containers:
+ - name: hollow-kubelet
+ image: 0yukali0/kubemark:1.20.10 # 您构建的kubemark映像
+ imagePullPolicy: IfNotPresent
+ ports:
+ - containerPort: 4194
+ - containerPort: 10250
+ - containerPort: 10255
+ env:
+ - name: NODE_NAME
+ valueFrom:
+ fieldRef:
+ fieldPath: metadata.name
+ command:
+ - /kubemark
+ args:
+ - --morph=kubelet
+ - --name=$(NODE_NAME)
+ - --kubeconfig=/kubeconfig/kubelet.kubeconfig
+ - --alsologtostderr
+ - --v=2
+ volumeMounts:
+ - name: kubeconfig-volume
+ mountPath: /kubeconfig
+ readOnly: true
+ - name: logs-volume
+ mountPath: /var/log
+ resources:
+ requests: # 空pod的资源，可以修改。
+ cpu: 20m
+ memory: 50M
+ securityContext:
+ privileged: true
+ - name: hollow-proxy
+ image: 0yukali0/kubemark:1.20.10 # 您构建的kubemark映像
+ imagePullPolicy: IfNotPresent
+ env:
+ - name: NODE_NAME
+ valueFrom:
+ fieldRef:
+ fieldPath: metadata.name
+ command:
+ - /kubemark
+ args:
+ - --morph=proxy
+ - --name=$(NODE_NAME)
+ - --use-real-proxier=false
+ - --kubeconfig=/kubeconfig/kubeproxy.kubeconfig
+ - --alsologtostderr
+ - --v=2
+ volumeMounts:
+ - name: kubeconfig-volume
+ mountPath: /kubeconfig
+ readOnly: true
+ - name: logs-volume
+ mountPath: /var/log
+ resources: # 空pod的资源，可以修改。
+ requests:
+ cpu: 20m
+ memory: 50M
+ tolerations:
+ - effect: NoExecute
+ key: node.kubernetes.io/unreachable
+ operator: Exists
+ - effect: NoExecute
+ key: node.kubernetes.io/not-ready
+ operator: Exists
+```
+
+完成编辑后，将其应用于集群：
+
+```
+kubectl apply -f hollow-node.yaml
+```
+
+---
+
+## 部署 YuniKorn
+
+#### 使用helm安装YuniKorn
+
+我们可以用 Helm 安装 YuniKorn，请参考这个[文档](https://yunikorn.apache.org/docs/#install)。 我们需要根据默认配置调整一些参数。 我们建议克隆[发布仓库](https://github.com/apache/yunikorn-release)并修改`value.yaml`中的参数。
+
+```
+git clone https://github.com/apache/yunikorn-release.git
+cd helm-charts/yunikorn
+```
+
+#### 配置
+
+`value.yaml`中的修改是：
+
+- 增加调度程序 pod 的内存/cpu 资源
+- 禁用 admission controller
+- 将应用排序策略设置为 FAIR
+
+请参阅以下更改：
+
+```
+resources:
+ requests:
+ cpu: 14
+ memory: 16Gi
+ limits:
+ cpu: 14
+ memory: 16Gi
+```
+```
+embedAdmissionController: false
+```
+```
+configuration: |
+ partitions:
+ -
+ name: default
+ queues:
+ - name: root
+ submitacl: '*'
+ queues:
+ -
+ name: sandbox
+ properties:
+ application.sort.policy: fair
+```
+
+#### 使用本地版本库安装YuniKorn
+
+```
+Helm install yunikorn . --namespace yunikorn
+```
+
+---
+
+## 设置Prometheus
+
+YuniKorn通过Prometheus公开其调度指标。 因此，我们需要设置一个Prometheus服务器来收集这些指标。
+
+### 1. 下载Prometheus版本
+
+```
+wget https://github.com/prometheus/prometheus/releases/download/v2.30.3/prometheus-2.30.3.linux-amd64.tar.gz
+```
+```
+tar xvfz prometheus-*.tar.gz
+cd prometheus-*
+```
+
+### 2. 配置prometheus.yml
+
+```
+global:
+ scrape_interval: 3s
+ evaluation_interval: 15s
+
+scrape_configs:
+ - job_name: 'yunikorn'
+ scrape_interval: 1s
+ metrics_path: '/ws/v1/metrics'
+ static_configs:
+ - targets: ['docker.for.mac.host.internal:9080']
+ # 9080为内部端口，需要端口转发或修改9080为服务端口
+```
+
+### 3. 启动Prometheus
+```
+./prometheus --config.file=prometheus.yml
+```
+
+---
+## 运行测试
+
+设置环境后，您就可以运行工作负载并收集结果了。 YuniKorn社区有一些有用的工具来运行工作负载和收集指标，更多详细信息将在此处发布。
+
+---
+
+## 收集和观察YuniKorn指标
+
+Prometheus 启动后，可以轻松收集 YuniKorn 指标。 这是 YuniKorn 指标的[文档](metrics.md)。 YuniKorn 跟踪一些关键调度指标，这些指标衡量一些关键调度路径的延迟。 这些指标包括：
+
+ - **scheduling_latency_seconds:** 主调度例程的延迟，以秒为单位。
+ - **app_sorting_latency_seconds**: 所有应用程序排序的延迟，以秒为单位。
+ - **node_sorting_latency_seconds**: 所有节点排序的延迟，以秒为单位。
+ - **queue_sorting_latency_seconds**: 所有队列排序的延迟，以秒为单位。
+ - **container_allocation_attempt_total**: 尝试分配容器的总次数。 尝试状态包括 `allocated`、`rejected`、`error`、`released`。 该指标仅增加。
+
+您可以在Prometheus UI上轻松选择和生成图形，例如：
+
+
+
+
+---
+
+## 性能调优
+
+### Kubernetes
+
+默认的 K8s 设置限制了并发请求，这限制了集群的整体吞吐量。 在本节中，我们介绍了一些需要调整的参数，以提高集群的整体吞吐量。
+
+#### kubeadm
+
+设置pod网络掩码
+
+```
+kubeadm init --pod-network-cidr=10.244.0.0/8
+```
+
+#### CNI
+
+修改CNI掩码和资源。
+
+```
+ net-conf.json: |
+ {
+ "Network": "10.244.0.0/8",
+ "Backend": {
+ "Type": "vxlan"
+ }
+ }
+```
+```
+ resources:
+ requests:
+ cpu: "100m"
+ memory: "200Mi"
+ limits:
+ cpu: "100m"
+ memory: "200Mi"
+```
+
+
+#### Api-Server
+
+在 Kubernetes API 服务器中，我们需要修改两个参数：`max-mutating-requests-inflight`和`max-requests-inflight`。 这两个参数代表API请求带宽。 因为我们会产生大量的Pod请求，所以我们需要增加这两个参数。修改`/etc/kubernetes/manifest/kube-apiserver.yaml`：
+
+```
+--max-mutating-requests-inflight=3000
+--max-requests-inflight=3000
+```
+
+#### Controller-Manager
+
+在Kubernetes控制器管理器中，我们需要增加三个参数的值：`node-cidr-mask-size`、`kube-api-burst` `kube-api-qps`. `kube-api-burst`和`kube-api-qps`控制服务器端请求带宽。`node-cidr-mask-size`表示节点 CIDR。 为了扩展到数千个节点，它也需要增加。
+
+
+Modify `/etc/kubernetes/manifest/kube-controller-manager.yaml`:
+
+```
+--node-cidr-mask-size=21 //log2(集群中的最大pod数)
+--kube-api-burst=3000
+--kube-api-qps=3000
+```
+
+#### kubelet
+
+在单个工作节点中，我们可以默认运行110个pod。 但是为了获得更高的节点资源利用率，我们需要在Kubelet启动命令中添加一些参数，然后重启它。
+
+修改`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`中的起始参数，在起始参数后面添加`--max-Pods=300`并重启。
+
+```
+systemctl daemon-reload
+systemctl restart kubelet
+```
+
+---
+
+## 概括
+
+借助Kubemark和Prometheus，我们可以轻松运行基准测试、收集YuniKorn指标并分析性能。 这有助于我们识别调度程序中的性能瓶颈并进一步消除它们。 YuniKorn社区未来将继续改进这些工具，并继续获得更多的性能改进。
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/performance/profiling.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/performance/profiling.md
new file mode 100644
index 0000000000..eb2ae74421
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/performance/profiling.md
@@ -0,0 +1,115 @@
+---
+id: profiling
+title: 分析
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+使用[pprof](https://github.com/google/pprof)做CPU，Memory profiling可以帮助你了解YuniKorn调度器的运行状态。YuniKorn REST服务中添加了分析工具，我们可以轻松地从HTTP端点检索和分析它们。
+
+## CPU 分析
+
+在这一步，确保你已经运行了YuniKorn，它可以通过`make run`命令从本地运行，也可以部署为在K8s内运行的pod。 然后运行
+
+```
+go tool pprof http://localhost:9080/debug/pprof/profile
+```
+
+配置文件数据将保存在本地文件系统中，一旦完成，它就会进入交互模式。 现在您可以运行分析命令，例如
+
+```
+(pprof) top
+Showing nodes accounting for 14380ms, 44.85% of 32060ms total
+Dropped 145 nodes (cum <= 160.30ms)
+Showing top 10 nodes out of 106
+ flat flat% sum% cum cum%
+ 2130ms 6.64% 6.64% 2130ms 6.64% __tsan_read
+ 1950ms 6.08% 12.73% 1950ms 6.08% __tsan::MetaMap::FreeRange
+ 1920ms 5.99% 18.71% 1920ms 5.99% __tsan::MetaMap::GetAndLock
+ 1900ms 5.93% 24.64% 1900ms 5.93% racecall
+ 1290ms 4.02% 28.67% 1290ms 4.02% __tsan_write
+ 1090ms 3.40% 32.06% 3270ms 10.20% runtime.mallocgc
+ 1080ms 3.37% 35.43% 1080ms 3.37% __tsan_func_enter
+ 1020ms 3.18% 38.62% 1120ms 3.49% runtime.scanobject
+ 1010ms 3.15% 41.77% 1010ms 3.15% runtime.nanotime
+ 990ms 3.09% 44.85% 990ms 3.09% __tsan::DenseSlabAlloc::Refill
+```
+
+您可以键入诸如`web`或`gif`之类的命令来获得可以更好地帮助您的图表
+了解关键代码路径的整体性能。 你可以得到一些东西
+如下所示：
+
+
+
+注意，要使用这些选项，您需要先安装虚拟化工具`graphviz`，如果您使用的是 Mac，只需运行`brew install graphviz`，更多信息请参考[这里](https://graphviz. gitlab.io/）。
+
+## 内存分析
+
+同样，您可以运行
+
+```
+go tool pprof http://localhost:9080/debug/pprof/heap
+```
+
+这将返回当前堆的快照，允许我们检查内存使用情况。 进入交互模式后，您可以运行一些有用的命令。 比如top可以列出top内存消耗的对象。
+```
+(pprof) top
+Showing nodes accounting for 83.58MB, 98.82% of 84.58MB total
+Showing top 10 nodes out of 86
+ flat flat% sum% cum cum%
+ 32MB 37.84% 37.84% 32MB 37.84% github.com/apache/yunikorn-core/pkg/cache.NewClusterInfo
+ 16MB 18.92% 56.75% 16MB 18.92% github.com/apache/yunikorn-core/pkg/rmproxy.NewRMProxy
+ 16MB 18.92% 75.67% 16MB 18.92% github.com/apache/yunikorn-core/pkg/scheduler.NewScheduler
+ 16MB 18.92% 94.59% 16MB 18.92% github.com/apache/yunikorn-k8shim/pkg/dispatcher.init.0.func1
+ 1.04MB 1.23% 95.81% 1.04MB 1.23% k8s.io/apimachinery/pkg/runtime.(*Scheme).AddKnownTypeWithName
+ 0.52MB 0.61% 96.43% 0.52MB 0.61% github.com/gogo/protobuf/proto.RegisterType
+ 0.51MB 0.61% 97.04% 0.51MB 0.61% sync.(*Map).Store
+ 0.50MB 0.6% 97.63% 0.50MB 0.6% regexp.onePassCopy
+ 0.50MB 0.59% 98.23% 0.50MB 0.59% github.com/json-iterator/go.(*Iterator).ReadString
+ 0.50MB 0.59% 98.82% 0.50MB 0.59% text/template/parse.(*Tree).newText
+```
+
+您还可以运行 `web`、`pdf` 或 `gif` 命令来获取堆图形。
+
+## 下载分析样本并在本地进行分析
+
+我们在调度程序docker映像中包含了基本的go/go-tool二进制文件，您应该能够进行一些基本的分析
+docker容器内的分析。 但是，如果您想深入研究一些问题，最好进行分析
+本地。 然后您需要先将示例文件复制到本地环境。 复制文件的命令如下：
+
+```
+kubectl cp ${SCHEDULER_POD_NAME}:${SAMPLE_PATH_IN_DOCKER_CONTAINER} ${LOCAL_COPY_PATH}
+```
+
+例如
+
+```
+kubectl cp yunikorn-scheduler-cf8f8dd8-6szh5:/root/pprof/pprof.k8s_yunikorn_scheduler.samples.cpu.001.pb.gz /Users/wyang/Downloads/pprof.k8s_yunikorn_scheduler.samples.cpu.001.pb.gz
+```
+
+在本地环境中获取文件后，您可以运行“pprof”命令进行分析。
+
+```
+go tool pprof /Users/wyang/Downloads/pprof.k8s_yunikorn_scheduler.samples.cpu.001.pb.gz
+```
+
+## 资源
+
+* pprof 文档 https://github.com/google/pprof/tree/master/doc。
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/deployment_modes.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/deployment_modes.md
new file mode 100644
index 0000000000..b33e1502aa
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/deployment_modes.md
@@ -0,0 +1,48 @@
+---
+id: deployment_modes
+title: 部署模式
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+## YuniKorn部署模式
+
+YuniKorn有两种部署模式: `标准模式`与`插件模式`。
+在标准模式下，YuniKorn作为自定义模式运行Kubernetes调度程序。
+在插件模式下，YuniKorn被实现为默认Kubernetes调度框架之上的一组插件。
+
+在这两种情况下，建议同时运行准入控制器(admin controller)，这会确保只有一个调度程序在您的Kubernetes集群中处于活动状态。
+当准入控制器运行时，所有pod将会绕过Kubernetes的默认调度器，除了YuniKorn本身的pod。
+
+## 应该使用哪个版本？
+
+### 标准模式(Standard)
+
+目前的默认模式是标准模式。 标准模式提供稳定、高效、良好性能。
+当pod利用YuniKorn的队列功能，此模式非常适合大多数此类部署。
+
+### 插件模式(Plugin)
+
+插件模式是一种新的部署模型，调度器是在默认的Kubernetes调度逻辑之上实现的，可以更好地兼容默认的Kubernetes调度器。
+它非常适合混合工作负载，如传统的Kubernetes以及排队的应用程序。
+
+插件模式目前非常新，因此还没有达到标准模式的成熟度。
+
+要在使用 Helm 部署时激活插件模式，请将变量`enableSchedulerPlugin`设置为`true`。
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/gang_scheduling.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/gang_scheduling.md
new file mode 100644
index 0000000000..754e29c329
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/gang_scheduling.md
@@ -0,0 +1,297 @@
+---
+id: gang_scheduling
+title: 分组调度
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+## 什么是分组调度
+
+当分组调度被启用时，YuniKorn 只在以下情况下调度应用程序
+应用程序的最小资源请求能够得到满足时才会调度。否则，应用程序
+将在队列中等待。应用程序被排在层次队列中、
+启用分组调度后，每个资源队列都被分配有
+在保证最小资源的情况下，每个资源队列都被分配了最大数量的应用程序并发运行。
+
+
+
+## 启用分组调度
+
+启用分组调度不需要在集群范围内进行配置。
+调度器会主动监控每个应用的元数据，如果该应用包含了
+一个有效的任务组定义，它就会被认为是所需的分组调度。
+
+:::info 任务组
+一个任务组是一个应用程序中的任务 "群组"，这些任务具有相同的资源概况
+和相同的放置限制。它们被认为是同质化的请求，在调度器中可以被视为
+在调度器中被当作同一类请求处理。
+:::
+
+### 前提
+
+对于运行支持调度的应用程序的队列，队列排序策略应该被设置为 "FIFO"。
+要配置队列排序策略，请参考文档：[应用程序排序](user_guide/sorting_policies.md#应用程序排序)。
+
+#### 为什么要使用 "FIFO" 排序策略？
+
+当分组调度被启用时，调度器会主动为每个应用程序保留资源。
+如果队列排序策略不是基于FIFO（StateAware 是基于 FIFO 的排序策略）、
+调度器可能会为每个应用保留部分资源并导致资源分割问题。
+
+#### "StateAware" 排序策略的副作用
+
+我们不建议使用 `StateAware`，尽管它是一个基于 FIFO 的策略。第一个 pod 的失败或者该 pod 的初始化时间过长都会使处理过程变慢。
+当驱动在请求执行器之前进行大量的预处理时，尤其是 Spark。
+在这些情况下，`StateAware` 超时会使处理速度减慢到每次超时只有一个应用程序。
+这实际上会推翻群组的保留，并导致减速和过度使用资源。
+
+### 应用程序配置
+
+在 Kubernetes 上，YuniKorn 通过从单个pod加载元数据来发现应用，应用的第一个pod
+被要求附上一份完整的应用元数据副本。如果应用程序没有关于第一个或第二个pod的任何注释，
+那么所有的pod都需要携带相同的 taskGroups 信息。分组調度需要 taskGroups 的定义，
+可以通过 pod 注解来指定。所需的字段是：
+
+| 注释 | 价值 |
+|-----|------|
+| yunikorn.apache.org/task-group-name | 任务组名称，在应用程序中必须是唯一的。 |
+| yunikorn.apache.org/task-groups | 任务组的列表，每一项都包含了为该任务组定义的所有信息。 |
+| yunikorn.apache.org/schedulingPolicyParameters | 可选。一个任意的键值对来定义调度策略参数。请阅读[调度策略参数](#调度策略参数) |
+
+#### 需要多少个任务组？
+
+这取决于这个应用程序向 K8s 请求多少不同类型的 pod。一个任务组是一个应用程序中的任务 "群组"、
+这些任务具有相同的资源概况和相同的放置限制。它们被认为是同质的
+在调度器中可以被视为同类的请求。以 Spark 为例，每个作业都需要有2个任务组、
+一个用于driver pod，另一个用于 executor pods。
+
+#### 如何定义任务组？
+
+任务组的定义是应用程序的真实pod定义的副本，像资源、节点选择器、容忍度
+和亲和力应该与真正的pod相同。这是为了确保调度器能够以准确的pod规格保留资源。
+确切正确的pod规范。
+
+#### 调度策略参数
+
+调度策略相关的可配置参数。在pod的注释中以下列格式应用这些参数：
+
+```yaml
+annotations:
+ yunikorn.apache.org/schedulingPolicyParameters: "PARAM1=VALUE1 PARAM2=VALUE2 ..."
+```
+
+目前，支持以下参数：
+
+`placeholderTimeoutInSeconds`
+
+默认值： *15分钟*。
+这个参数定义了预约超时，即调度器在放弃分配所有占位符之前应该等待多长时间。
+当调度器*分配第一个占位器pod*时，超时计时器开始计时。这确保了如果调度器
+无法调度所有的占位荚，它最终会在一定的时间后放弃。这样，资源可以被
+释放出来，供其他应用程序使用。如果没有占位符可以被分配，这个超时就不会启动。为了避免占位符
+pods永远卡住，请参考 [故障排除](troubleshooting.md#成组调度) 了解解决方案。
+
+`gangSchedulingStyle`
+
+有效值： *Soft*, *Hard*
+
+默认值：*Soft*.
+这个参数定义了当应用程序由于占位符 pod 分配而遇到分组问题时的后退机制。
+更多细节见[分组调度风格](#分组调度风格)部分
+
+更多的调度参数将被添加，以便在调度应用程序时提供更多的灵活性。
+
+#### 示例
+
+下面的例子是一个工作的yaml文件。这个工作启动了2个 pod，每个 pod 睡眠时间为 30 秒。
+在 pod 规范中值得注意的变化是 *spec.template.metadata.annotations*，在这里我们定义了 `yunikorn.apache.org/task-group-name
+和 `yunikorn.apache.org/task-groups` 。
+
+```yaml
+apiVersion: batch/v1
+kind: Job
+metadata:
+ name: gang-scheduling-job-example
+spec:
+ completions: 2
+ parallelism: 2
+ template:
+ metadata:
+ labels:
+ app: sleep
+ applicationId: "gang-scheduling-job-example"
+ queue: root.sandbox
+ annotations:
+ yunikorn.apache.org/task-group-name: task-group-example
+ yunikorn.apache.org/task-groups: |-
+ [{
+ "name": "task-group-example",
+ "minMember": 2,
+ "minResource": {
+ "cpu": "100m",
+ "memory": "50M"
+ },
+ "nodeSelector": {},
+ "tolerations": [],
+ "affinity": {}
+ }]
+ spec:
+ schedulerName: yunikorn
+ restartPolicy: Never
+ containers:
+ - name: sleep30
+ image: "alpine:latest"
+ command: ["sleep", "30"]
+ resources:
+ requests:
+ cpu: "100m"
+ memory: "50M"
+```
+
+当这项工作提交给 Kubernetes 时，将使用同一模板创建2个pod，它们都属于一个任务组：
+*"task-group-example"*。 YuniKorn将创建2个占位符pod，每个都使用任务组定义中指定的资源。
+当所有2个占位符分配完毕后，调度器将使用占位符保留的位置来绑定真正的2个睡眠pods。
+
+如果有必要，你可以添加多个任务组，每个任务组由任务组名称标识、
+通过设置任务组名称，需要将每个真实的pod与一个预先定义的任务组进行映射。注意、
+任务组名称只要求在一个应用程序中是唯一的。
+
+
+### 启用Spark作业的Gang调度
+
+每个Spark作业都运行2种类型的pod，驱动和执行器。因此，我们需要为每个作业定义2个任务组。
+驱动器pod的注释看起来像：
+
+```yaml
+Annotations:
+ yunikorn.apache.org/schedulingPolicyParameters: “placeholderTimeoutSeconds=30”
+ yunikorn.apache.org/taskGroupName: “spark-driver”
+ yunikorn.apache.org/taskGroup: “
+ TaskGroups: [
+ {
+ Name: “spark-driver”,
+ minMember: 1,
+ minResource: {
+ Cpu: 1,
+ Memory: 2Gi
+ },
+ Node-selector: ...,
+ Tolerations: ...,
+ Affinity: ...
+ },
+ {
+ Name: “spark-executor”,
+ minMember: 10,
+ minResource: {
+ Cpu: 1,
+ Memory: 2Gi
+ }
+ }
+ ]
+ ”
+```
+
+:::note
+任务组的资源必须考虑到Spark驱动和执行器的内存开销。
+参见 [Spark documentation](https://spark.apache.org/docs/latest/configuration.html#application-properties) 以了解如何计算这些数值的细节。
+:::
+
+对于所有的执行者 pod，
+
+```yaml
+Annotations:
+ # 任务组字段中定义的名称相匹配
+ # 在任务组字段中定义
+ yunikorn.apache.org/taskGroupName: “spark-executor”
+```
+
+一旦工作被提交给调度器，工作就不会被立即调度。
+相反，在实际启动驱动/执行器之前，调度器将确保它获得最小的资源。
+
+## 分组调度风格
+
+有2种分组调度方式支持，分别是 Soft 和 Hard。它可以在每个应用层面进行配置，以定义应用在分组调度失败时的行为。
+
+- `Hard Style`：当使用这种风格时，我们将有初始行为，更确切地说，如果应用程序不能根据分组调度规则进行调度，并且超时，它将被标记为失败，而不会重新尝试调度。
+- `Soft Style`：当应用程序不能被分组调度时，它将退回到正常的调度，并使用非分组调度策略来实现最佳努力的调度。当这种情况发生时，应用程序将过渡到恢复状态，所有剩余的占位符 pod 将被清理掉。
+
+**使用的默认样式**： ``Soft。
+
+**启用一个特定的风格**：可以通过在应用程序定义中设置'gangSchedulingStyle'参数来改变风格，即 Soft 或 Hard。
+
+#### Example
+
+```yaml
+apiVersion: batch/v1
+kind: Job
+metadata:
+ name: gang-app-timeout
+spec:
+ completions: 4
+ parallelism: 4
+ template:
+ metadata:
+ labels:
+ app: sleep
+ applicationId: gang-app-timeout
+ queue: fifo
+ annotations:
+ yunikorn.apache.org/task-group-name: sched-style
+ yunikorn.apache.org/schedulingPolicyParameters: "placeholderTimeoutInSeconds=60 gangSchedulingStyle=Hard"
+ yunikorn.apache.org/task-groups: |-
+ [{
+ "name": "sched-style",
+ "minMember": 4,
+ "minResource": {
+ "cpu": "1",
+ "memory": "1000M"
+ },
+ "nodeSelector": {},
+ "tolerations": [],
+ "affinity": {}
+ }]
+ spec:
+ schedulerName: yunikorn
+ restartPolicy: Never
+ containers:
+ - name: sleep30
+ image: "alpine:latest"
+ imagePullPolicy: "IfNotPresent"
+ command: ["sleep", "30"]
+ resources:
+ requests:
+ cpu: "1"
+ memory: "1000M"
+
+```
+
+## 验证配置
+
+为了验证配置是否已经完全正确，请检查以下事项：
+1. 当一个应用程序被提交时，验证预期的占位符数量是否被调度器创建。
+如果你定义了两个任务组，一个是minMember 1，另一个是minMember 5，这意味着我们期望在任务提交后有6个占位符被创建。
+被创建。
+2. 验证占位符的规格是否正确。每个占位符都需要有与同一任务组中的真实pod相同的信息。
+检查领域包括：命名空间、pod资源、节点选择器、容忍度和亲和力。
+3. 验证占位符可以分配到正确的节点类型上，并验证真正的pod是通过替换占位符pod而启动的。
+
+## 故障排除
+
+请参阅启用帮派调度时的故障排除文档 [這裡](troubleshooting.md#成组调度)
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/placement_rules.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/placement_rules.md
new file mode 100644
index 0000000000..17ccd279c8
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/placement_rules.md
@@ -0,0 +1,296 @@
+---
+id: placement_rules
+title: App 放置规则
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+基础的放置规则(placement rules)配置[调度弃配置设计文档](../design/scheduler_configuration#placement-rules-definition)中有相关描述。
+
+我们可以将多个规则链结再一起形成一个放置策略，并通过[存取控制列表(Access control lists)](user_guide/acls.md)和规则过滤来定义和执行规则。
+
+本篇文章将通过例子来解释如何建立策略以及规则的使用，而该放置策略为调度器的一部分。
+
+## 配置
+放置规则作为调度程序队列配置的一部分，可以在各分区(partition)中被定义。规则定义的顺序就是他们会被执行的顺序。如果一个规则匹配，策略会停止执行剩余的规则。
+
+匹配的放置规则会产生一个完全合格的队列名称。同时这个回传的队列名称会从根队列(root)开始。而在队列层次结构中，可以生成的层次数量没有限制。
+
+当要执行一条规则时，已经被执行过的规则不会被列入考虑；这条规则也不会对往后要执行的规则有所影响：规则不能影响其他的规则，除非它们被配置为父规则([parent](#parent-参数))。
+
+当放置策略没有生成队列名称且没有更多的规则时，应用程式将会被拒绝。
+
+在配置中，定义放置规则的基本结构如下：
+```yaml
+placementrules:
+ - name: <第一条放置规则的名称>
+ - name: <第二条放置规则的名称>
+```
+每个[规则](#规则)都可以在配置中采取一套预定义的参数。可以被使用的规则名称在规则描述中提及。规则名称在配置中不区分大小写，且必须遵从以下的命名惯例：
+* 从字母开始：a-z 或 A-Z
+* 后面跟着0或多个字元 a-z, A-Z, 0-9 或 _
+
+当规则名称没有对应到任何已定义的规则时，表示规则处于未知的状态，会造成放置管理器初始化错误。如果参数不正确，会抛出解析错误或在初始化时发生错误。一个有错误的规则集永远不可能被激活。
+
+如果放置管理器中含有一个被激活的规则集，就代表他已经初始化了。重新载入时，若配置了一个新的规则集时，就会将新的规则集激活，并取代旧有的。如果新规则集包含一个错误，放置管理器就会忽视这个新规则集，同时也持续处于「使用不完全的规则集」的状态。如果放置管理器持续使用已激活的规则集，忽视新的且有错误的规则集时，则会记录一条关于坏掉且被忽视的配置信息。
+
+规则结果中的「点 "."」，会被文字的「"\_dot\_"」所替代。而「点」会被取代是因为在完全限定的队列名称中，他是被用来分隔队列层次的。而替代过程是发生在建构完整队列层次，且结果合格之前。这代表我们允许用「点」来表达用户名或标籤值，但不影响到队列层次。举例来说，当配置中的队列对应到「含有点的用户名」时，你必须要使用以下方法来指定它们：如果一个用户名称为`user.name`且使用`user`规则，则会产生队列名称为`root.user_dot_name`的队列。而如果该用户队列必须事先被加到配置中，则也该使用`user_dot_name`这个名字。
+
+### Create 参数
+create 参数是一个布林值，会定义当一个队列不存在时，是否可以在规则的定义下创建队列。不能保证队列一定会被创建，因为现有的队列可能会阻止创建。但如果规则定义下想创建的队列不存在，且`create: false`，那结果将会是创建失败。
+
+带有`create`参数的简易yaml范例：
+```yaml
+placementrules:
+ - name: <放置规则的名称>
+ create: true
+```
+预设值为`false`。允许的值为`true`或`false`，其他值均会导致显示错误。
+
+### Parent 参数
+`parent` 参数允许指定一个规则，并为他产生一个父队列。父规则可以被嵌套，一个父规则可以包含另一个父规则，此外对于父规则的嵌套也没有强制限制。
+
+父规则被视为顶层的规则，因此具有与放置定义中任何其他规则相同的参数和需求。例外的情况是，在「已经生成完全合格队列」的规则上再使用父规则，被认为是一个配置错误。这个错误只能发生在`fixed`型的规则上，查看规范可以得到更多细节。
+
+注意：规则的执行会沿着父规则的列表向下遍历，并首先执行列表中的最后一条。代表最后一条父规则将会直接产生在根部，详见示例。
+
+带有`parent`参数的简易yaml范例：
+```yaml
+placementrules:
+ - name: <放置规则的名称>
+ parent:
+ name: <父规则的名称>
+```
+预设值中没有parent参数。
+
+### Filter 参数
+通过`filter`参数的定义，能过滤掉适用的用户来进行配置。过滤器是一个复杂的配置組件。
+
+用户和群组可以被配置为两种类别：
+* 正则表达式
+* 用户或群组的列表
+
+如果用户或群组在yaml中的条目超过一个，则就会被视为一个用户列表或群组列表。列表中重复的条目会被忽略，不会引起错误。依据其他列表元素来使用正则表达式是不被允许的。
+
+用户和群组名称遵循标准的Linux 用户和群组惯例，对于用户名来说：
+* 从一个字母作为开头：a-z 或 A-Z
+* 后面跟着0或更多个字符：a-z, A-Z, 0-9 或 _ . @ -
+* 最后一个字符可以式$
+
+对于群组名来说：
+* 从一个字母作为开头：a-z 或 A-Z
+* 后面跟着0或更多个字符：a-z, A-Z, 0-9 或 _ -
+
+如果列表中正好有一个条目，他可以是单个用户、群组或正则表达式。当一个条目包含一个在用户或群组中不允许的字符时，该条目会被认为是一个正则表达式。正则表达式必须按照规定进行编译。一个不能编译的正则表达式将会被忽略。
+
+此外针对群组的正则表达式中：每次都是针对一个组进行匹配，而不是针对组的列表。
+
+带有 `filter`参数的简易yaml范例：
+```yaml
+filter:
+ type: deny
+ users:
+ - <user name or regexp>
+ - <user name>
+ groups:
+ - <group name or regexp>
+ - <group name>
+```
+预设值中没有filter参数。
+
+### Value 参数
+这是一个通用值，用来传递给规则以实现或改变其行为。该值被用来与[fixed](#fixed-rule)和[tag](#tag-rule)型的规则一起使用。此外`value`是以字串型式存在的单一值，也不会被系统解释或干扰。
+
+带有 `value`参数的简易yaml范例：
+```yaml
+placementrules:
+ - name: <放置规则的名称>
+ value: "any string"
+```
+预设值中没有value参数。
+
+## 准入控制列表
+准入控制列表没有在规则中定义，但它们影响放置策略的结果。有两种准入控制列表可以被定义到队列上：
+1. 提交ACL: `submitacl`
+2. 管理ACL: `adminacl`
+
+如果队列的ACL允许任何ACL提交存取，则放置规则才能匹配。管理队列ACL还提供「提交准入」的功能。如果队列不存在或没有配置ACL，则将检查父队列的ACL。这种递迴的检查会重复执行，直到有ACL提供存取或根目录的ACL被检查过后。
+
+关于ACL语法的更多细节，请查阅[ACL文档](user_guide/acls.md)。
+
+## 规则
+### Provided Rule
+在配置中使用的名称：*provided*
+
+提供在提交应用时所指定的队列。本规则的行为是─如果队列不完全合格，则完全限定由「应用程序提供的队列」作为放置的队列。如果设置了一个父规则，并且在应用程序提交中提供的队列是完全合格的，那麽父规则就不会被执行。
+
+支持的参数：
+* create
+* parent
+* filter
+
+举例：如果用户名下不存在队列，则用户传入的队列会被创建。
+```yaml
+placementrules:
+ - name: provided
+ create: true
+ parent:
+ name: user
+ create: true
+```
+当用户 `developer` 向应用程式提交请求，且应用程式要求的队列名称为：`my_special_queue`。<br/>
+结果：`root.developer.my_special_queue`(父规则将设置用户名称)。
+
+当用户 `developer` 向应用程式提交请求，且应用程式要求的队列名称为：`root.dev_queue`。<br/>
+结果：`root.dev_queue`(父规则将被忽视)。
+
+### User Name Rule
+在配置中使用的名称：*user*
+
+提供一个基于用户名的队列，而该用户名为所提交的应用程序的一部分。
+
+支持的参数：
+* create
+* parent
+* filter
+
+举例：提交一个基于用户名的队列，如果队列不存在，不要创建队列。
+```yaml
+placementrules:
+ - name: user
+ create: false
+```
+
+当用户`finance.test`提交了一个应用程式，此外对应的队列也存在。<br/>
+结果： `root.finance_dot_test`(注意，「点」被替换了)。
+
+当用户`developer`提交了一个应用程式，但对映的队列不存在。<br/>
+结果：失败，执行下一条规则。
+
+### Fixed Rule
+在配置中使用的名称：*fixed*
+
+回传一个队列，其依据规则参数的值作为名称，配置的值必须是一个合法的队列名称或层次结构。该队列名称不一定需要完全合格。名称中的层次结构使用「一个点(.)」作为层次结构中不同级别的分隔符。只有当配置的队列不存在且`create`标籤未设置时，`fixed`规则才会失败，因为他始终新增一个配置的队列。
+
+支持的参数：
+* value(reuqired)
+* create
+* parent
+* filter
+
+举例：因为总是会回传一个队列，若没有设置`create`标籤，则要在配置中将队列定义为子队列。
+```yaml
+placementrules:
+ - name: fixed
+ value: last_resort
+```
+
+当用户 `developer`提交请求，且在应用程式中设定的队列为：`my_special_queue` 。<br/>
+结果：`root.last_resort`。
+
+### Tag Rule
+在配置中使用的名称：*tag*
+
+从应用程式的标籤中检索队列名称。检查`tag`的值(value)，并在规则中使用该值进行配置。若`tag`规则没有包含任何值，则代表配置错误，但是一个应用程式不一定要设置该值。
+
+如果应用程序上没有设置对应的`tag`，则规则失败。如果从应用程序回传的`tag` value是一个完全限定的队列名称，则父规则(如果已配置)将不会执行。
+
+支持的参数：
+* value(reuqired)
+* create
+* parent
+* filter
+
+举例：根据kubernetes命名空间放置一个应用程序，该命名空间在提交时自动在应用程序中设置。
+```yaml
+placementrules:
+ - name: tag
+ value: namespace
+ create: true
+```
+
+用户`developer`在命名空间`default`，提交基于kubernetes的应用程序请求，且在应用程是中设定的队列为：`my_pecial_queue`。<br/>
+结果：`root.default`。
+
+用户`developer`在命名空间`testing`，提交基于kubernetes的应用程序请求，且在应用程是中设定的队列为：`my_pecial_queue`。<br/>
+结果：`root.testing`。
+
+用户提交非基于kubernetes的应用程序请求。<br/>
+结果：失败，执行下一条规则。
+
+## 复杂的例子
+在这个复杂的例子中，我们串连了三个规则：
+
+1. 一个`user`规则，其父规则标籤使用kubernetes命名空间，且仅供`dev`群组内的用户。
+2. 一个`tag`规则，使用kubernetes命名空间，其`parent`规则固定使用已存在的队列─ `root.namespaces`。
+3. 一个`fixed`规则，将所有到达这个点的应用程序都放在`root.default`队列中。
+
+举例：
+```yaml
+placementrules:
+ - name: user
+ create: true
+ filter:
+ type: allow
+ groups:
+ - dev*
+ parent:
+ - name: tag
+ value: namespace
+ - name: tag
+ value: namespace
+ create: true
+ parent:
+ - name: fixed
+ value: root.namespaces
+ filter:
+ type: allow
+ users:
+ - john
+ - name: fixed
+ value: root.default
+```
+用户`john`在命名空间testing中提交基于kubernetes应用程序的请求。<br/>
+结果：`root.namespaces.testing`(在规则2中匹配)。
+
+用户`sarah`在命名空间`newapp`中提交基于kubernetes应用程序的请求，组员为`sarah`, `test_app`, `dev_app`。<br/>
+结果：`root.newapp.sarah`(在规则1中匹配)。
+
+用户bob在命名空间`testapp`中提交基于kubernetes应用程序的请求，组别成员为`bob`。<br/>
+结果：`root.default`(在规则3中匹配)。
+<br/>
+在第二个例子中，我们使用了两条规则。
+
+1. 一个`fixed`规则，将所有东西放在`root.production`队列中。
+2. 一个`user`规则，以及设置 `create` 标籤。
+
+但在这个例子中，我们在`root.production`的队列上设置了ACL，只允许两个特定的用户使用这个队列。因此，即使规则匹配，除非是`john`或`bob`，否则应用程式将不会被放在`production`队列中。所有其他用户将匹配第二条规则并使用它们自己的队列，如果队列不存在，就会创建。
+
+```yaml
+partitions:
+ - name: default
+ queues:
+ - name: production
+ submitacl: john,bob
+ placementrules:
+ - name: fixed
+ value: root.production
+ - name: user
+ create: true
+```
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/prometheus.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/prometheus.md
new file mode 100644
index 0000000000..4ded82ff1f
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/prometheus.md
@@ -0,0 +1,82 @@
+---
+id: prometheus
+title: Setting Prometheus
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+YuniKorn exposes its scheduling metrics via Prometheus. Thus, we need to set up a Prometheus server to collect these metrics.
+
+If you don't know what metric can be used, you can use [REST API](../api/scheduler.md#指标(Metrics)).
+
+### 1. **Download Prometheus release**
+
+```bash
+wget https://github.com/prometheus/prometheus/releases/download/v2.30.3/prometheus-2.30.3.linux-amd64.tar.gz
+```
+
+```bash
+tar xvfz prometheus-*.tar.gz
+cd prometheus-*
+```
+
+### 2. **Configure prometheus.yml**
+
+Prometheus collects metrics from *targets* by scraping metrics HTTP endpoints.
+
+```yaml
+global:
+ scrape_interval: 3s
+ evaluation_interval: 15s
+
+scrape_configs:
+ - job_name: 'yunikorn'
+ scrape_interval: 1s
+ metrics_path: '/ws/v1/metrics'
+ static_configs:
+ - targets: ['localhost:9080']
+ # 9080 is internal port, need port forward or modify 9080 to service's port
+```
+
+### 3. Start port-forward
+
+Port forwarding for the core's web service on the standard port can be turned on via:
+
+```bash
+kubectl port-forward svc/yunikorn-service 9080:9080 -n yunikorn
+```
+
+`9080`is the default port for core's web service.
+
+### 4. Execute prometheus
+
+```bash
+./prometheus --config.file=prometheus.yml
+```
+
+
+
+### 5. Access the Prometheus UI
+
+You should be able to browse to a status page at [localhost:9090](http://localhost:9090/). Give it a couple of seconds to collect data about itself from its own HTTP metrics endpoint.
+
+
+
+You can also verify that Prometheus is serving metrics by navigating to its metrics endpoint:[localhost:9090/metrics](http://localhost:9090/metrics)
\ No newline at end of file
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/queue_config.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/queue_config.md
new file mode 100644
index 0000000000..c8a140eba3
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/queue_config.md
@@ -0,0 +1,382 @@
+---
+id: queue_config
+title: 分区和队列配置
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+队列配置基础在[配置设计文档](design/scheduler_configuration.md)中有描述。
+
+本文档提供通用队列配置。
+队列配置引用了[访问控制列表](user_guide/acls.md)和[放置规则](user_guide/placement_rules.md)文档。
+
+本文档通过示例说明如何为调度程序创建分区和队列配置。
+
+调度程序依靠shim可靠地提供用户信息作为应用程序提交的一部分。
+当前shim使用[用户和组解析](usergroup_resolution)中提供的方法识别用户和用户所属的组。
+
+## 配置
+此处描述的调度器的配置文件仅提供分区和队列的配置。
+
+默认情况下，我们在部署中使用`queues.yaml`文件。
+文件名可以通过命令行更改调度器的`policyGroup`标志。
+更改文件名后必须对部署细节进行相应的更改，可以是`configmap`或包含在docker容器中的文件。
+配置的示例文件位于yunikorn-core的[queues.yaml](https://github.com/apache/yunikorn-core/blob/master/config/queues.yaml).
+
+## 分区
+分区(partitions)是调度器配置的最高级别。
+在配置中可以定义多个分区。
+
+配置中分区定义的基本结构如下：
+```yaml
+partitions:
+ - name: <第一个分区的名称>
+ - name: <第二个分区的名称>
+```
+分区的默认名称是`default`。
+分区定义包含特定shim相应调度器的完整配置。
+每个shim都使用自己独特的分区。
+
+分区必须至少需要定义以下键：
+* name
+* [queues](#队列)
+
+队列配置会在分区结束后介绍。
+
+可以选择为分区定义以下键：
+* [placementrules](#放置规则)
+* [statedumpfilepath](#状态转储文件路径)
+* [limits](#限制)
+* nodesortpolicy
+* preemption
+
+放置规则和限制在各自的章节中解释。
+
+`nodesortpolicy`定义节点为分区排序的方式。
+有关可以使用的节点排序策略值的详细信息，请参阅[排序策略](user_guide/sorting_policies.md#node-sorting)文档。
+
+抢占键目前只能有一个子键： _enabled_。
+这个布林值定义了整个分区的抢占行为。
+
+_enabled_的默认值为_false_。
+_enabled_的允许值：_true_或_false_，任何其他值都会导致解析错误。
+
+下方的示例中，`partition` yaml条目是带有_preemption_标志集和_fair_的`nodesortpolicy`。
+```yaml
+partitions:
+ - name: <分区名称>
+ nodesortpolicy: fair
+ preemption:
+ enabled: true
+```
+备注：
+目前，Kubernetes独特的shim不支持除`default`分区之外的任何其他分区。
+这已被记录为shim的[jira](https://issues.apache.org/jira/browse/YUNIKORN-22)。
+
+### 队列
+
+YuniKorn通过利用资源队列来管理资源。
+资源队列(queues)具有以下特征：
+- 队列可以有**层次**结构
+- 每个队列都可以预设**最小/最大容量**，其中最小容量定义保证资源，最大容量定义资源限制(所谓的资源配额)
+- 任务必须在某个`leaf`队列下运行
+- 队列可以是**静态**(从配置文件加载)或**动态**(由YuniKorn内部管理)
+- 队列级别的**资源公平**是由调度器强制执行
+- 作业只能在特定队列下运行
+
+:::info
+YuniKorn队列与[Kubernetes命名空间](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)的区别：
+Kubernetes命名空间提供了Kubernetes资源的范围，包括安全环境(即谁可以访问对象)，以及定义[资源配额](https://kubernetes.io/docs/concepts/policy/resource-quotas/)时的资源边界(即对象可以使用多少资源)。
+另一方面，YuniKorn队列仅使用一组作业可以使用多少资源，以及以何种顺序使用。
+YuniKorn队列在考虑资源公平性、作业排序等方面提供了更细粒度的多租户资源共享控制。
+在大多数情况下，YuniKorn队列可用于替代命名空间资源配额，以提供更多的调度特性。
+:::
+
+_queues_条目是主要的配置元素，它为队列定义了层次结构。
+
+它可以定义一个`root`队列，但它不是必需的元素。
+如果未定义`root`队列，配置解析将插入root队列以保持一致性。
+以下因素会触发root队列的插入：
+* 如果配置在顶层定义了多个队列，则会插入一个根队列。
+* 如果在顶层只定义了一个队列并且它不被称为`root`，则插入一个root队列。
+
+定义的一个或多个队列将成为插入的`root`队列的子队列。
+
+带有子队列的基本`queue` yaml条目：
+```yaml
+queues:
+- name: <队列名称>
+ queues:
+ - name: <队列名称>
+```
+
+队列支持的参数：
+* name
+* parent
+* queues
+* maxapplications
+* properties
+* adminacl
+* submitacl
+* [resources](#资源)
+* [limits](#限制)
+
+每个队列都必须有一个_name_并且队列的名称在定义队列的同一级别上必须是唯一的。
+由于队列结构是完全层次化的，层次结构中不同点的队列可能具有相同的名称。
+例如：队列结构`root.testqueue`和`root.parent.testqueue`是一个有效的结构。
+需注意的是，队列不能包含点“.”字符，因为该字符用于分隔层次结构中的队列。
+如果名称对于配置中的队列不是唯一的，或者名称包含一个点，则会生成解析错误并拒绝配置。
+
+依队列的类型是否于队列有子模板队列和子队列的事实，结构中的队列将自动获得分配的类型。
+队列类型有两种：
+* parent
+* leaf
+
+应用只能分配给_leaf_队列。
+在配置中，队列具有子模板队列或子队列将自动成为_parent_队列。
+如果队列在配置中没有子队列，则该队列是_leaf_队列，除非该队列`parent`参数设置为_true_。
+尝试覆盖配置中的_parent_队列类型将导致配置解析错误。
+
+parent队列的子队列在`queues`条目下定义。
+`queues`条目是队列级别的递归条目，它使用完全相同的参数集。
+_maxapplications_属性是一个大于 1 的整数值，它允许您限制队列中正在运行的应用的数量。
+不允许为_maxapplications_指定零，因为它会阻止队列中应用的任何分配。
+_子_队列的_maxapplications_值必须小于或等于_parent_队列的值。
+`properties`参数是一个简单的键值对列表，并为队列提供一组简单的属性。其中的键或值没有限制，任何东西都是允许的。
+目前，属性列表仅在调度器中用于定义leaf队列的[排序顺序](user_guide/sorting_policies.md#application-sorting)。
+在未来的扩展中，添加比如打开或关闭队列抢占或其他排序策略的选项，让使用相同的属性构造而无需更改配置。
+
+通过`adminacl`设置对队列的访问权限以进行管理操作，并通过`submitacl`条目提交应用。
+访问控制列表(ACLs)的描述可见[访问控制列表(ACLs)](user_guide/acls.md)文档。
+
+队列资源限制是通过`resources`参数设置。
+用户和群组的限制是通过`limits`参数设置。
+由于这两个条目都是复杂的配置条目，因此它们在下面的[resources](#资源)和[limits](#限制)中有相应解释。
+
+以下示例配置是`root.namespaces`队列作为具有限制的_parent_队列：
+```yaml
+partitions:
+ - name: default
+ queues:
+ - name: namespaces
+ parent: true
+ maxapplications: 12
+ resources:
+ guaranteed:
+ {memory: 1G, vcore: 10}
+ max:
+ {memory: 10G, vcore: 100}
+ queues:
+ - name: level1
+ maxapplications: 8
+ resources:
+ guaranteed:
+ {memory: 0.5G, vcore: 5}
+ max:
+ {memory: 5G, vcore: 50}
+```
+
+### 放置规则
+
+放置规则(placement rules)在[放置规则](user_guide/placement_rules.md)文档中有相关定义和记录。
+
+每个分区只能定义一组放置规则。
+如果没有定义规则，则放置管理器不会启动。
+此外，在提交应用时，*必须*为每个应用设置一个队列。
+
+### 状态转储文件路径
+
+状态转储文件路径(Statedump filepath)定义YuniKorn状态转储的输出文件并且它可以在分区级别上设置。
+如果设置转储文件路径，该字段的值可以是相对路径或绝对路径(此处相对路径是基于工作目录)。
+如果YuniKorn调度器没有足够的权限在指定路径创建状态转储文件，它将无法启动状态转储的功能。
+
+```yaml
+statedumpfilepath: <path/to/statedump/file>
+```
+如果上面的键没有在分区配置中指定，它的默认值为`yunikorn-state.txt`。
+需注意的是，如果键在多个分区中指定，则其第一次出现的值优先。
+
+状态转储文件也有一个固定的循环策略。
+目前，每个状态转储文件的容量为10MB，最多可以有10个这样的文件。
+当前正在写入的状态转储文件将始终是上面配置的值或默认的`yunikorn-state.txt`。
+当达到文件大小限制时，日志旋转器(`lumberjack`)将通过在文件前加上时间戳来修改文件，并创建一个具有相同的无前缀名称的新文件来写入状态转储。
+如果达到状态转储文件的最大数量，轮换策略将删除根据标记时间戳的最旧文件。
+
+### 限制
+限制(limits)为分区或队列定义一组限制对象，以及它可以在分区或任何级别的队列上设置。
+```yaml
+limits:
+ - limit: <描述>
+ - limit: <描述>
+```
+
+限制对象是一个复杂的配置对象，它为一组用户和/或群组定义一个限制。
+多个独立的限制可以设置为队列或分区上一个`limits`条目的一部分。
+不属于限制设置的用户和/或群组将不受限制。
+
+limits条目的示例：
+```yaml
+limits:
+ - limit: <描述>
+ users:
+ - <用户名或"*">
+ - <用户名>
+ groups:
+ - <群组名称或"*">
+ - <群组名称>
+ maxapplications: <1..最大值>
+ maxresources:
+ <资源名称1>: <0..最大值>[后缀]
+ <资源名称2>: <0..最大值>[后缀]
+```
+
+队列限制的情况下，应用递归限制。
+这意味着对`root`队列的限制是集群中用户或群组的总体限制。
+因此，`root`队列限制也等同于`partition`限制。
+
+limits参数：
+* limit
+* users
+* groups
+* maxapplications
+* maxresources
+
+_limit_参数是limits条目的可选描述。
+除了使配置易于理解和可读之外，它不用于任何其他用途。
+
+可以配置的_users_和_groups_可以是以下两种类型之一：
+* 一个星号字符 "*"
+* users或groups的列表。
+
+如果users或groups的条目包含超过1个条目，则它始终被视为users或groups的列表。
+星号字符“*”为通配符，匹配所有用户或群组。
+不允许在其他列表元素旁边指定星号字符。
+列表中的重复条目将被忽略，并不会导致解析错误。
+
+_maxapplications_是一个无符号整数值。
+当_maxapplications_大于1，它允许您限制为配置的用户或群组运行的应用的数量。
+不允许指定_maxapplications_为0，因为_maxapplications_为0时，隐含拒绝任何访问。
+拒绝访问的规范应交由ACL条目处理。
+
+_maxresources_参数可用于指定一个或多个资源的限制。
+_maxresources_使用与队列的[resources](#资源)参数相同的语法。
+未在列表中指定的资源不受限制。
+资源限制可以设置为 0，这可以防止用户或群组请求指定的资源，即使队列或分区具有可用的特定资源也是如此。
+不允许将总体资源限制指定为零，换言之，这意味着限制中指定的至少一个资源必须大于零。
+如果资源在队列上不可用，则应使用队列定义上的最大资源。
+指定一个实际上为零的限制，_maxapplications_ 为零并且所有资源限制为零，这是不允许的，并且会导致解析错误。
+
+每个用户或群组都有一个限制，它*不是*所有用户或群组的组合限制。
+
+举个例子：
+```yaml
+limit: "example entry"
+maxapplications: 10
+users:
+- sue
+- bob
+```
+在这种情况下，用户`sue`和`bob`都被允许运行10个应用。
+
+### 资源
+队列的resources条目可以为队列设置_guaranteed_和/或_maximum_资源，yunikorn会递归地检查资源限制。
+leaf队列的资源使用量是为该队列分配的所有资源的总和。
+parent队列的资源使用量是该parent队列下面所有队列，leaf和parent队列的资源使用量的总和。
+
+root队列没有_guaranteed_的资源设置。
+root队列的_max_资源限制自动等于集群大小。
+如果root队列设置了任何限制，则会发生解析错误。
+leaf队列在定义时不能设置任何资源限制。
+
+配置后的_max_资源对可以在任何时间点分配给队列的所有分配的大小进行了硬性限制。
+_max_资源可以设置为0，这使得资源对队列不可用。
+_guaranteed_资源用于计算队列份额和分配期间，它用作决定将分配分配给哪个队列的输入之一。
+抢占使用队列的_guaranteed_资源作为队列不能低于的基础。
+
+基本的`resources` yaml条目：
+```yaml
+resources:
+ guaranteed:
+ <资源名称1>: <0..最大值>[后缀]
+ <资源名称2>: <0..最大值>[后缀]
+ max:
+ <资源名称1>: <0..最大值>[后缀]
+ <资源名称2>: <0..最大值>[后缀]
+```
+列表中未指定的资源不受限制，对于最大(max)资源，或在保证(guaranteed)资源的情况下保证。
+
+可以为资源数量指定一个可选的后缀。
+有效的国际单位制后缀是`k`、`M`、`G`、`T`、`P` 和 `E`，用于10的幂，以及`Ki`、`Mi`、`Gi`、`Ti`、 `Pi`和`Ei`表示2的幂。
+此外，`vcore`类型的资源可能带有后缀`m`以表示millicores。 例如，`500m`是vcore的50%。
+默认情况下，`memory`类型的单位以byte为单位进行解释。
+所有其他资源类型都没有指定的基本单位。
+
+注意，以上单位行为从yunikorn 1.0开始有效
+以前的版本将`memory`解释为1000000(百万)bytes的单位，将`vcore`解释为millicores。
+
+### 子模板
+
+子模板(child template)可以在父类型队列的队列层次结构中的任何级别来定义。
+parent队列可以提供一个模板来定义它下面的动态leaf队列的行为。
+如果parent队列定义了子模板，则没有子模板的parent队列会从其parent队列继承子模板。
+
+模板中支持的配置如下所示。
+1. application sort policy
+2. max resources
+3. guaranteed resources
+4. max applications
+
+举个例子：
+```yaml
+ partitions:
+ - name: default
+ placementrules:
+ - name: provided
+ create: true
+ queues:
+ - name: root
+ submitacl: '*'
+ childtemplate:
+ maxapplications: 10
+ properties:
+ application.sort.policy: stateaware
+ resources:
+ guaranteed:
+ vcore: 1
+ memory: 1G
+ max:
+ vcore: 20
+ memory: 600G
+ queues:
+ - name: parent
+ parent: true
+ childtemplate:
+ resources:
+ max:
+ vcore: 21
+ memory: 610G
+ - name: notemplate
+ parent: true
+```
+在这种情况下，`root.parent.sales`将直接使用parent队列`root.parent`的子模板。
+相比之下，`root.notemplate.sales`将使用在队列`root`上设置的子模板，因为其parent队列 `root.notemplate` 从队列`root`继承了子模板。
+
+[已弃用] 如果您的集群依赖于动态叶队列可以从父级继承`application.sort.policy`的旧行为(由[YUNIKORN-195](https://issues.apache.org/jira/browse/YUNIKORN-195)引入)，请迁移到模板。
+旧的行为将在未来的版本中被删除。
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/resource_quota_mgmt.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/resource_quota_mgmt.md
new file mode 100644
index 0000000000..6d0811a3a3
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/resource_quota_mgmt.md
@@ -0,0 +1,336 @@
+---
+id: resource_quota_management
+title: 资源配额管理
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+## 配额配置和规则
+与 Kubernetes 提供的简单命名空间资源配额相比，YuniKorn 可以提供一个更细化的资源配额管理设置。
+
+在 Kubernetes 上，一个 pod 在提交时必须符合命名空间的配额。
+如果 pod 不适合命名空间配额， pod 就会被拒绝。
+客户端必须实现重试机制，如果它需要该 pod 被调度，就重新提交该 pod 。
+
+与 Kubernetes 中的配额相反， YuniKorn 不在提交时强制执行配额，而只对主动消耗的资源执行配额。
+解释一下区别：当使用 YuniKorn 执行配额时，提交给 Kubernetes 的新 pod 总是被接受。
+ Yunikorn 将对 pod 进行排队，而不将排队的 pod 的资源计入已消耗的配额。
+当 YuniKorn 试图调度 pod 时，它会在调度时检查 pod 是否符合为 pod 所分配的队列配置的配额。
+如果这时 pod 不符合配额， pod 就会被跳过，不计入资源消耗。
+这意味着，在一个 pod 的调度尝试成功之前，一个 pod 在 YuniKorn 配额系统中不消耗资源。
+
+YuniKorn 中的资源配额与队列及其在队列层次结构中的位置有关。
+队列结构的基础，即 `root` 队列，不允许设置配额，因为它反映了集群的当前规模。
+节点的增加和删除会自动更新 `root` 队列的配额。
+
+除了 `root` 队列，配额可以设置，并在层次结构的任何一点上执行。
+每个队列都可以有一个配额设置。配额在整个层次结构中是递归执行的。
+这意味着子队列使用的资源不能超过父队列的**配置的**配额。
+因此，在子队列上设置大于其父队列配额的配额不会有任何影响，并被作为配置错误处理。
+
+在层次结构中，还有一些需要考虑的规则。
+如果一个父队列有多个子队列，所有子队列的**使用量之和不能超过父队列的**配置配额。
+然而，从配置的角度来看，这并不意味着所有子队的**配置的**配额之和必须小于父队的配额。
+
+
+
+举个例子，`root.parent` 队列的配额是 900。
+它包含三个子队列，其中两个有配额设置。
+`root.parent.child1` 没有设置配额，因此将被限制在 `root.parent` 的配额内。
+另外两个队列 `root.parent.child2` 和 `root.parent.child3` 各设置了 750 的配额。
+在正常运行期间，3 个子队列的总使用量将是 900。
+在每个子队列中运行的应用程序，每个都有超过 1000 的需求。
+
+在这种情况下，分配可能是以下任何一种：
+* 所有 900 个都被 `child1` 队列使用
+* 平均分布在 3 个队列中（每个队列 300 个）。
+* `child2` 最大使用 750，剩下的 150 由 `child3` 使用。
+
+队列之间的确切分布将是波动的，取决于调度策略。
+
+## 转换 Kubernetes 资源和配额
+
+对pod的资源支持仅限于作为_需求_规范的一部分而指定的资源：
+
+* _cpu_ 被映射到 _vcore_，其值为 milli cpu。
+* _memory_ 被映射到 _memory_，其值为MB（1 MB = 10^6 B = 1 000 000 B）。
+* 所有其他资源都按照规定进行映射。
+
+支持 [Kubernetes文档](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) 中提到的扩展资源。
+
+有一个单一容器的 pod 例子：
+```yaml
+apiVersion: v1
+kind: Pod
+spec:
+ containers:
+ - name: container-1
+ resources:
+ requests:
+ cpu: "250m"
+ memory: "1Gi"
+ hugepages-1Gi: "1"
+```
+上述规范将在 YuniKorn 中为调度设置 pod 资源请求：
+* _vcore_ -> 250m
+* _memory_ -> 1073741824
+* _hugepages-1Gi_ -> 1
+
+两个备注：
+多个容器规格将被自动汇总为一个总的 pod 资源请求。所有的内存都是以字节为单位报告的。
+
+在为队列使用静态队列定义的情况下，对配额中可指定的资源类型没有限制。
+作为自动队列创建的一部分，命名空间上的配额注释被限制在相当于 _cpu_ 和 _memory_ 的资源。
+参见下面的 [设置](#Namespace-quota)，了解命名空间上的配额注释。
+
+## Kubernetes 和 YuniKorn 配额互动
+建议关闭而不是配置 Kubernetes 命名空间配额。
+只使用 YuniKorn 队列配额提供了一个更灵活的设置，并允许对工作负载进行排队。
+
+在同时开启 YuniKorn 和 Kubernetes 配额的设置中，考虑以下几点：
+* 需要维护两个独立的配置。
+ 这增加了维护负担，以及配置错误的可能性。
+* 两个配额都会被强制执行。
+
+开启这两个配额可能会导致意外的行为。
+主要问题是，Kubernetes 命名空间配额在提交时被强制执行。
+有三种配额配置的组合是可能的。
+当与 YuniKorn 配额结合使用时，这3种组合可能有两种效果。
+
+1. 两种配额都是_平等的_：工作负载将不被排队，可以使用全部配置的配额。
+ - 最大使用量和排队将被限制在设定的配额内
+2. Kubernetes 配额比 YuniKorn 低：YuniKorn 配额将永远不会达到，工作负载将不会被排队。
+ - 最大使用量将被限制在 Kubernetes 的配额内。
+3. Kubernetes 配额比 YuniKorn 高： YuniKorn 将把使用量限制在 YuniKorn 中设置的配额。
+ Kubernetes 配额将在提交时强制执行，从而为可以在 YuniKorn 配额之上排队的工作负载设置限制。
+ - 最大使用量将被限制在 YuniKorn 的配额内。
+ - 工作负载的排队将被限制在 Kubernetes 配额内。
+
+:::note
+下面的配置例子只是为了演示需要的格式
+来创建一个设置了配额的队列层次结构。
+:::
+
+## 静态队列定义
+
+### 目标
+一个预先配置好的具有最大和保证容量的队列层次结构。
+用户只能向叶子队列提交申请。
+这种方法管理每个队列的资源容量，适用于队列不经常变化的情况。
+
+### 配置
+将以下配置应用于 YuniKorn 的 configmap，以：
+* 在 `root` 下设置 3 个队列
+* 每个队列都有一个特定的保证和最大容量
+* 任何人都可以向任何队列提交
+
+```yaml
+partitions:
+ - name: default
+ queues:
+ - name: root
+ submitacl: '*'
+ queues:
+ - name: advertisement
+ resources:
+ guaranteed:
+ memory: 500G
+ vcore: 50
+ max:
+ memory: 800G
+ vcore: 80
+ - name: search
+ resources:
+ guaranteed:
+ memory: 400G
+ vcore: 40
+ max:
+ memory: 600G
+ vcore: 60
+ - name: sandbox
+ resources:
+ guaranteed:
+ memory: 100G
+ vcore: 10
+ max:
+ memory: 100G
+ vcore: 10
+```
+
+### 运行一个工作负载
+为了在特定队列中运行应用程序，你需要在所有 pod 规格中设置以下标签。
+所有具有相同 `applicationID` 标签的 pod 被认为是一个应用程序。
+在下面的例子中，应用程序 `my-test-app` 将在队列 `root.sandbox` 中运行：
+
+```yaml
+labels:
+ app: my-test-app
+ applicationId: "my-test-app-01"
+ queue: root.sandbox
+```
+
+## 名称空间到队列的映射
+
+### 目标
+自动将Kubernetes的 `namespace` 映射到 YuniKorn 的队列。
+用户在 Kubernetes 中创建所需的命名空间。
+YuniKorn k8s shim 和核心调度器会自动传递所需信息，并将命名空间映射到队列中，如果队列不存在，则创建队列。
+资源配额将由 YuniKorn 管理，而不是使用 Kubernetes 命名空间配额。
+这确实需要按照下面的 [设置](#Namespace-quota) 设置命名空间，不需要 Kubernetes 配额的执行和标签。
+
+### 配置
+将以下配置应用于 YuniKorn 的配置图：
+
+```yaml
+partitions:
+ - name: default
+ placementrules:
+ - name: tag
+ value: namespace
+ create: true
+ queues:
+ - name: root
+ submitacl: '*'
+ properties:
+ application.sort.policy: stateaware
+```
+
+该配置根据 `tag` 规则放置一个应用程序。
+选择的标签是 `namespace` 标签，它由 k8s shim 自动添加到所有被创建的应用程序中。
+`create` 标志被设置为 `true`，如果队列不存在，它将触发与命名空间同名的队列的创建。
+
+自动创建的子队列中的应用程序将根据父队列上设置的排序策略进行排序。
+在这种情况下，属性 `application.sort.policy` 在此配置中被设置为 `stateaware` 。
+这是一个适用于批处理作业的简单应用排序策略，你可以找到更多的文件 [这里](sorting_policies.md#StateAwarePolicy)。
+
+你可以在安装过程中使用 helm charts 来改变配置，通过覆盖在
+[helm chart template](https://github.com/apache/yunikorn-release/blob/master/helm-charts/yunikorn/values.yaml#L71-L81)。
+
+### 命名空间配额
+Kubernetes 中的命名空间包含配额信息。
+如果在命名空间上设置了配额，Kubernetes 将自动执行该配额。
+在 YuniKorn 被用于执行配额的情况下，必须在命名空间上设置配额。
+
+为了允许在命名空间上指定配额，应在命名空间对象中设置以下注释：
+
+```yaml
+yunikorn.apache.org/namespace.quota: "{\"cpu\": \"64\", \"memory\": \"100G\", \"nvidia.com/gpu\": \"1\"}"
+```
+YuniKorn 将解析这些注释，并设置映射到该命名空间的队列的最大容量。
+指定的值遵循标准的 Kubernetes 格式和单位规范。
+注释值必须是一个符合 json 的字符串。确保双引号被正确转义，以免造成任何问题。
+
+上面的例子将把映射到注释命名空间的队列限制在 64 个 CPU、100GB 内存和 1 个 `nvidia.com/gpu`。
+
+[已废弃]
+以下注释已被废弃，并将在下一个主要版本中被删除。
+它们只支持映射内存和cpu，不支持其他资源类型。
+```yaml
+yunikorn.apache.org/namespace.max.cpu: "64"
+yunikorn.apache.org/namespace.max.memory: "100Gi"
+```
+废弃注释的例子将把队列配额设置为 64 个 CPU 和 100GB 内存。
+
+### 运行一个工作负载
+
+应用程序，以及作为应用程序一部分的 pod，可以在没有特定标签的情况下提交。
+YuniKorn 将自动添加所需的标签。
+如果需要，配置的放置规则将创建队列，并将应用程序添加到队列中。
+
+例如，如果一个应用程序被提交到命名空间 `development` ，那么该应用程序将在 `root.development` 队列中运行。
+
+## 命名空间的父队列映射
+
+### 目标
+尽管使用 `namespace` 标签的标签放置规则能够将应用程序放置在队列中，但这在所有设置中可能是不够的。
+在某些情况下，例如多租户，命名空间需要被归为一组。
+管理员可以对命名空间进行注释，如果设置了放置规则，可以根据多个注释动态放置应用程序。
+YuniKorn 不能也不会将一个命名空间的所有注解添加到一个应用程序。
+
+为了帮助支持这种分组情况，可以在命名空间上标记一个父队列。
+
+### 配置
+这个功能的配置由两部分组成：
+1. 映射规则
+1. 命名空间注释
+
+首先，我们在 YuniKorn 的 configmap 上设置以下配置：
+
+```yaml
+partitions:
+ - name: default
+ placementrules:
+ - name: tag
+ value: namespace
+ create: true
+ parent:
+ name: tag
+ value: namespace.parentqueue
+ queues:
+ - name: root
+ queues:
+ - name: production
+ parent: true
+ - name: development
+ parent: true
+```
+
+用于命名空间到队列映射的配置与 [上文](#名称空间到队列的映射) 相同。
+作为放置规则的扩展，添加了一个 `parent` 规则以支持分组。
+父级规则用于生成层次结构中的父级，或上面的队列。
+该规则使用应用程序中的标签 `namespace.parentqueue` 来生成父队列名称。
+`namespace.parentqueue` 标签由 Kubernetes shim 自动添加，但确实需要一个命名空间注释（见下文）。
+
+在给出的规则配置示例中，`create` 标志没有在父规则上设置。
+这意味着父队列必须存在于配置中，否则应用提交将失败。
+对于这个例子的配置，这意味着父队的支持值被限制为 `production` 和 `development`。
+
+不能使用任何这些映射在父队列上设置配额。
+根据前面提供的命名空间映射，与命名空间相关的配额设置在命名空间队列上，而不是父队。
+
+父队列的配额必须总是直接在配置中设置。
+这需要在父规则上将 `create` 标志设置为 `false`。
+
+### 命名空间父队列
+与命名空间名称本身相反，并与配额设置相一致，命名空间需要被注解以使用父队列映射。
+命名空间名称在 Kubernetes 中必须是唯一的，这不受此注释的影响。
+相同的注解值可以用于多个命名空间：
+```yaml
+yunikorn.apache.org/parentqueue: root.production
+```
+
+上面的例子注释将把父队列映射到现有的 `root.production` 队列。
+注意，如果需要的话，规则将完全限定名称，因此你可以省略注释中的 `root.` 部分。
+如果注释以 `root.` 开头，系统会认为这是一个完全合格的队列名称。
+
+为了使图片更完整，这里有一张图片，显示了 YuniKorn 中从 Kubernetes 命名空间到队列的映射。
+它使用了 Kubernetes 中命名空间的注释，以及映射规则的配置示例。
+`finance` 和 `sales`命名空间成为队列，归入父队列 `production` 之下。
+命名空间 `dev` 和 `test` 被放在 `development` 父队列下。
+
+
+
+### 运行一个工作负载
+应用程序，以及作为应用程序一部分的 pod，可以在没有特定标签或更改的情况下提交。
+YuniKorn 将添加标签，安置规则将做其余的事情。
+配置的放置规则将创建队列（如果需要），并将应用程序添加到队列中。
+
+由于命名空间 `finance` 被注释为示例值，并且规则已经到位。
+`finance` 命名空间的应用程序将在动态创建的 `root.production.finance` 队列中运行。
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/service_config.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/service_config.md
new file mode 100644
index 0000000000..362c1af746
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/service_config.md
@@ -0,0 +1,792 @@
+---
+id: service_config
+title: 服务配置
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+YuniKorn的官方版本是通过Helm charts部署到Kubernetes中的。YuniKorn的配置分为两部分：Helm配置和YuniKorn服务配置。
+
+## Helm 配置
+Helm配置是用于将YuniKorn部署到Kubernetes的选项。
+
+可以在YuniKorn安装期间通过Helm进行以下设置配置，可以使用Helm的命令行方式，例如`--set key=value`，也可以使用外部文件方式：`-f file.yaml`。以下示例将以YAML语法表示。
+
+### 容器镜像
+YuniKorn以一组容器镜像的形式提供。可以按照以下方式自定义其位置和拉取策略：
+
+ # 标准调度器的镜像信息
+ image:
+ repository: apache/yunikorn
+ tag: scheduler-1.2.0 # 默认取决于YuniKorn版本
+ pullPolicy: Always
+
+ # 插件调度器的镜像信息
+ pluginImage:
+ repository: apache/yunikorn
+ tag: scheduler-plugin-1.2.0 # 默认取决于YuniKorn版本
+ pullPolicy: Always
+
+ # Web UI的镜像信息
+ web:
+ image:
+ repository: apache/yunikorn
+ tag: web-1.2.0 # 默认取决于YuniKorn版本
+ pullPolicy: Always
+
+ # 准入控制器的镜像信息
+ admissionController:
+ image:
+ repository: apache/yunikorn
+ tag: admission-1.2.0 # 默认取决于YuniKorn版本
+ pullPolicy: Always
+
+### Kubernetes 配置
+
+#### affinity
+设置YuniKorn调度器Pod的亲和性。
+
+默认值： `{}`
+
+示例：
+
+ affinity:
+ nodeAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ nodeSelectorTerms:
+ - matchExpressions:
+ - key: kubernetes.io/hostname
+ operator: In
+ values:
+ - primary1
+ - primary2
+
+#### admissionController.affinity
+设置YuniKorn准入控制器Pod的亲和性。
+
+默认值： `{}`
+
+示例：
+
+ admissionController:
+ affinity:
+ nodeAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ nodeSelectorTerms:
+ - matchExpressions:
+ - key: kubernetes.io/hostname
+ operator: In
+ values:
+ - primary1
+ - primary2
+
+#### hostNetwork
+控制调度器是否应在主机网络中运行。
+
+默认值： `false`
+
+示例：
+
+ hostNetwork: true
+
+#### admissionController.hostNetwork
+控制准入控制器是否应在主机网络中运行。
+
+默认值： `true`
+
+示例：
+
+ admissionController:
+ hostNetwork: false
+
+#### imagePullSecrets
+提供提取YuniKorn镜像所需的secret。
+
+默认值： `[]`
+
+示例：
+
+ imagePullSecrets:
+ - secret1
+ - secret2
+
+#### nodeSelector
+设置用于放置YuniKorn调度器Pod的节点选择算符。
+
+默认值： `{}`
+
+示例：
+
+ nodeSelector:
+ role.node.kubernetes.io/infra: "true"
+
+#### admissionController.nodeSelector
+设置用于放置YuniKorn准入控制器Pod的节点选择算符。
+
+默认值： `{}`
+
+示例：
+
+ admissionController:
+ nodeSelector:
+ role.node.kubernetes.io/infra: "true"
+
+#### admissionController.replicaCount
+设置用于YuniKorn准入控制器的副本数。可以将其设置为大于1以实现高可用性。
+
+默认值： `1`
+
+示例：
+
+ admissionController:
+ replicaCount: 2
+
+#### serviceAccount
+为YuniKorn调度器设置备用服务账户。
+
+不建议更改此值，因为Helm会为默认用户安装基于角色的访问控制（RBAC）策略，而这对于正确的功能是必需的。
+
+默认值： `yunikorn-admin`
+
+示例：
+
+ serviceAccount: my-account
+
+#### admissionController.serviceAccount
+为YuniKorn准入控制器设置备用服务账户。
+
+不建议更改此值，因为Helm会为默认用户安装基于角色的访问控制（RBAC）策略，而这对于正确的功能是必需的。
+
+默认值： `yunikorn-admission-controller`
+
+示例：
+
+ admissionController:
+ serviceAccount: my-account
+
+#### service.type
+设置用于调度器的服务类型。
+
+默认值： `ClusterIP`
+
+示例：
+
+ service:
+ type: ClusterIP
+
+#### admissionController.service.type
+设置用于准入控制器的服务类型。
+
+默认值： `ClusterIP`
+
+示例：
+
+ admissionController:
+ service:
+ type: ClusterIP
+
+#### service.port
+设置在YuniKorn调度器服务中用于REST API的暴露端口。不建议更改此值。
+
+默认值： 9080
+
+示例：
+
+ service:
+ port: 9080
+
+#### service.portWeb
+设置在YuniKorn调度器服务中用于Web UI的暴露端口。不建议更改此值。
+
+默认值： 9889
+
+示例：
+
+ service:
+ portWeb: 9889
+
+#### tolerations
+设置用于YuniKorn调度器Pod的容忍规则。
+
+默认值： `[]`
+
+示例：
+
+ tolerations:
+ - key: *infraRoleKey
+ operator: Equal
+ value: "true"
+ effect: NoSchedule
+ - key: CriticalAddonsOnly
+ operator: Exists
+
+#### admissionController.tolerations
+设置用于YuniKorn准入控制器Pod的容忍规则。
+
+默认值： `[]`
+
+示例：
+
+ admissionController:
+ tolerations:
+ - key: *infraRoleKey
+ operator: Equal
+ value: "true"
+ effect: NoSchedule
+ - key: CriticalAddonsOnly
+ operator: Exists
+
+### 资源利用率
+可以按照以下方式自定义YuniKorn Pod所需的资源：
+
+ # 调度器容器的资源
+ resources:
+ requests:
+ cpu: 200m
+ memory: 1Gi
+ limits:
+ cpu: 4
+ memory: 2Gi
+
+ # Web UI容器的资源
+ web:
+ resources:
+ requests:
+ cpu: 100m
+ memory: 100Mi
+ limits:
+ cpu: 100m
+ memory: 500Mi
+
+ # 准入控制器的资源
+ admissionController:
+ resources:
+ requests:
+ cpu: 100m
+ memory: 500Mi
+ limits:
+ cpu: 500m
+ memory: 500mi
+
+### 自选功能
+
+#### embedAdmissionController
+控制是否启用YuniKorn准入控制器。
+
+默认值： `true`
+
+示例：
+
+ embedAdmissionController: false
+
+#### enableSchedulerPlugin
+控制是否以调度器插件模式运行YuniKorn。
+
+默认值： `false`
+
+示例：
+
+ enableSchedulerPlugin: true
+
+### YuniKorn 默认值
+
+#### yunikornDefaults
+设置将呈现到 `yunikorn-defaults` ConfigMap的条目。这可以用于在部署时预配置YuniKorn。可以在此处设置 [YuniKorn 配置](#yunikorn-配置) 中声明的任何设置。
+
+默认值： `{}`
+
+示例：
+
+ yunikornDefaults:
+ service.clusterId: yunikorn-01
+ service.policyGroup: group-01
+ group-01.yaml: |
+ partitions:
+ - name: default
+ placementrules:
+ - name: tag
+ value: namespace
+ create: true
+ queues:
+ - name: root
+ submitacl: '*'`
+
+
+### 弃用设置
+以下设置已被弃用，或在将来的 YuniKorn 版本中被删除。现在应该在 `yunikorn-configs` ConfigMap 或通过 Helm 的 `yunikornDefaults` 部分指定：
+
+| 弃用设置 | ConfigMap 替代方案 |
+| --------------------------------------- | ----------------------------------------------- |
+| operatorPlugins | service.operatorPlugins |
+| placeHolderImage | service.placeholderImage |
+| admissionController: processNamespaces | admissionController.filtering.processNamespaces |
+| admissionController: bypassNamespaces | admissionController.filtering.bypassNamespaces |
+| admissionController: labelNamespaces | admissionController.filtering.labelNamespaces |
+| admissionController: noLabelNamespaces | admissionController.filtering.noLabelNamespaces |
+| configuration | queues.yaml |
+
+以下是一個過時的例子:
+
+ operatorPlugins: general
+ placeHolderImage: registry.k8s.io/pause:3.7
+ admissionController:
+ processNamespaces: "^spark-,^mpi-"
+ bypassNamespaces: "^kube-system$"
+ labelNamespaces: "^spark-"
+ noLabelNamespaces: "^mpi-legacy-"
+ configuration: |
+ partitions:
+ - name: default
+ placementrules:
+ - name: tag
+ value: namespace
+ create: true
+ queues:
+ - name: root
+ submitacl: '*'`
+
+以下是替代示例：
+
+ yunikornDefaults:
+ service.policyGroup: queues
+ service.operatorPlugins: general
+ service.placeholderImage: registry.k8s.io/pause:3.7
+ admissionController.processNamespaces: "^spark-,^mpi-"
+ admissionController.bypassNamespaces: "^kube-system$"
+ admissionController.labelNamespaces: "^spark-"
+ admissionController.noLabelNamespaces: "^mpi-legacy-"
+ queues.yaml: |
+ partitions:
+ - name: default
+ placementrules:
+ - name: tag
+ value: namespace
+ create: true
+ queues:
+ - name: root
+ submitacl: '*'`
+
+近期，如果同时指定了被弃用的参数和替代的ConfigMap条目，则ConfigMap条目将优先生效。
+
+
+## YuniKorn 配置
+
+YuniKorn的服务配置由两个 Kubernetes ConfigMaps 控制，它们分别是在安装 YuniKorn 的命名空间中：`yunikorn-defaults` 和 `yunikorn-configs`。
+
+运行时，YuniKorn会轮询这些ConfigMaps并将它们合并以形成有效配置。如果在两个 ConfigMaps 中都存在某个设置，则 `yunikorn-configs` 中的设置将覆盖 `yunikorn-defaults` 中的设置。
+
+`yunikorn-defaults` 的目的是提供一种机制，供 Helm 配置初始的服务配置细节。它不应该被直接修改。
+
+`yunikorn-configs` ConfigMap 完全不受 Helm 管理，适用于可能随时间变化的配置，如队列配置。所有对 YuniKorn 配置的更改都应在此处进行，而不是在基础设施供应之外。
+
+### 默认 ConfigMap
+
+如果没有提供任何配置映射，或者某个选项未被指定，YuniKorn将使用此处列出的默认值：
+
+ apiVersion: v1
+ kind: ConfigMap
+ metadata:
+ name: yunikorn-configs
+ data:
+ service.clusterId: "mycluster"
+ service.policyGroup: "queues"
+ service.schedulingInterval: "1s"
+ service.volumeBindTimeout: "10s"
+ service.eventChannelCapacity: "1048576"
+ service.dispatchTimeout: "5m"
+ service.operatorPlugins: "general"
+ service.disableGangScheduling: "false"
+ service.enableConfigHotRefresh: "true"
+ service.placeholderImage: "registry.k8s.io/pause:3.7"
+ service.instanceTypeNodeLabelKey: "node.kubernetes.io/instance-type"
+ health.checkInterval: "30s"
+ log.level: "0"
+ kubernetes.qps: "1000"
+ kubernetes.burst: "1000"
+ admissionController.webHook.amServiceName: "yunikorn-admission-controller-service"
+ admissionController.webHook.schedulerServiceAddress: "yunikorn-service:9080"
+ admissionController.filtering.processNamespaces: ""
+ admissionController.filtering.bypassNamespaces: "^kube-system$"
+ admissionController.filtering.labelNamespaces: ""
+ admissionController.filtering.noLabelNamespaces: ""
+ admissionController.accessControl.bypassAuth: "false"
+ admissionController.accessControl.trustControllers: "true"
+ admissionController.accessControl.systemUsers: "^system:serviceaccount:kube-system:"
+ admissionController.accessControl.externalUsers: ""
+ admissionController.accessControl.externalGroups: ""
+ queues.yaml: |
+ partitions:
+ - name: default
+ placementrules:
+ - name: tag
+ value: namespace
+ create: true
+ queues:
+ - name: root
+ submitacl: '*'`
+
+### 服务设置
+YuniKorn可理解以下参数：
+
+#### service.clusterId
+为正在配置的集群设置标识符。这将作为REST API调用的一部分返回。
+
+更改此设置需要重新启动YuniKorn才能生效。
+
+默认值： `mycluster`
+
+示例：
+
+ service.clusterId: "yunikorn-east"
+
+#### service.policyGroup
+定义此调度器使用的策略组。策略组用于选择多个队列配置之一。此设置的值加上`.yaml`的扩展名控制用于检索分区和队列配置的ConfigMap条目。
+
+更改此设置需要重新启动YuniKorn才能生效。
+
+默认值： `queues`
+
+示例：
+
+ service.policyGroup: group_b
+ group_b.yaml: |
+ partitions:
+ - name: default
+ placementrules:
+ - name: tag
+ value: namespace
+ create: true
+ queues:
+ - name: root
+ submitacl: '*'`
+
+#### service.schedulingInterval
+控制YuniKorn执行调度运行的频率。
+
+更改此设置需要重新启动YuniKorn才能生效。
+
+默认值： `1s`
+
+示例：
+
+ service.schedulingInterval: "5s"
+
+#### service.volumeBindTimeout
+控制卷绑定失败的超时时间。
+
+更改此设置需要重新启动YuniKorn才能生效。
+
+默认值： `10s`
+
+示例：
+
+ service.volumeBindTimeout: "30s"
+
+#### service.eventChannelCapacity
+控制YuniKorn一次允许有多少个内部调度事件在运行。作為内存不足的保护。
+
+更改此设置需要重新启动YuniKorn才能生效。
+
+默认值： `1048576`
+
+示例：
+
+ service.eventChannelCapacity: "1000000"
+
+#### service.dispatchTimeout
+控制如果事件通道已满，内部事件将重新尝试调度多长时间。如果超过此超时时间，将发出警告。
+
+更改此设置需要重新启动YuniKorn才能生效。
+
+默认值： `5m`
+
+示例：
+
+ service.dispatchTimeout: "10m"
+
+#### service.operatorPlugins
+控制在YuniKorn中启用的运算符插件集。目前只实现了 `general`，`spark-k8s-operator` 和 `yunikorn-app` 插件。`general` 插件不应禁用。
+
+更改此设置需要重新启动YuniKorn才能生效。
+
+默认值： `general`
+
+示例：
+
+ service.operatorPlugins: "general,spark-k8s-operator"
+
+#### service.disableGangScheduling
+允许全局禁用gang调度功能（不建议）。
+
+更改此设置需要重新启动YuniKorn才能生效。
+
+默认值： `false`
+
+示例：
+
+ service.disableGangScheduling: "true"
+
+#### service.enableConfigHotRefresh
+控制配置是否应该进行热重载。默认情况下，这个设置为 `true`，但是它可以被禁用，以避免 ConfigMaps 的更改被拾起直到调度器重启。
+
+更改此设置将在YuniKorn不需要重启的情况下生效。
+
+注意：如果禁用了此设置，则可能无法重新启用，除非重新启动YuniKorn。
+
+默认值： `true`
+
+示例：
+
+ service.enableConfigHotRefresh: "false"
+
+#### service.placeholderImage
+设置将用于gang调度占位符的Pod镜像。
+
+更改此设置需要重新启动YuniKorn才能生效。
+
+默认值： `registry.k8s.io/pause:3.7`
+
+示例：
+
+ service.placeholderImage: "registry.k8s.io/pause:3.6"
+
+#### service.instanceTypeNodeLabelKey
+设置节点标签的键，该键用于标识节点的实例类型。如果设置了此值，则YuniKorn将使用此标签来区分节点的实例类型。
+
+更改此设置需要重新启动YuniKorn才能生效。
+
+默认值： `node.kubernetes.io/instance-type`
+
+示例：
+
+ service.instanceTypeNodeLabelKey: "node.kubernetes.io/my-instance-type"
+
+### 健康检查设置
+
+#### health.checkInterval
+设置YuniKorn自动健康检查的时间间隔。
+
+将该值设置为 `0` 或负值将禁用后台健康检查。
+
+更改此设置不需要重新启动YuniKorn即可生效。
+
+默认值： `30s`
+
+示例：
+
+ health.checkInterval: "1m"
+
+### 日志设置
+
+#### log.level
+设置YuniKorn的日志详细程度。
+
+更改此设置不需要重新启动YuniKorn即可生效。可用的值有:
+
+ - `-1`: 调试(Debug)
+ - `0`: 信息(Info)
+ - `1`: 警告(Warn)
+ - `2`: 错误(Error)
+ - `3`: 不可恢復的錯誤(DPanic)
+ - `4`: 不可恢復的錯誤(Panic)
+ - `5`: 致命错误(Fatal)
+
+默认值： `0` (Info)
+
+示例：
+
+ log.level: "-1"
+
+### Kubernetes 设置
+
+#### kubernetes.qps
+设置 YuniKorn Kubernetes 客户端每秒查询（QPS）的数量。该数字必须>=0。
+
+更改此设置需要重新启动 YuniKorn 才能生效。
+
+默认值： `1000`
+
+示例：
+
+ kubernetes.qps: "500"
+
+#### kubernetes.burst
+该设置用于设置 Kubernetes 查询的突发大小，临时允许事件突发到此数字，而不会超过 kubernetes.qps。
+
+更改此设置需要重新启动 YuniKorn 才能生效。
+
+默认值： `1000`
+
+示例：
+
+ kubernetes.burst: "500"
+
+### 准入控制器 webhook 设置
+
+#### admissionController.webHook.amServiceName
+设置 YuniKorn 准入控制器所在的服务的名称下注册。这是准入控制器注册所必需的本身与 Kubernetes 兼容，通常不应更改。
+
+更改此设置需要重新启动 YuniKorn 准入控制器生效。
+
+默认值： `yunikorn-admission-controller-service`
+
+示例：
+
+ admissionController.webHook.amServiceName: "yunikorn-admission-controller-alt-service-name"
+
+#### admissionController.webHook.schedulerServiceAddress
+设置 YuniKorn 调度器服务的地址。这个地址必须是准入控制器可达，并由准入使用验证 ConfigMap 更改时的控制器。准入控制器将联系调度器上的 REST API 以验证任何提议 ConfigMap 更改。通常不应更改此设置。
+
+更改此设置需要重新启动 YuniKorn 准入控制器生效。
+
+默认值： `yunikorn-service:9080`
+
+示例：
+
+ admissionController.webHook.schedulerServiceAddress: "alt-yunikorn-service:9080"
+
+### 准入控制器过滤设置
+
+#### admissionController.filtering.processNamespaces
+控制哪些命名空间会将 pod 转发给 YuniKorn 进行调度。
+
+此设置是以逗号分隔的正则表达式列表。如果这个设置是一个空字符串，在所有命名空间中创建的 pod 将由 YuniKorn 调度。
+
+无需重新启动准入控制器即可获取对此设置的更改。
+
+默认值： empty
+
+示例：
+
+ # YuniKorn 仅在 spark-* 和 mpi-* 命名空间中调度 pod
+ admissionController.filtering.processNamespaces: "^spark-,^mpi-"
+
+#### admissionController.filtering.bypassNamespaces
+该设置控制哪些命名空间的 pod *不会* 被转发到 YuniKorn 进行调度。它作为 `admissionController.filtering.processNamespaces` 的例外列表。
+
+此设置是一组逗号分隔的正则表达式。如果该设置为空字符串，则不会从任何命名空间中排除由 YuniKorn 处理的 pod。
+
+默认情况下，该设置将排除 kube-system 命名空间中的 pod，因为这些 pod 的调度通常需要成功将节点添加到群集中。这可能会阻止 YuniKorn 本身或其他关键服务的启动。
+
+更改此设置将被 admission controller 感知，无需重新启动。
+
+默认值： `^kube-system$`
+
+示例：
+
+ # 不要在 kube-system 或 fluentd-* 命名空间中调度 pod。
+ admissionController.filtering.bypassNamespaces: "^kube-system$,^fluentd-"
+
+#### admissionController.filtering.labelNamespaces
+该设置控制哪些命名空间的 pod 将被打上 `applicationId` 标签。默认情况下，所有由 YuniKorn 调度的 pod 都会被打上 `applicationId` 标签。
+
+当使用标准部署模型运行 YuniKorn 时，所有 pod 都应打上标签，因为 YuniKorn 无法调度未定义 `applicationId` 的 pod。
+
+当使用调度器插件部署模型运行 YuniKorn 时，此设置可用于过滤哪些命名空间应通过 YuniKorn 的队列模型进行调度，哪些命名空间应绕过队列模型并由嵌入式默认调度器进行调度。
+
+此设置是一组逗号分隔的正则表达式。如果该设置为空字符串，则将为转发到 YuniKorn 的所有 pod 打上 `applicationId` 标签。
+
+更改此设置将被 admission controller 感知，无需重新启动。
+
+默认值： empty
+
+示例：
+
+ # 将 applicationId 标签添加到 spark-* 命名空间中的 pod。
+ admissionController.filtering.labelNamespaces: "^spark-"
+
+#### admissionController.filtering.noLabelNamespaces
+该设置控制哪些命名空间的 pod *不会* 打上` applicationId` 标签。它作为 `admissionController.filtering.labelNamespaces` 的例外列表。
+
+当使用标准部署模型运行 YuniKorn 时，所有 pod 都应打上标签，因为 YuniKorn 无法调度未定义 `applicationId` 的 pod。
+
+当使用调度器插件部署模型运行 YuniKorn 时，此设置可用于过滤哪些命名空间应通过 YuniKorn 的队列模型进行调度，哪些命名空间应绕过队列模型并由嵌入式默认调度器进行调度。
+
+此设置是一组逗号分隔的正则表达式。如果该设置为空字符串，则不会应用到 `admissionController.filtering.labelNamespaces` 的任何例外。
+
+更改此设置将被 admission controller 感知，无需重新启动。
+
+默认值： empty
+
+示例：
+
+ # 在命名空间为 noqueue 时跳过队列。
+ admissionController.filtering.labelNamespaces: "^noqueue$"
+
+### 准入控制器访问控制列表（ACL）设置
+
+#### admissionController.accessControl.bypassAuth
+允许外部用户创建带有用户信息的 pod。
+
+更改此设置将被准入控制器感知，无需重新启动。
+
+默认值： `false`
+
+示例：
+
+ admissionController.accessControl.bypassAuth: "true"
+
+#### admissionController.accessControl.trustControllers
+允许控制器用户创建带有用户信息的 pod。
+
+更改此设置将被准入控制器感知，无需重新启动。
+
+默认值： `true`
+
+示例：
+
+ admissionController.accessControl.trustControllers: "false"
+
+#### admissionController.accessControl.systemUsers
+逗号分隔的正则表达式列表，用于匹配允许的控制器服务账户。
+
+更改此设置将被准入控制器感知，无需重新启动。
+
+默认值： `^system:serviceaccount:kube-system:`
+
+示例：
+
+ # 允许所有的 kube-system 账户以及 kube-controller-manager
+ admissionController.accessControl.systemUsers: "^system:serviceaccount:kube-system,^system:kube-controller-manager$"
+
+#### admissionController.accessControl.externalUsers
+逗号分隔的正则表达式列表，用于匹配允许的外部用户。
+
+更改此设置将被准入控制器感知，无需重新启动。
+
+默认值： empty
+
+示例：
+
+ # 允许 'alice'、'bob' 和 'admin-*'
+ admissionController.accessControl.externalUsers: "^alice$,^bob$,^admin-"
+
+#### admissionController.accessControl.externalGroups
+逗号分隔的正则表达式列表，用于匹配允许的外部用户组。
+
+更改此设置将被准入控制器感知，无需重新启动。
+
+默认值： empty
+
+示例：
+
+ # 允许 'sales'、'marketing' 和 'admin-*'
+ admissionController.accessControl.externalGroups: "^sales$,^marketing$,^admin-"
+
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/sorting_policies.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/sorting_policies.md
new file mode 100644
index 0000000000..49d64e9002
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/sorting_policies.md
@@ -0,0 +1,190 @@
+---
+id: sorting_policies
+title: 排序策略
+---
+
+<!--
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ -->
+
+调度器使用策略可以在不更改代码的情况下改变调度行为。
+可以为以下项目设置策略：
+* [应用程序](#应用程序排序)
+* [节点](#节点排序)
+* [请求](#请求排序)
+
+## 应用程序排序
+通过配置为每个队列设置应用程序排序策略。排序策略设置仅对*叶子*队列有效。每个*叶子*队列可以使用不同的策略。
+
+排序策略仅指定应用程序在队列内排序的顺序。
+该顺序对于指定在分配资源时首先考虑哪个应用程序非常重要。
+排序策略*不会*影响在队列中同时调度或激活的应用程序数量。
+所有具有待处理资源请求的应用程序都可以并且将在队列中调度，除非明确地被过滤掉。
+即使使用先进先出策略(FIFO)对应用程序进行排序，多个应用程序也将在队列中并行运行。
+
+*父*队列始终使用公平策略对子队列进行排序。
+
+考虑子队列的相对优先级（在*父*队列排序的情况下）和应用程序的相对优先级（在*叶子*队列排序的情况下）。
+要在调度时忽略应用程序和队列优先级，请将队列属性`application.sort.priority`设置为`disabled`。
+
+以下配置条目将应用程序排序策略设置为FIFO，适用于队列`root.sandbox`：
+
+```yaml
+partitions:
+ - name: default
+ queues:
+ - name: root
+ queues:
+ - name: sandbox
+ properties:
+ application.sort.policy: fifo
+```
+
+仅考虑具有未处理请求的应用程序进行调度。
+在排序应用程序*时*应用筛选器以移除所有没有未处理请求的应用程序。
+
+### FifoSortPolicy
+简短描述：先进先出，基于应用程序创建时间。
+
+配置值：`fifo`（默认）
+
+在排序之前，需要过滤应用程序，并且必须有挂起(pending)的资源请求。
+
+经过筛选后，应用程序将根据创建时间戳进行排序，不会使用其他过滤。
+由于系统仅在锁定状态下添加应用程序，因此不可能有两个具有完全相同时间戳的应用程序。
+
+结果，最早的请求资源的应用程序获得资源。
+较晚请求的应用程序将在满足之前应用程序当前所有请求之后获得资源。
+
+### FairSortPolicy
+简短描述：基于资源利用率公平性排序。
+
+配置值： `fair`
+
+在排序之前，需要过滤应用程序，并且必须有挂起(pending)的资源请求。
+
+经过筛选后，剩下的应用程序将根据使用情况进行排序。
+应用程序的使用情况是指应用程序所有已确认和未确认的分配。
+计算使用情况时，将考虑应用程序中定义的所有资源。
+
+达到的效果是资源相对平均分配给所有请求资源的应用程序
+
+### StateAwarePolicy
+简短描述：限制同一时间只有一个为 Starting 或 Accepted 状态的应用程序。
+
+配置值： `stateaware`
+
+此排序策略需要了解应用程序状态。
+应用程序状态在[应用程序状态](design/scheduler_object_states.md#application-state)文档中进行了描述。
+
+在对所有排队的应用程序进行排序之前，将应用以下过滤器：
+第一个过滤器基于应用程序状态。
+以下应用程序通过过滤器并生成第一个中间列表：
+* 处于 *running* 状态的所有应用程序
+* *一个*（1）处于 *starting* 状态的应用程序
+* 如果*没有*处于 *starting* 状态的应用程序，则添加 *一个*（1）处于 *accepted* 状态的应用程序
+
+第二个过滤器将第一个过滤器的结果作为输入。
+再次过滤初步列表：删除所有*没有*挂起(pending)请求的应用程序。
+
+根据状态和挂起(pending)请求进行过滤后，剩余的应用程序将进行排序。
+因此，最终列表将使用剩余的应用程序两次过滤并按创建时间排序。
+
+回顾下 *Starting* 和 *Accepted* 状态的交互：
+只有在没有处于 *Starting* 状态的应用程序时，才会添加处于 *Accepted* 状态的应用程序。
+处于 *Starting* 状态的应用程序不必有挂起(pending)请求。
+任何处于 *Starting* 状态的应用程序都将防止 *Accepted* 应用程序被添加到已过滤的列表中。
+
+有关详细信息，请参阅设计文档中的 [示例](design/state_aware_scheduling.md#example-run) 运行。
+
+达到的效果是，已经在运行的应用程序讲优先得到资源。
+在所有已运行的应用程序后，逐一调度新的应用程序。
+
+
+## 节点排序
+节点排序策略通过配置文件为每个分区设置，不同的分区可以使用不同的策略。
+以下配置项将分区`default`的节点排序策略设置为`fair`:
+```yaml
+partitions:
+ - name: default
+ nodesortpolicy:
+ type: fair
+```
+
+### FairnessPolicy
+简要描述：按可用资源排序，按降序排列
+
+配置值：`fair` (默认值)
+
+行为：
+按可用资源的数量对节点列表进行排序，使具有最高可用资源量的节点排在列表的第一位。
+计算使用情况时，将考虑节点上定义的所有资源。
+对于节点的相同类型资源进行比较。
+
+这将导致考虑可用性最低的节点首先进行新分配的分配，从而在所有可用节点上分散分配。
+这将导致每个可用节点的整体利用率降低，除非整个环境的利用率非常高。
+将所有节点的负载保持在相似水平有助于。
+在自动缩放添加新节点的环境中，这可能会触发意外的自动缩放请求。
+
+### BinPackingPolicy
+简要描述：按可用资源排序，按升序排列
+
+配置值：`binpacking`
+
+行为：
+按可用资源的数量对节点列表进行排序，使具有最低可用资源量的节点排在列表的第一位。
+计算使用情况时，将考虑节点上定义的所有资源。
+对于节点的相同类型资源进行比较。
+
+这将导致考虑可用性最高的节点首先进行新分配的分配，从而使少量节点的利用率更高，更适合云部署。
+
+## 资源加权
+节点排序策略可能使用节点利用率来确定顺序。
+因为节点可以具有多个唯一的资源类型，所以节点的利用率是由其各个资源类型的加权平均值确定的。
+资源加权可以通过使用`nodesortpolicy`的`resourceweights`部分进行自定义。
+如果`resourceweights`不存在或为空，则默认配置将`vcore`和`memory`的权重设置为相等的`1.0`。
+所有其他资源类型都将被忽略。
+只有明确提到的资源类型才会具有权重。
+
+YuniKorn在内部跟踪CPU资源作为`vcore`资源类型。
+这将映射到Kubernetes资源类型`cpu`。
+除`vcore`和memory之外，所有其他资源类型在YuniKorn和Kubernetes之间具有一致的命名。
+
+例如，在默认配置中，如果节点的CPU和内存分别分配了`90％`和`50％`，则该节点将被视为已使用`70％`。
+
+以下配置条目为分区default设置了`vcore`权重为`4.0`和`memory`权重为`1.0`。
+这将使CPU使用的权重比内存使用高四倍：
+```yaml
+partitions:
+ - name: default
+ nodesortpolicy:
+ type: fair
+ resourceweights:
+ vcore: 4.0
+ memory: 1.0
+```
+
+使用此配置，在此示例中，如果节点的CPU和内存分别分配了`90％`和`50％`，则该节点将被视为已使用`82％`。
+
+请注意，权重是相对于彼此的，因此指定`{4.0，1.0}`的权重等效于`{1.0，0.25}`。不允许负权重。
+
+## 请求排序
+当前仅有一种策略可用于在应用程序内对请求进行排序。
+此策略不可配置。
+仅可以基于请求的优先级对请求进行排序。
+如果应用程序中有多个具有相同优先级的请求，则请求的顺序未确定。
+这意味着具有相同优先级的请求的顺序可能会在运行之间改变。
\ No newline at end of file
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/troubleshooting.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/troubleshooting.md
new file mode 100644
index 0000000000..4b47d6b0ab
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/troubleshooting.md
@@ -0,0 +1,189 @@
+---
+id: troubleshooting
+title: 故障排除
+---
+
+<!--
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ -->
+
+## 调度日志(Scheduler logs)
+
+### 检索调度日志
+
+调度器会将日志写入stdout/stderr，docker容器就会将这些日志重新导向到节点的本地位置，你可以从[这里](https://docs.docker.com/config/containers/logging/configure/)读到更多的文档，这些日志可以通过[kuberctl logs](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs)检索。如：
+
+```shell script
+//获取调度的pod
+kubectl get pod -l component=yunikorn-scheduler -n yunikorn
+NAME READY STATUS RESTARTS AGE
+yunikorn-scheduler-766d7d6cdd-44b82 2/2 Running 0 33h
+
+//检索日志
+kubectl logs yunikorn-scheduler-766d7d6cdd-44b82 yunikorn-scheduler-k8s -n yunikorn
+```
+
+在大多数的情况下，这个命令没有办法获取所有的日志，因为调度程序的日志数量庞大，您需要设置[集群级别的日志收集](https://kubernetes.io/docs/concepts/cluster-administration/logging/#cluster-level-logging-architectures)。推荐的设置方式是利用[fluentd](https://www.fluentd.org/)在外部储存(例如s3)上持久的收集日志。
+
+### 设定日志级别
+
+###
+:::note
+我们建议通过REST API来调整日志级别，如此以来我们不需要每次修改级别时重新启动调动程序的pod。但是透过编辑部署配置来设定日志级别时，需要重新启用调度程序的pod，因此强烈不建议这么做。
+:::
+
+停止调度器：
+```shell script
+kubectl scale deployment yunikorn-scheduler -n yunikorn --replicas=0
+```
+
+使用vim编辑部署配置：
+```shell script
+kubectl edit deployment yunikorn-scheduler -n yunikorn
+```
+
+在容器模板的`env`字段中加入`LOG_LEVEL`。例如将`LOG_LEVEL`设置为0会将日志纪录的级别设置为`INFO`。
+
+```yaml
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+…
+spec:
+template:
+…
+spec:
+containers:
+- env:
+- name: LOG_LEVEL
+value: '0'
+```
+
+启用调度器：
+```shell script
+kubectl scale deployment yunikorn-scheduler -n yunikorn --replicas=1
+```
+
+可使用的日志级别：
+
+| 值 | 日志级别 |
+|:-----: |:-------------: |
+| -1 | DEBUG |
+| 0 | INFO |
+| 1 | WARN |
+| 2 | ERROR |
+| 3 | DPanic |
+| 4 | Panic |
+| 5 | Fatal |
+
+## Pods卡在`Pending`状态
+
+如果Pod卡在Pending状态，则意味着调度程序找不到分配Pod的节点。造成这种情况有以下几种可能：
+
+### 1.没有节点满足pod的放置要求
+
+可以在Pod中配置一些放置限制，例如[节点选择器(node-selector)](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)、[亲合/反亲合性(affinity/anti-affinity)](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)、对节点的[污点(taints)](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)没有一定的容忍度等。若要修正此类问题，你可以通过以下方法观察pod：
+
+```shell script
+kubectl describe pod <pod名称> -n <命名空间>
+```
+
+pod事件中包含预测失败，而这解释了为什么节点不符合分配条件
+
+### 2.队列的可用资源不足
+
+如果队列的可用资源不足，Pod将等待队列资源。检查队列是否还有空间可以给Pending pod的方法有以下几种：
+
+1 ) 从Yunikorn UI检查队列使用情况
+
+如果你不知道如何访问UI，可以参考[这里](../get_started/get_started.md#访问-web-ui)的文档。在`Queues`页面中，寻找Pod对应到的队列。你将能够看到队列中剩馀的可用资源。
+
+2 ) 检查pod事件
+
+运行`kubectl describe pod`以获取pod事件。如果你看到类似以下的事件：`Application <appID> does not fit into <队列路径> queue`。则代表pod无法分配，因为队列的资源用完了。
+
+当队列中的其他Pod完成工作或被删除时，代表目前Pending的pod能得到分配，如果Pod依旧在有足够的剩馀资源下，保持pending状态，则可能是因为他正在等待集群扩展。
+
+## 获取完整的状态
+
+Yunikorn状态储存中，包含了对每个进程中每个对象的状态。透过端点来检索，我们可以有很多有用的信息，举一个故障排除的例子：分区列表、应用程序列表(包括正在运行的、已完成的以及历史应用程序的详细信息)、节点数量、节点利用率、通用集群信息、集群利用率的详细信息、容器历史纪录和队列信息。
+
+状态是Yunikorn提供的用于故障排除的宝贵资源。
+
+有几种方法可以获得完整的状态：
+### 1.调度器URL
+
+步骤：
+*在浏览器中打开Yunikorn UI，且在URL中编辑：
+*将`/#/dashboard`取代为`/ws/v1/fullstatedump`，(例如，`http://localhost:9889/ws/v1/fullstatedump`)
+*按下回车键。
+
+透过这个简单的方法来观看即时且完整的状态。
+
+### 2.调度器的REST API
+
+使用以下的调度器REST API，能够让我们看到Yunikorn的完整状态。
+
+`curl -X 'GET'http://localhost:9889/ws/v1/fullstatedump-H 'accept: application/json'`
+
+有关储存状态的更多信息，可以参阅[检索完整状态](api/scheduler.md#retrieve-full-state-dump)的文档。
+
+## 重启调度器
+:::note
+最好的故障排除方法是─把「重启调度器」当作完全没有其他方法之下的最后一步，他不应该在搜集所有日志和状态之前使用。
+:::
+
+Yunikorn可以在重启之后恢复其状态。Yunikorn调度器的pod作为deployment部署。我们可以透过`scale`来增加和减少副本数量来重启Yunikorn调度器，方法如下：
+
+```shell script
+kubectl scale deployment yunikorn-scheduler -n yunikorn --replicas=0
+kubectl scale deployment yunikorn-scheduler -n yunikorn --replicas=1
+```
+
+## 成组调度
+### 1.没有占位符被创建，且app处于pending状态
+*原因*：这通常是因为应用程序被调度气拒绝，因此没有一个pod被调度。
+
+导致拒绝的常见原因有：
+
+1)任务群组(taskGroups)定义无效。调度程序在应用程序被提交时会进行健全性检查，以确保正确定义所有任务群组，如果这些信息的格式不正确，调度程序将拒绝该应用程序
+
+2)任务群组中定义的总最小资源量大于队列的最大资源量，因此调度程序拒绝该应用程序，因为队列的资源量无法满足它。可以通过检查pod事件中的相关消息，或调度器日志来找到更多详细的错误信息。
+
+*解决方案*：更正任务群组的定义并重新提交应用程序。
+
+### 2.有些占位符没有被分配
+*原因*：占位符也会消耗资源，如果不能全部分配，通常是队列或者集群没有足够的资源分配给它们。在这种情况下，占位符将在一定时间后被清理，该时间由调度策略参数─`placeholderTimeoutInSeconds`所定义。
+
+*解决方案*：如果占位符超时了，目前的app将会转为failed状态，无法再被调度。如果您愿意等待更长的时间，可以增加占位符超时的值。将来可能会添加倒退策略以提供重试，而不是使应用程序失败。
+
+### 3.有些占位符没有被交换
+*原因*：这通常代表应用程序的pod少于任务群组中定义的最小成员数(`minMembers`)
+
+*解决方案*：检查任务群组字段中的`minMember`并确保其设置正确。`minMember`可以小于实际的pod数，设置大于实际pod数是无效的。
+
+### 4.应用程序终止时不会清除占位符
+*原因*：所有占位符都会设置[ownerReference](https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)到应用程序的第一个真实的pod，或控制器参考。如果无法清理占位符，则意味着垃圾回收(garbage collector)的机制不正常。
+
+*解决方案*：检查占位符的`ownerReference`和Kubernetes中的垃圾收集器。
+
+## 仍然遇到问题？
+没问题！Apache Yunikorn社区将很乐意提供帮助。您可以通过以下选项联系社区：
+
+1. 将您的问题发布到dev@yunikorn.apache.org。
+2. 加入[YuniKorn slack](https://join.slack.com/t/yunikornworkspace/shared_invite/enQtNzAzMjY0OTI4MjYzLTBmMDdkYTAwNDMwNTE3NWVjZWE1OTczMWE4NDI2Yzg3MmEyZjUyYTZlMDE5M2U4ZjZhNmYyNGFmYjY4ZGYyMGE)并将您的问题发布到`#yunikorn-user`频道。
+3. 加入[社区会议](http://yunikorn.apache.org/community/get_involved#community-meetings)并直接与社区成员交谈。
\ No newline at end of file
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/usergroup_resolution.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/usergroup_resolution.md
new file mode 100644
index 0000000000..7702498cd2
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/usergroup_resolution.md
@@ -0,0 +1,121 @@
+---
+id: usergroup_resolution
+title: 解析用户和群组
+---
+
+<!--
+Licensed to the Apache Software Foundation(ASF)under one
+or more contributor license agreements.See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.The ASF licenses this file
+to you under the Apache License，Version 2.0(the
+"License")；you may not use this file except in compliance
+with the License.You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing，
+software distributed under the License is distributed on an
+"AS IS"BASIS，WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND，either express or implied.See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+## 用户解析 (User resolution)
+
+用户信息是调度周期的重要概念，他是決定「是否将作业提交到队列」的关键指标之一。Yunikorn调度器依赖k8s Shim来提供用户信息，但在Kubernetes的世界中，没有任何对象可以识别实际用户，这是基于设计使然，可以从这个[页面](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes)中得到更多资讯。
+
+在Yunikorn中有两种处理用户和群组的方法。第一种是传统的方式，使用标签`yunikorn.apache.org/usernname`。如果此标签设置在pod上，则该值会自动提取到shim中并被使用。群组解析也在shim中完成，但预设是不启用的。这种方法的问题有两个方面：首先，用户限制可以很容易地被绕过，因为提交者可以自由地将标签设置为任何值，因此这只能在受信任的环境中使用。其次，在shim中识别组别太慢了─将用户分配到多个群组是不可行的，因为根据身份验证机制(如X509，tokens，LDP，etc)可能很难查找用户属于哪一个群组。
+
+由于这些限制很大，为了向后兼容才保留了此方法，且将来可能会被删除。
+
+一种更可靠和健全的机制是使用`yunikorn.apache.org/user.info`，其中用户信息中的「允许的用户或群组列表」可以由从外部设置，或者准入控制(admission controller)可以自动将其附加到每个工作负载(workflow)。
+
+## 传统的用户处理
+
+### 使用`yunikorn.apache.org/username`标签
+
+由于kubernetes没有预定义的字段和资源能用于用户信息，且个别集群使用的用户识别工具可能有所不同，于是我们定义了标准的方法来识别用户。Yunikorn需要添加一个kubernetes[标签](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)。这里提供了[推荐的使用方法](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/)，预设的标签定义如下：
+
+|标签|值|
+|----------------------------------------------- |--------------------- |
+| yunikorn.apache.org/username |用户名。可以重复该条目，但只会使用第一个值。默认的用户是`nobody` |
+
+举例：
+```yaml
+metadata:
+ labels:
+ yunikorn.apache.org/username:"john"
+```
+:::tip
+为了让该字段(field)成为唯一识别用户的指标，建议集群管理员使用用户识别工具，将这个标签设为不可变的字段。集群管理员或用户可以自由的使用任何方法或工具来增加这个字段和值。其中包含在提交时手动添加。
+:::
+
+:::note 假设
+假设：
+Yunikorn假设一个应用程序的所有pod都属于同一个用户。我们建议将用户标签添加到应用程序的每个pod。这是为了确保没有任何意外。
+:::
+
+在[K8s的部署](https://github.com/apache/yunikorn-release/blob/master/helm-charts/yunikorn/templates/deployment.yaml)时，可以通过覆盖`USER_LABEL_KEY`来改变标签`yunikorn.apache.org/username`的默认值，这在已经添加用户标签，或出于某些安全因素下必须修改标签的情况下特别有用。
+
+```yaml
+ env:
+ - name: USER_LABEL_KEY
+ value:"custom_user_label"
+```
+
+### 群组解析 (Group resolution)
+
+这里包含群组成员解析的定义，此外该功能是可以选择加入或移除的。群组不必是用户或群组对象所提供的一部分。当对象被加到缓存中时，群组将自动根据配置来解析。可以为每个分区(partition)设置连接到缓存的解析器(resolver)。
+
+预设的群组解析器是"no resolver"。此解析器仅回传用户明和与用户同名的主要群组。
+
+其他解析器：
+* 操作系统解析器
+* 测试解析器
+
+## 推荐的处理用户的新方式
+
+从Yunikorn 1.2开始，可以使用更复杂的用户/群组解析方式。
+
+在这种模式下，Yunikorn不再依赖标签`yunikorn.apache.org/username`，而是将`yunikorn.apache.org/user.info`附加到工作负载。通过简单的JSON值，定义用户名和群组：
+
+```yaml
+metadata:
+ annotations:
+ yunikorn.apache.org/user.info:"
+ {
+ username: \"yunikorn\"，
+ groups: [
+ \"developers\"，
+ \"devops\"
+ ]
+ }"
+```
+
+然而，为了加强安全性，在准入控制器中强制执行了以下操作：
+* 不是集群中的每个用户都可以附加此注解(annotation)，只有在配置允许时才可以使用。
+* 如果缺少注解，则准入控制器将自动添加。
+* 若尝试修改此注解将会被拒绝。
+
+我们不只在pods上这样做，而是在Deployments，ReplicaSet，DeamonSet，StatefulSet，Jobs和CronJobs上都这样做。
+
+此外，群组解析器不再需要放在k8s-shim中。
+
+### 配置准入控制器
+
+准入控制可以在`yunikorn-configs`的configmap中被配置。所有条目都以前缀`admissionController.accessControl.`开头。
+
+|变量|默认值|描述|
+|--|--|--|
+|`bypassAuth`|false|允许任何外部用户使用用户信息集创建pod|
+|`trustControllers`|true|允许Kubernetes控制器的用户创建带有用户信息集的pod|
+|`systemUsers`|"^system:serviceaccount:kube-system:"|允许控制器符物帐号列表使用正则表达式|
+|`externalUsers`|""|在「允许的外部用户列表」上使用正则表达式|
+|`externalGroups`|""|在「允许的外部群组列表」上使用正则表达式|
+
+如果`bypassAuth`设置为`true`，但注解不存在且设定了已遗弃的用户标签，则准入控制器将不会把注解加到pod中。如果未设置注解也未设置用户标签，则新的注解将会被加入。
+在`bypassAuth`为`false`(默认值)的情况下，准入控制器将始终添加新的注解，而不管是否存在已弃用的标签。
+
+在某些情况下，必须将用户和群组在提交时提供给Yunikorn，因为用户和群组管理由外部系统提供，查找机制并不简单。因此，在这些情况下，可以将`externalUsers`和`externalGroups`配置为正则表达式。其中，匹配的用户或群组就可以将`yunikorn.apache.org/user.info`设置为任意值。但这会影响Yunikorn内部的调度，因此必须仔细设置这些属性。
\ No newline at end of file
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/workloads/run_flink.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/workloads/run_flink.md
new file mode 100644
index 0000000000..40eb05b197
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/workloads/run_flink.md
@@ -0,0 +1,66 @@
+---
+id: run_flink
+title: 运行Flink作业
+description: 如何与YuniKorn一起运行Flink作业
+image: https://svn.apache.org/repos/asf/flink/site/img/logo/png/100/flink_squirrel_100_color.png
+keywords:
+ - spark
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+使用 YuniKorn 在 Kubernetes 上运行 [Apache Flink](https://flink.apache.org/) 非常容易。
+根据在 Kubernetes 上运行 Flink 的模式不同，配置会略有不同。
+
+## Standalone（独立）模式
+
+请关注 [Kubernetes 设置](https://ci.apache.org/projects/flink/flink-docs-stable/ops/deployment/kubernetes.html) 以获取 standalone 部署模式的细节和示例。
+在这种模式下，我们可以直接在 Deployment/Job spec 中添加需要的标签（applicationId 和 queue）来使用 YuniKorn 调度器运行 flink 应用程序，以及 [使用 YuniKorn 调度器运行 workloads](#run-workloads-with-yunikorn-scheduler) .
+
+## Native（原生）模式
+
+请关注 [原生 Kubernetes 设置](https://ci.apache.org/projects/flink/flink-docs-stable/ops/deployment/native_kubernetes.html) 以获取原生部署模式的细节和示例。
+只有 Flink 1.11 或更高版本才支持在 native 模式下使用 YuniKorn 调度程序运行 Flink 应用程序，我们可以利用两个 Flink 配置 `kubernetes.jobmanager.labels` 和 `kubernetes.taskmanager.labels` 来设置所需的标签。
+例子：
+
+* 启动一个 Flink session
+```
+./bin/kubernetes-session.sh \
+ -Dkubernetes.cluster-id=<ClusterId> \
+ -Dtaskmanager.memory.process.size=4096m \
+ -Dkubernetes.taskmanager.cpu=2 \
+ -Dtaskmanager.numberOfTaskSlots=4 \
+ -Dresourcemanager.taskmanager-timeout=3600000 \
+ -Dkubernetes.jobmanager.labels=applicationId:MyOwnApplicationId,queue:root.sandbox \
+ -Dkubernetes.taskmanager.labels=applicationId:MyOwnApplicationId,queue:root.sandbox
+```
+
+* 启动一个 Flink application
+```
+./bin/flink run-application -p 8 -t kubernetes-application \
+ -Dkubernetes.cluster-id=<ClusterId> \
+ -Dtaskmanager.memory.process.size=4096m \
+ -Dkubernetes.taskmanager.cpu=2 \
+ -Dtaskmanager.numberOfTaskSlots=4 \
+ -Dkubernetes.container.image=<CustomImageName> \
+ -Dkubernetes.jobmanager.labels=applicationId:MyOwnApplicationId,queue:root.sandbox \
+ -Dkubernetes.taskmanager.labels=applicationId:MyOwnApplicationId,queue:root.sandbox \
+ local:///opt/flink/usrlib/my-flink-job.jar
+```
\ No newline at end of file
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/workloads/run_mpi.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/workloads/run_mpi.md
new file mode 100644
index 0000000000..374c5ca1e6
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/workloads/run_mpi.md
@@ -0,0 +1,107 @@
+---
+id: run_mpi
+title: 运行MPI作业
+description: 在Yunikorn中运行MPI作业
+keywords:
+ - mpi
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+本指南介绍将介绍如何设置[MPI Operator](https://github.com/kubeflow/mpi-operator)，以及如何使用YuniKorn调度程序运行MPIJob。
+
+## 安装MPI操作器
+您可以使用以下命令安装MPI操作器。如果您在安装时遇到问题，请参阅[此文档](https://github.com/kubeflow/mpi-operator)了解详细信息。
+```
+kubectl create -f https://raw.githubusercontent.com/kubeflow/mpi-operator/master/deploy/v2beta1/mpi-operator.yaml
+```
+
+## 运行MPI作业
+此示例显示如何运行MPI应用程序。
+
+此程序将印出一些关于workers的基础信息，然后计算圆周率的近似值。
+
+这是一个计算圆周率的[YAML示例](https://github.com/apache/yunikorn-k8shim/blob/master/deployments/examples/mpioperator/Pi/pi.yaml)：
+
+```yaml
+apiVersion: kubeflow.org/v2beta1
+kind: MPIJob
+metadata:
+ name: pi
+spec:
+ slotsPerWorker: 1
+ runPolicy:
+ cleanPodPolicy: Running
+ ttlSecondsAfterFinished: 60
+ sshAuthMountPath: /home/mpiuser/.ssh
+ mpiReplicaSpecs:
+ Launcher:
+ replicas: 1
+ template:
+ labels:
+ applicationId: "mpi_job_pi"
+ queue: root.mpi
+ spec:
+ schedulerName: yunikorn
+ containers:
+ - image: mpioperator/mpi-pi
+ name: mpi-launcher
+ securityContext:
+ runAsUser: 1000
+ command:
+ - mpirun
+ args:
+ - -n
+ - "2"
+ - /home/mpiuser/pi
+ resources:
+ limits:
+ cpu: 1
+ memory: 1Gi
+ Worker:
+ replicas: 2
+ template:
+ labels:
+ applicationId: "mpi_job_pi"
+ queue: root.mpi
+ spec:
+ schedulerName: yunikorn
+ containers:
+ - image: mpioperator/mpi-pi
+ name: mpi-worker
+ securityContext:
+ runAsUser: 1000
+ command:
+ - /usr/sbin/sshd
+ args:
+ - -De
+ - -f
+ - /home/mpiuser/.sshd_config
+ resources:
+ limits:
+ cpu: 1
+ memory: 1Gi
+```
+创建一个MPIJob。
+```
+kubectl create -f deployments/examples/mpioperator/Pi/pi.yaml
+```
+
+我们在圆周率示例中添加了Yunikorn标签，以演示如何使用yunikorn调度程序。
\ No newline at end of file
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/workloads/run_spark.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/workloads/run_spark.md
new file mode 100644
index 0000000000..45791a1842
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/workloads/run_spark.md
@@ -0,0 +1,159 @@
+---
+id: run_spark
+title: 运行Spark作业
+description: 如何使用YuniKorn运行Spark作业
+keywords:
+ - spark
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+:::note 注意
+本文档假设您已安装YuniKorn及其准入控制器。请参阅 [开始](../../get_started/get_started.md) 查看如何操作。
+:::
+
+## 为Spark准备docker镜像
+
+要在Kubernetes上运行Spark，您需要Spark的docker镜像。您可以
+1）使用Spark团队提供的docker镜像
+2）从头开始构建一个镜像。如果你想建立自己的Spark的docker镜像，您可以找到 [完整说明](https://spark.apache.org/docs/latest/building-spark.html)
+在 Spark 文档中。简化步骤:
+* 下载一个支持Kubernetes的Spark版本，URL: https://github.com/apache/spark
+* 构建支持Kubernetes的Spark版本:
+```shell script
+./buid/mvn -Pkubernetes -DskipTests clean package
+```
+建议使用[dockerhub](https://hub.docker.com/r/apache/spark/tags)中不同spark版本的官方镜像
+
+## 为Spark作业创建一个命名空间
+
+创建一个命名空间：
+
+```shell script
+cat <<EOF | kubectl apply -f -
+apiVersion: v1
+kind: Namespace
+metadata:
+ name: spark-test
+EOF
+```
+
+## 创建服务帐号和角色绑定
+
+在 `spark-test` 命名空间下创建 service account 和 role bindings :
+
+```shell script
+cat <<EOF | kubectl apply -n spark-test -f -
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+ name: spark
+ namespace: spark-test
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+ name: spark-role
+ namespace: spark-test
+rules:
+- apiGroups: [""]
+ resources: ["pods"]
+ verbs: ["get", "watch", "list", "create", "delete"]
+- apiGroups: [""]
+ resources: ["configmaps"]
+ verbs: ["get", "create", "delete"]
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+ name: spark-role-binding
+ namespace: spark-test
+subjects:
+- kind: ServiceAccount
+ name: spark
+ namespace: spark-test
+roleRef:
+ kind: Role
+ name: spark-role
+ apiGroup: rbac.authorization.k8s.io
+EOF
+```
+
+:::注意
+不可以在生产环境使用 `ClusterRole` 和 `ClusterRoleBinding` 去运行一个Spark作业！
+请为运行Spark作业配置更细粒度的安全上下文。有关如何配置正确的RBAC规则的详细信息，请参见[链接](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)。
+:::
+
+## 提交一个Spark作业
+
+如果这是从本地计算机运行的，您需要启动代理才能与api服务器通信。
+```shell script
+kubectl proxy
+```
+
+[dockerhub](https://hub.docker.com/r/apache/spark/tags)中有不同spark版本的官方镜像
+运行一个简单的 SparkPi 作业，假设 Spark 二进制文件本地安装在 `/usr/local` 目录中。
+```shell script
+export SPARK_HOME=/usr/local/spark/
+${SPARK_HOME}/bin/spark-submit --master k8s://http://localhost:8001 --deploy-mode cluster --name spark-pi \
+ --master k8s://http://localhost:8001 --deploy-mode cluster --name spark-pi \
+ --class org.apache.spark.examples.SparkPi \
+ --conf spark.executor.instances=1 \
+ --conf spark.kubernetes.namespace=spark-test \
+ --conf spark.kubernetes.executor.request.cores=1 \
+ --conf spark.kubernetes.container.image=docker.io/apache/spark:v3.3.0 \
+ --conf spark.kubernetes.authenticate.driver.serviceAccountName=spark-test:spark \
+ local:///opt/spark/examples/jars/spark-examples_2.12-3.3.0.jar
+```
+:::note
+在 [spark](https://spark.apache.org/docs/latest/running-on-kubernetes.html#configuration) 中有更多设置驱动程序和执行程序的选项。
+可以分配 applicationId 和队列路径。
+```
+--conf spark.kubernetes.executor.label.applicationId=application-spark-0001
+--conf spark.kubernetes.driver.label.applicationId=application-spark-0001
+--conf spark.kubernetes.executor.label.queue=root.default.sandbox
+--conf spark.kubernetes.driver.label.queue=root.default.sandbox
+```
+:::
+
+您可以看见Spark的driver和executors在Kubernetes上创建:
+
+
+
+spark-pi结果在 driver pod中。
+
+
+
+## 幕后发生了什么？
+
+当Spark作业提交到集群时，该作业将提交到 `spark-test` 命名空间。Spark的driver的pod将首先在此名称空间下创建。
+由于该集群已启用YuniKorn准入控制器，当driver的pod创建后，准入控制器会修改pod的规范并注入 `schedulerName=yunikorn`，
+通过这样做默认K8s调度程序将跳过此pod，而由YuniKorn调度。请查看这里[在Kubernetes配置其他调度器](https://kubernetes.io/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)来了解是如何完成的.
+
+默认配置已启用放置规则，该规则会自动将 `spark-test` 命名空间映射到YuniKorn的队列 `root.spark test`。
+提交到此命名空间的所有Spark作业将首先自动提交到该队列。
+要了解有关放置规则如何工作的更多信息，请参阅文档[应用放置规则](user_guide/placement_rules.md)。
+到目前为止，名称空间定义pod的安全上下文，队列考虑到作业顺序、队列资源公平性等因素会确定如何调度作业和pod。
+注意，这是最简单的设置，不强制执行队列容量。该队列被视为具有无限容量。
+
+YuniKor在标签 `spark-app-selector` 中重复设置Spark的应用程序ID，并提交此作业去YuniKorn，同时被视为一份作业。
+当集群中有足够的资源时，作业被调度并运行。
+YuniKorn将driver的pod分配给一个节点，绑定pod并启动所有容器。
+一旦driver的pod启动，它会请求一堆executor的pod来运行它的任务。这些pod也将在相同的名称空间中创建，并且被YuniKorn所调度。
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/workloads/run_tensorflow.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/workloads/run_tensorflow.md
new file mode 100644
index 0000000000..a6007028b5
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/workloads/run_tensorflow.md
@@ -0,0 +1,229 @@
+---
+id: run_tf
+title: 运行TensorFlow作业
+description: 如何使用 YuniKorn 运行 TensorFlow 作业
+keywords:
+ - tensorflow
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+本章节概述了如何设置 [training-operator](https://github.com/kubeflow/training-operator) 以及如何使用 YuniKorn 调度器运行 Tensorflow 作业。
+training-operator 是由 Kubeflow 维护的一体化集成的训练 operator。它不仅支持 TensorFlow，还支持 PyTorch、XGboots 等。
+
+## 安装 training-operator
+您可以使用以下命令在 kubeflow 命名空间中默认安装 training operator。如果安装有问题，
+请参阅 [此文档](https://github.com/kubeflow/training-operator#installation) 来查找相关的详细信息。
+```
+kubectl apply -k "github.com/kubeflow/training-operator/manifests/overlays/standalone?ref=v1.3.0"
+```
+
+## 准备 docker 镜像
+在开始于 Kubernetes 上运行 TensorFlow 作业之前，您需要构建 docker 镜像。
+1. 从 [deployment/examples/tfjob](https://github.com/apache/yunikorn-k8shim/tree/master/deployments/examples/tfjob) 上下载文件
+2. 使用以下命令构建这个 docker 镜像
+
+```
+docker build -f Dockerfile -t kubeflow/tf-dist-mnist-test:1.0 .
+```
+
+## 运行一个 TensorFlow 作业
+以下是一个使用 MNIST [样例](https://github.com/apache/yunikorn-k8shim/blob/master/deployments/examples/tfjob/tf-job-mnist.yaml) 的 TFJob yaml.
+
+```yaml
+apiVersion: kubeflow.org/v1
+kind: TFJob
+metadata:
+ name: dist-mnist-for-e2e-test
+ namespace: kubeflow
+spec:
+ tfReplicaSpecs:
+ PS:
+ replicas: 2
+ restartPolicy: Never
+ template:
+ metadata:
+ labels:
+ applicationId: "tf_job_20200521_001"
+ queue: root.sandbox
+ spec:
+ schedulerName: yunikorn
+ containers:
+ - name: tensorflow
+ image: kubeflow/tf-dist-mnist-test:1.0
+ Worker:
+ replicas: 4
+ restartPolicy: Never
+ template:
+ metadata:
+ labels:
+ applicationId: "tf_job_20200521_001"
+ queue: root.sandbox
+ spec:
+ schedulerName: yunikorn
+ containers:
+ - name: tensorflow
+ image: kubeflow/tf-dist-mnist-test:1.0
+```
+创建 TFJob
+```
+kubectl create -f deployments/examples/tfjob/tf-job-mnist.yaml
+```
+
+您可以从 YuniKorn UI 中查看作业信息。 如果您不知道如何访问 YuniKorn UI，
+请阅读此 [文档](../../get_started/get_started.md#访问-web-ui)。
+
+
+
+## 使用GPU Time-slicing
+### 前提
+要使用 Time-slicing GPU，您需要先设定丛集以让GPU和Time-slicing GPU能被使用。
+- 节点上必须连接GPU
+- Kubernetes版本为1.24
+- 丛集中需要安装 GPU drivers
+- 透过 [GPU Operator](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/getting-started.html) 自动化的建置与管理节点中的 NVIDIA 软体组件
+- 在Kubernetes中设定 [Time-Slicing GPUs in Kubernetes](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/gpu-sharing.html)
+
+
+在安装完 GPU Operator 及 Time-slicing GPU 以后，确认pods的状态以确保所有的containers正在运行或完成：
+```shell script
+kubectl get pod -n gpu-operator
+```
+```shell script
+NAME READY STATUS RESTARTS AGE
+gpu-feature-discovery-fd5x4 2/2 Running 0 5d2h
+gpu-operator-569d9c8cb-kbn7s 1/1 Running 14 (39h ago) 5d2h
+gpu-operator-node-feature-discovery-master-84c7c7c6cf-f4sxz 1/1 Running 0 5d2h
+gpu-operator-node-feature-discovery-worker-p5plv 1/1 Running 8 (39h ago) 5d2h
+nvidia-container-toolkit-daemonset-zq766 1/1 Running 0 5d2h
+nvidia-cuda-validator-5tldf 0/1 Completed 0 5d2h
+nvidia-dcgm-exporter-95vm8 1/1 Running 0 5d2h
+nvidia-device-plugin-daemonset-7nzvf 2/2 Running 0 5d2h
+nvidia-device-plugin-validator-gj7nn 0/1 Completed 0 5d2h
+nvidia-operator-validator-nz84d 1/1 Running 0 5d2h
+```
+确认时间片设定是否被成功的使用：
+```shell script
+kubectl describe node
+```
+
+```shell script
+Capacity:
+ nvidia.com/gpu: 16
+...
+Allocatable:
+ nvidia.com/gpu: 16
+...
+```
+### 使用GPU测试TensorFlow job
+在这个段落中会在 Time-slicing GPU 的支援下，测试及验证TFJob的运行
+
+1. 新建一个workload的测试档案tf-gpu.yaml：
+ ```shell script
+ vim tf-gpu.yaml
+ ```
+ ```yaml
+ apiVersion: "kubeflow.org/v1"
+ kind: "TFJob"
+ metadata:
+ name: "tf-smoke-gpu"
+ namespace: kubeflow
+ spec:
+ tfReplicaSpecs:
+ PS:
+ replicas: 1
+ template:
+ metadata:
+ creationTimestamp:
+ labels:
+ applicationId: "tf_job_20200521_001"
+ spec:
+ schedulerName: yunikorn
+ containers:
+ - args:
+ - python
+ - tf_cnn_benchmarks.py
+ - --batch_size=32
+ - --model=resnet50
+ - --variable_update=parameter_server
+ - --flush_stdout=true
+ - --num_gpus=1
+ - --local_parameter_device=cpu
+ - --device=cpu
+ - --data_format=NHWC
+ image: docker.io/kubeflow/tf-benchmarks-cpu:v20171202-bdab599-dirty-284af3
+ name: tensorflow
+ ports:
+ - containerPort: 2222
+ name: tfjob-port
+ workingDir: /opt/tf-benchmarks/scripts/tf_cnn_benchmarks
+ restartPolicy: OnFailure
+ Worker:
+ replicas: 1
+ template:
+ metadata:
+ creationTimestamp: null
+ labels:
+ applicationId: "tf_job_20200521_001"
+ spec:
+ schedulerName: yunikorn
+ containers:
+ - args:
+ - python
+ - tf_cnn_benchmarks.py
+ - --batch_size=32
+ - --model=resnet50
+ - --variable_update=parameter_server
+ - --flush_stdout=true
+ - --num_gpus=1
+ - --local_parameter_device=cpu
+ - --device=gpu
+ - --data_format=NHWC
+ image: docker.io/kubeflow/tf-benchmarks-gpu:v20171202-bdab599-dirty-284af3
+ name: tensorflow
+ ports:
+ - containerPort: 2222
+ name: tfjob-port
+ resources:
+ limits:
+ nvidia.com/gpu: 2
+ workingDir: /opt/tf-benchmarks/scripts/tf_cnn_benchmarks
+ restartPolicy: OnFailure
+ ```
+2. 创建TFJob
+ ```shell script
+ kubectl apply -f tf-gpu.yaml
+ ```
+3. 在Yunikorn中验证TFJob是否运行
+ 
+ 察看pod的日志:
+ ```shell script
+ kubectl logs logs po/tf-smoke-gpu-worker-0 -n kubeflow
+ ```
+ ```
+ .......
+ ..Found device 0 with properties:
+ ..name: NVIDIA GeForce RTX 3080 major: 8 minor: 6 memoryClockRate(GHz): 1.71
+
+ .......
+ ..Creating TensorFlow device (/device:GPU:0) -> (device: 0, name: NVIDIA GeForce RTX 3080, pci bus id: 0000:01:00.0, compute capability: 8.6)
+ .......
+ ```
+ 
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/workloads/workload_overview.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/workloads/workload_overview.md
new file mode 100644
index 0000000000..c7b46a4c37
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.3.0/user_guide/workloads/workload_overview.md
@@ -0,0 +1,56 @@
+---
+id: workload_overview
+title: 概述
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+YuniKorn调度器支持任何的Kubernetes工作负载。所需要的只是确保将Pod规范的
+`schedulerName`字段设置为`yunikorn`并将`applicationId`标签设置为每个应用程序的唯一值：
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ labels:
+ app: sleep
+ applicationId: "application-sleep-0001"
+ name: sleep-app-1
+spec:
+ schedulerName: yunikorn
+ containers:
+ - name: sleep-30s
+ image: "alpine:latest"
+ command: ["sleep", "30"]
+ resources:
+ requests:
+ cpu: "100m"
+ memory: "100M"
+```
+
+此外，如果存在YuniKorn准入控制器，则可以省略“schedulerName”字段，因为它将在新创建的pod上自动设置。
+
+## 进阶例子
+
+可以在此处找到更进阶的例子：
+
+* [运行Spark作业](run_spark)
+* [运行Flink作业](run_flink)
+* [运行TensorFlow作业](run_tf)
diff --git a/i18n/zh-cn/docusaurus-plugin-content-pages/community/download.md b/i18n/zh-cn/docusaurus-plugin-content-pages/community/download.md
index f2c5d686c2..2e6a4cd21c 100644
--- a/i18n/zh-cn/docusaurus-plugin-content-pages/community/download.md
+++ b/i18n/zh-cn/docusaurus-plugin-content-pages/community/download.md
@@ -31,13 +31,13 @@ Apache YuniKorn 作为源代码压缩包已经发布。
为了方便大家，我们发布了预构建的docker镜像。
-Apache YuniKorn 的最新版本是 v1.2.0。
+Apache YuniKorn 的最新版本是 v1.3.0。
-| 版本 | 发布日期 | 源代码下载 | Docker 镜像 [...]
-|--------|------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [...]
-| v1.2.0 | 2023-02-02 | [下载](https://www.apache.org/dyn/closer.lua/yunikorn/1.2.0/apache-yunikorn-1.2.0-src.tar.gz) <br />[Checksum](https://downloads.apache.org/yunikorn/1.2.0/apache-yunikorn-1.2.0-src.tar.gz.sha512) & [签名](https://downloads.apache.org/yunikorn/1.1.0/apache-yunikorn-1.2.0-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.2.0/images/sha256-c3b1a7b2cfec3f3560415519278cc4d94748f0f60ee80dfaf23fcc22dbb8b8e5) <br />[admission-controller]( [...]
-| v1.1.0 | 2022-09-08 | [下载](https://archive.apache.org/dist/yunikorn/1.1.0/apache-yunikorn-1.1.0-src.tar.gz) <br />[Checksum](https://archive.apache.org/dist/yunikorn/1.1.0/apache-yunikorn-1.1.0-src.tar.gz.sha512) & [签名](https://archive.apache.org/dist/yunikorn/1.1.0/apache-yunikorn-1.1.0-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.1.0/images/sha256-5a45cede355b4c1d0016ba81b317e12a7608ac5de4779892f8c7fa53adf5d739) <br />[admission-controller]( [...]
-| v1.0.0 | 2022-05-06 | [下载](https://archive.apache.org/dist/yunikorn/1.0.0/apache-yunikorn-1.0.0-src.tar.gz) <br />[Checksum](https://downloads.apache.org/yunikorn/1.0.0/apache-yunikorn-1.0.0-src.tar.gz.sha512) & [签名](https://downloads.apache.org/yunikorn/1.0.0/apache-yunikorn-1.0.0-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.0.0/images/sha256-a38ef737337798a6597c56637efc5eeae1701898eb94c4c43e638cbdb9ad782c) <br />[admission-controller]( [...]
+| 版本 | 发布日期 | 源代码下载 | Docker 镜像 [...]
+| ------ | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [...]
+| v1.3.0 | 20203-06-09 | [下载](https://downloads.apache.org/yunikorn/1.3.0/apache-yunikorn-1.3.0-src.tar.gz)<br/>[Checksum](https://downloads.apache.org/yunikorn/1.3.0/apache-yunikorn-1.3.0-src.tar.gz.sha512) & [签名](https://archive.apache.org/dist/yunikorn/1.3.0/apache-yunikorn-1.3.0-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.3.0/images/sha256-cbf05725ca0fa89bda70547c6c00ac955d3aa2456a278b195973c4d7eddd516f?context=explore)<br/>[admissi [...]
+| v1.2.0 | 2023-02-02 | [下载](https://archive.apache.org/dist/yunikorn/1.2.0/apache-yunikorn-1.2.0-src.tar.gz) <br />[Checksum](https://archive.apache.org/dist/yunikorn/1.2.0/apache-yunikorn-1.2.0-src.tar.gz.sha512) & [签名](https://archive.apache.org/dist/yunikorn/1.2.0/apache-yunikorn-1.2.0-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.2.0/images/sha256-c3b1a7b2cfec3f3560415519278cc4d94748f0f60ee80dfaf23fcc22dbb8b8e5) <br />[admission-controller] [...]
+| v1.1.0 | 2022-09-08 | [下载](https://archive.apache.org/dist/yunikorn/1.1.0/apache-yunikorn-1.1.0-src.tar.gz) <br />[Checksum](https://archive.apache.org/dist/yunikorn/1.1.0/apache-yunikorn-1.1.0-src.tar.gz.sha512) & [签名](https://archive.apache.org/dist/yunikorn/1.1.0/apache-yunikorn-1.1.0-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.1.0/images/sha256-5a45cede355b4c1d0016ba81b317e12a7608ac5de4779892f8c7fa53adf5d739) <br />[admission-controller] [...]
## 验证签名
diff --git a/i18n/zh-cn/docusaurus-plugin-content-pages/release-announce/1.3.0.md b/i18n/zh-cn/docusaurus-plugin-content-pages/release-announce/1.3.0.md
new file mode 100644
index 0000000000..ba8ee816f2
--- /dev/null
+++ b/i18n/zh-cn/docusaurus-plugin-content-pages/release-announce/1.3.0.md
@@ -0,0 +1,87 @@
+---
+id: rn-1.3.0
+title: 发布公告 v1.3.0
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# 发布公告 v1.3.0
+我们很高兴地宣布Apache YuniKorn社区已投票决定发布1.3.0。
+Apache YuniKorn是一个独立的资源调度器，专为管理和调度在容器编排框架(如Kubernetes)上的大数据工作负载，用于本地和云端使用案例。
+
+## 概述
+Apache YuniKorn社区在此版本中修复了160个[JIRAs](https://issues.apache.org/jira/issues/?filter=12352568)。
+
+发布经理: Yu Teng Chen
+
+发布日期: 2023-06-09
+
+## 亮点
+
+### Kubernetes 版本支持
+YuniKorn 1.3.0 支持在 1.21 到 1.26 版本的 Kubernetes 集群上运行。
+**不**支持在 Kubernetes 1.27 上运行，但 YuniKorn 1.4.0 计划支持在 Kubernetes 1.27 上运行。
+
+**注**: YuniKorn 1.3.0 是计划中的最后一个版本，它将支持 Kubernetes 1.21 到 1.23； YuniKorn 1.4.0 预计需要 Kubernetes 1.24 或更高版本。
+
+请参阅 [YUNIKORN-1699](https://issues.apache.org/jira/browse/YUNIKORN-1699)了解详情。
+
+### 抢占支持
+YuniKorn 现在全面支持抢占，包括每个队列的可定制策略。 请参阅抢占
+[设计文件](https://yunikorn.apache.org/docs/next/design/preemption)了解详情。
+
+JIRA: [YUNIKORN-1461](https://issues.apache.org/jira/browse/YUNIKORN-1461)
+
+### 更好地支持 BestEffort pod
+YuniKorn 现在跟踪作为队列配额限制的一部分安排的 pod 数量。
+这允许限制队列内的并行性，但也为运行带有`PodQOSBestEffort`调度类的 Kubernetes pod 提供更好的支持（即那些没有请求明确的资源的）。
+
+请参阅 [YUNIKORN-1632](https://issues.apache.org/jira/browse/YUNIKORN-1632)了解详情。
+
+### 更轻便、更安全的镜像
+YuniKorn 1.3.0 已开始为所有容器使用scratch镜像。
+由于 YuniKorn 不再在我们的容器映像中运送任何第三方软件，因此占用空间更小，安全性也更高。
+
+使用scratch镜像的先决条件是将 Web 应用程序从 nginx 迁移到基于 go 的 Web 服务器。
+请参阅
+[YUNIKORN-1672](https://issues.apache.org/jira/browse/YUNIKORN-1672)和
+[YUNIKORN-1535](https://issues.apache.org/jira/browse/YUNIKORN-1535)了解详情。
+
+### 准入控制器中的动态命名空间支持
+YuniKorn 准入控制器现在支持每个命名空间注释来控制 YuniKorn 特定的处理。
+以前，只能使用正则表达式的静态列表（仍然支持）来选择命名空间。
+
+请参阅 [YUNIKORN-1647](https://issues.apache.org/jira/browse/YUNIKORN-1647)了解详情。
+
+### CPU和内存优化
+YuniKorn 1.3.0 包含多项针对 CPU 和内存使用的优化，使该版本成为迄今为止最轻便和最快的版本。
+一些例子：
+* [YUNIKORN-1719](https://issues.apache.org/jira/browse/YUNIKORN-1719)
+ 改进Application.sortRequests()性能
+* [YUNIKORN-1720](https://issues.apache.org/jira/browse/YUNIKORN-1720)
+ 改进node.preAllocateCheck()性能
+* [YUNIKORN-1722](https://issues.apache.org/jira/browse/YUNIKORN-1722)
+ calculateNodesResourceUsage()中过多的资源克隆调用
+* [YUNIKORN-1746](https://issues.apache.org/jira/browse/YUNIKORN-1746)
+ 改进nodeInfoListerImpl.List()性能
+
+## 社区
+Apache YuniKorn社区很高兴欢迎新的PMC: Yu Teng Chen和committer: Qi Zhu。
+
diff --git a/src/pages/community/download.md b/src/pages/community/download.md
index 04ea0720eb..dcdf861f02 100644
--- a/src/pages/community/download.md
+++ b/src/pages/community/download.md
@@ -31,13 +31,13 @@ All release artifacts should be checked for tampering using GPG or SHA-512.
We publish prebuilt docker images for everyone's convenience.
-The latest release of Apache YuniKorn is v1.2.0.
+The latest release of Apache YuniKorn is v1.3.0.
-| Version | Release date | Source download | Docker images [...]
-|---------|--------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------- [...]
-| v1.2.0 | 2023-02-02 | [Download](https://www.apache.org/dyn/closer.lua/yunikorn/1.2.0/apache-yunikorn-1.2.0-src.tar.gz) <br />[Checksum](https://downloads.apache.org/yunikorn/1.2.0/apache-yunikorn-1.2.0-src.tar.gz.sha512) & [Signature](https://downloads.apache.org/yunikorn/1.1.0/apache-yunikorn-1.2.0-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.2.0/images/sha256-c3b1a7b2cf [...]
-| v1.1.0 | 2022-09-08 | [Download](https://archive.apache.org/dist/yunikorn/1.1.0/apache-yunikorn-1.1.0-src.tar.gz) <br />[Checksum](https://archive.apache.org/dist/yunikorn/1.1.0/apache-yunikorn-1.1.0-src.tar.gz.sha512) & [Signature](https://archive.apache.org/dist/yunikorn/1.1.0/apache-yunikorn-1.1.0-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.1.0/images/sha256-5a45cede35 [...]
-| v1.0.0 | 2022-05-06 | [Download](https://archive.apache.org/dist/yunikorn/1.0.0/apache-yunikorn-1.0.0-src.tar.gz) <br />[Checksum](https://archive.apache.org/dist/yunikorn/1.0.0/apache-yunikorn-1.0.0-src.tar.gz.sha512) & [Signature](https://archive.apache.org/dist/yunikorn/1.0.0/apache-yunikorn-1.0.0-src.tar.gz.sha512) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.0.0/images/sha256-a38ef73733 [...]
+| Version | Release date | Source download | Docker images [...]
+| ------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- [...]
+| v1.3.0 | 20203-06-09 | [Download](https://downloads.apache.org/yunikorn/1.3.0/apache-yunikorn-1.3.0-src.tar.gz)<br/>[Checksum](https://downloads.apache.org/yunikorn/1.3.0/apache-yunikorn-1.3.0-src.tar.gz.sha512) & [Signature](https://archive.apache.org/dist/yunikorn/1.3.0/apache-yunikorn-1.3.0-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.3.0/images/sha256-cbf05725ca0fa89bda70547c6c00ac955d3aa2456a278b195973c4d7eddd516f?context=explor [...]
+| v1.2.0 | 2023-02-02 | [Download](https://archive.apache.org/dist/yunikorn/1.2.0/apache-yunikorn-1.2.0-src.tar.gz) <br />[Checksum](https://archive.apache.org/dist/yunikorn/1.2.0/apache-yunikorn-1.2.0-src.tar.gz.sha512) & [Signature](https://archive.apache.org/dist/yunikorn/1.2.0/apache-yunikorn-1.2.0-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.2.0/images/sha256-c3b1a7b2cfec3f3560415519278cc4d94748f0f60ee80dfaf23fcc22dbb8b8e5) <br />[admiss [...]
+| v1.1.0 | 2022-09-08 | [Download](https://archive.apache.org/dist/yunikorn/1.1.0/apache-yunikorn-1.1.0-src.tar.gz) <br />[Checksum](https://archive.apache.org/dist/yunikorn/1.1.0/apache-yunikorn-1.1.0-src.tar.gz.sha512) & [Signature](https://archive.apache.org/dist/yunikorn/1.1.0/apache-yunikorn-1.1.0-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.1.0/images/sha256-5a45cede355b4c1d0016ba81b317e12a7608ac5de4779892f8c7fa53adf5d739) <br />[admiss [...]
## Verifying the signature
diff --git a/src/pages/release-announce/1.3.0.md b/src/pages/release-announce/1.3.0.md
index 72b7fe2347..e40f8d7d12 100644
--- a/src/pages/release-announce/1.3.0.md
+++ b/src/pages/release-announce/1.3.0.md
@@ -35,7 +35,7 @@ in this release.
Release manager: Yu Teng Chen
-Release date: 2023-06-09
+Release date: 2023-06-12
## Highlights
diff --git a/versioned_docs/version-1.3.0/api/cluster.md b/versioned_docs/version-1.3.0/api/cluster.md
new file mode 100644
index 0000000000..b4498d2b51
--- /dev/null
+++ b/versioned_docs/version-1.3.0/api/cluster.md
@@ -0,0 +1,73 @@
+---
+id: cluster
+title: Cluster
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+## Clusters
+
+Returns general information about the clusters managed by the YuniKorn Scheduler. Information includes number of (total, failed, pending, running, completed) applications and containers and the build information of resource managers.
+
+**URL** : `/ws/v1/clusters`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+As an example, here is a response from a cluster with 1 resource manager.
+
+```json
+[
+ {
+ "startTime": 1649167576110754000,
+ "rmBuildInformation": [
+ {
+ "buildDate": "2022-02-21T19:09:16+0800",
+ "buildVersion": "latest",
+ "isPluginVersion": "false",
+ "rmId": "rm-123"
+ }
+ ],
+ "partition": "default",
+ "clusterName": "kubernetes"
+ }
+]
+```
+
+### Error response
+
+**Code** : `500 Internal Server Error`
+
+**Content examples**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
diff --git a/versioned_docs/version-1.3.0/api/scheduler.md b/versioned_docs/version-1.3.0/api/scheduler.md
new file mode 100644
index 0000000000..f52da9b5ec
--- /dev/null
+++ b/versioned_docs/version-1.3.0/api/scheduler.md
@@ -0,0 +1,1890 @@
+---
+id: scheduler
+title: Scheduler
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Overview
+
+The scheduler REST API returns information about various objects used by the YuniKorn Scheduler.
+
+Many of these APIs return collections of resources. Internally, all resources are represented as raw
+64-bit signed integer types. When interpreting responses from the REST API, resources of type `memory`
+are returned in units of bytes while resources of type `vcore` are returned in units of millicores
+(thousands of a core). All other resource types have no specific unit assigned.
+
+Under the `allocations` field in the response content for the app/node-related calls in the following spec, `placeholderUsed` refers to whether or not the allocation is a replacement for a placeholder. If true, `requestTime` is the creation time of its placeholder allocation, otherwise it's that of the allocation's ask. `allocationTime` is the creation time of the allocation, and `allocationDelay` is simply the difference between `allocationTime` and `requestTime`.
+
+## Partitions
+
+Returns general information and statistics about a partition.
+
+**URL** : `/ws/v1/partitions`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```json
+[
+ {
+ "clusterId": "mycluster",
+ "name": "default",
+ "state": "Active",
+ "lastStateTransitionTime": 1649167576110754000,
+ "capacity": {
+ "capacity": {
+ "ephemeral-storage": 188176871424,
+ "hugepages-1Gi": 0,
+ "hugepages-2Mi": 0,
+ "memory": 1000000000,
+ "pods": 330,
+ "vcore": 1000
+ },
+ "usedCapacity": {
+ "memory": 800000000,
+ "vcore": 500
+ },
+ "utilization": {
+ "memory": 80,
+ "vcore": 50
+ }
+ },
+ "nodeSortingPolicy": {
+ "type": "fair",
+ "resourceWeights": {
+ "memory": 1.5,
+ "vcore": 1.3
+ }
+ },
+ "applications": {
+ "New": 5,
+ "Pending": 5,
+ "total": 10
+ },
+ "totalContainers": "0",
+ "totalNodes": "2"
+ },
+ {
+ "clusterId": "mycluster",
+ "name": "gpu",
+ "state": "Active",
+ "lastStateTransitionTime": 1649167576111236000,
+ "capacity": {
+ "capacity": {
+ "memory": 2000000000,
+ "vcore": 2000
+ },
+ "usedCapacity": {
+ "memory": 500000000,
+ "vcore": 300
+ },
+ "utilization": {
+ "memory": 25,
+ "vcore": 15
+ }
+ },
+ "nodeSortingPolicy": {
+ "type": "binpacking",
+ "resourceWeights": {
+ "memory": 0,
+ "vcore": 4.11
+ }
+ },
+ "applications": {
+ "New": 5,
+ "Running": 10,
+ "Pending": 5,
+ "total": 20
+ },
+ "totalContainers": "20",
+ "totalNodes": "5"
+ }
+]
+```
+
+### Error response
+
+**Code** : `500 Internal Server Error`
+
+**Content examples**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## Queues
+
+### Partition queues
+
+Fetch all Queues associated with given Partition and displays general information about the queues like name, status, capacities and properties.
+The queues' hierarchy is kept in the response json.
+
+**URL** : `/ws/v1/partition/{partitionName}/queues`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+For the default queue hierarchy (only `root.default` leaf queue exists) a similar response to the following is sent back to the client:
+
+```json
+[
+ {
+ "queuename": "root",
+ "status": "Active",
+ "maxResource": {
+ "ephemeral-storage": 188176871424,
+ "hugepages-1Gi": 0,
+ "hugepages-2Mi": 0,
+ "memory": 8000000000,
+ "pods": 330,
+ "vcore": 8000
+ },
+ "guaranteedResource": {
+ "memory": 54000000,
+ "vcore": 80
+ },
+ "allocatedResource": {
+ "memory": 54000000,
+ "vcore": 80
+ },
+ "pendingResource": {
+ "memory": 54000000,
+ "vcore": 80
+ },
+ "isLeaf": "false",
+ "isManaged": "false",
+ "properties": {
+ "application.sort.policy": "stateaware"
+ },
+ "parent": "",
+ "template": {
+ "maxResource": {
+ "memory": 8000000000,
+ "vcore": 8000
+ },
+ "guaranteedResource": {
+ "memory": 54000000,
+ "vcore": 80
+ },
+ "properties": {
+ "application.sort.policy": "stateaware"
+ }
+ },
+ "partition": "default",
+ "children": [
+ {
+ "queuename": "root.default",
+ "status": "Active",
+ "maxResource": {
+ "memory": 8000000000,
+ "vcore": 8000
+ },
+ "guaranteedResource": {
+ "memory": 54000000,
+ "vcore": 80
+ },
+ "allocatedResource": {
+ "memory": 54000000,
+ "vcore": 80
+ },
+ "pendingResource": {
+ "memory": 54000000,
+ "vcore": 80
+ },
+ "isLeaf": "true",
+ "isManaged": "false",
+ "properties": {
+ "application.sort.policy": "stateaware"
+ },
+ "parent": "root",
+ "template": null,
+ "children": [],
+ "absUsedCapacity": {
+ "memory": 1,
+ "vcore": 0
+ },
+ "maxRunningApps": 12,
+ "runningApps": 4,
+ "allocatingAcceptedApps": [
+ "app-1",
+ "app-2"
+ ]
+ }
+ ],
+ "absUsedCapacity": {
+ "memory": 1,
+ "vcore": 0
+ }
+ }
+]
+```
+
+### Error response
+
+**Code** : `500 Internal Server Error`
+
+**Content examples**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## Applications
+
+### Queue applications
+
+Fetch all Applications for the given Partition/Queue combination and displays general information about the applications like used resources, queue name, submission time and allocations.
+
+**URL** : `/ws/v1/partition/{partitionName}/queue/{queueName}/applications`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+In the example below there are three allocations belonging to two applications, one with a pending request.
+
+```json
+[
+ {
+ "applicationID": "application-0001",
+ "usedResource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "maxUsedResource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "pendingResource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "partition": "default",
+ "queueName": "root.default",
+ "submissionTime": 1648754032076020293,
+ "requests": [
+ {
+ "allocationKey": "f137fab6-3cfa-4536-93f7-bfff92689382",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0001",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task2"
+ },
+ "requestTime": 16487540320812345678,
+ "resource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "pendingCount": 1,
+ "priority": "0",
+ "requiredNodeId": "",
+ "applicationId": "application-0001",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderTimeout": 0,
+ "taskGroupName": "",
+ "allocationLog": [
+ {
+ "message": "node(s) didn't match Pod's node affinity, node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate",
+ "lastOccurrence": 16487540320812346001,
+ "count": 81
+ },
+ {
+ "message": "node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, node(s) didn't match Pod's node affinity",
+ "lastOccurrence": 16487540320812346002,
+ "count": 504
+ },
+ {
+ "message": "node(s) didn't match Pod's node affinity",
+ "lastOccurrence": 16487540320812346003,
+ "count": 1170
+ }
+ ]
+ }
+ ],
+ "allocations": [
+ {
+ "allocationKey": "deb12221-6b56-4fe9-87db-ebfadce9aa20",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0001",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task0"
+ },
+ "requestTime": 1648754034098912461,
+ "allocationTime": 1648754035973982920,
+ "allocationDelay": 1875070459,
+ "uuid": "9af35d44-2d6f-40d1-b51d-758859e6b8a8",
+ "resource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "priority": "0",
+ "nodeId": "node-0001",
+ "applicationId": "application-0001",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderUsed": true
+ }
+ ],
+ "applicationState": "Running",
+ "user": "system:serviceaccount:kube-system:deployment-controller",
+ "groups": [
+ "system:serviceaccounts",
+ "system:serviceaccounts:kube-system",
+ "system:authenticated"
+ ],
+ "rejectedMessage": "",
+ "stateLog": [
+ {
+ "time": 1648741409145224000,
+ "applicationState": "Accepted"
+ },
+ {
+ "time": 1648741409145509400,
+ "applicationState": "Starting"
+ },
+ {
+ "time": 1648741409147432100,
+ "applicationState": "Running"
+ }
+ ],
+ "placeholderData": [
+ {
+ "taskGroupName": "task-group-example",
+ "count": 2,
+ "minResource": {
+ "memory": 1000000000,
+ "vcore": 100
+ },
+ "replaced": 1,
+ "timedout": 1
+ }
+ ],
+ "hasReserved": false,
+ "reservations": []
+ },
+ {
+ "applicationID": "application-0002",
+ "usedResource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "maxUsedResource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "pendingResource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "partition": "default",
+ "queueName": "root.default",
+ "submissionTime": 1648754032076020293,
+ "requests": [],
+ "allocations": [
+ {
+ "allocationKey": "54e5d77b-f4c3-4607-8038-03c9499dd99d",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0002",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task0"
+ },
+ "requestTime": 1648754034098912461,
+ "allocationTime": 1648754035973982920,
+ "allocationDelay": 1875070459,
+ "uuid": "08033f9a-4699-403c-9204-6333856b41bd",
+ "resource": {
+ "memory": 2000000000,
+ "vcore": 2000
+ },
+ "priority": "0",
+ "nodeId": "node-0001",
+ "applicationId": "application-0002",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderUsed": false
+ },
+ {
+ "allocationKey": "af3bd2f3-31c5-42dd-8f3f-c2298ebdec81",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0002",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task1"
+ },
+ "requestTime": 1648754034098912461,
+ "allocationTime": 1648754035973982920,
+ "allocationDelay": 1875070459,
+ "uuid": "96beeb45-5ed2-4c19-9a83-2ac807637b3b",
+ "resource": {
+ "memory": 2000000000,
+ "vcore": 2000
+ },
+ "priority": "0",
+ "nodeId": "node-0002",
+ "applicationId": "application-0002",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderUsed": false
+ }
+ ],
+ "applicationState": "Running",
+ "user": "system:serviceaccount:kube-system:deployment-controller",
+ "groups": [
+ "system:serviceaccounts",
+ "system:serviceaccounts:kube-system",
+ "system:authenticated"
+ ],
+ "rejectedMessage": "",
+ "stateLog": [
+ {
+ "time": 1648741409145224000,
+ "applicationState": "Accepted"
+ },
+ {
+ "time": 1648741409145509400,
+ "applicationState": "Starting"
+ },
+ {
+ "time": 1648741409147432100,
+ "applicationState": "Running"
+ }
+ ],
+ "placeholderData": [],
+ "hasReserved": false,
+ "reservations": []
+ }
+]
+```
+
+### Error response
+
+**Code** : `500 Internal Server Error`
+
+**Content examples**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## Application
+
+### Queue application
+
+Fetch an Application given a Partition, Queue and Application ID and displays general information about the application like used resources, queue name, submission time and allocations.
+
+**URL** : `/ws/v1/partition/{partitionName}/queue/{queueName}/application/{appId}`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content example**
+
+```json
+{
+ "applicationID": "application-0001",
+ "usedResource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "maxUsedResource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "pendingResource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "partition": "default",
+ "queueName": "root.default",
+ "submissionTime": 1648754032076020293,
+ "requests": [
+ {
+ "allocationKey": "f137fab6-3cfa-4536-93f7-bfff92689382",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0001",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task2"
+ },
+ "requestTime": 16487540320812345678,
+ "resource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "pendingCount": 1,
+ "priority": "0",
+ "requiredNodeId": "",
+ "applicationId": "application-0001",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderTimeout": 0,
+ "taskGroupName": "",
+ "allocationLog": [
+ {
+ "message": "node(s) didn't match Pod's node affinity, node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate",
+ "lastOccurrence": 16487540320812346001,
+ "count": 81
+ },
+ {
+ "message": "node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, node(s) didn't match Pod's node affinity",
+ "lastOccurrence": 16487540320812346002,
+ "count": 504
+ },
+ {
+ "message": "node(s) didn't match Pod's node affinity",
+ "lastOccurrence": 16487540320812346003,
+ "count": 1170
+ }
+ ]
+ }
+ ],
+ "allocations": [
+ {
+ "allocationKey": "deb12221-6b56-4fe9-87db-ebfadce9aa20",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0001",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task0"
+ },
+ "requestTime": 1648754034098912461,
+ "allocationTime": 1648754035973982920,
+ "allocationDelay": 1875070459,
+ "uuid": "9af35d44-2d6f-40d1-b51d-758859e6b8a8",
+ "resource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "priority": "0",
+ "nodeId": "node-0001",
+ "applicationId": "application-0001",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderUsed": true
+ }
+ ],
+ "applicationState": "Running",
+ "user": "system:serviceaccount:kube-system:deployment-controller",
+ "groups": [
+ "system:serviceaccounts",
+ "system:serviceaccounts:kube-system",
+ "system:authenticated"
+ ],
+ "rejectedMessage": "",
+ "stateLog": [
+ {
+ "time": 1648741409145224000,
+ "applicationState": "Accepted"
+ },
+ {
+ "time": 1648741409145509400,
+ "applicationState": "Starting"
+ },
+ {
+ "time": 1648741409147432100,
+ "applicationState": "Running"
+ }
+ ],
+ "placeholderData": [
+ {
+ "taskGroupName": "task-group-example",
+ "count": 2,
+ "minResource": {
+ "memory": 1000000000,
+ "vcore": 100
+ },
+ "replaced": 1,
+ "timedout": 1
+ }
+ ],
+ "hasReserved": false,
+ "reservations": []
+}
+```
+
+### Error response
+
+**Code** : `500 Internal Server Error`
+
+**Content examples**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## UsersTracker
+### Get users usage tracking information
+
+Fetch all users usage given a Partition and displays general information about the users managed by YuniKorn.
+
+**URL** : `/ws/v1/partition/{partitionName}/usage/users`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content example**
+
+```json
+[
+ {
+ "userName": "user1",
+ "groups": {
+ "app2": "tester"
+ },
+ "queues":
+ {
+ "queuePath": "root",
+ "resourceUsage": {
+ "memory": 12000000000,
+ "vcore": 12000
+ },
+ "runningApplications": ["app1", "app2"],
+ "children": [
+ {
+ "queuePath": "root.default",
+ "resourceUsage": {
+ "memory": 6000000000,
+ "vcore": 6000
+ },
+ "runningApplications": ["app1"],
+ "children": []
+ },
+ {
+ "queuePath": "root.test",
+ "resourceUsage": {
+ "memory": 6000000000,
+ "vcore": 6000
+ },
+ "runningApplications": [
+ "app2"
+ ],
+ "children": []
+ }]
+ }
+ },
+ {
+ "userName": "user2",
+ "groups": {
+ "app1": "tester"
+ },
+ "queues":
+ {
+ "queuePath": "root",
+ "resourceUsage": {
+ "memory": 11000000000,
+ "vcore": 10000
+ },
+ "runningApplications": ["app1", "app2", "app3"],
+ "children": [
+ {
+ "queuePath": "root.default",
+ "resourceUsage": {
+ "memory": 5000000000,
+ "vcore": 5000
+ },
+ "runningApplications": ["app1"],
+ "children": []
+ },
+ {
+ "queuePath": "root.test",
+ "resourceUsage": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "runningApplications": [
+ "app3"
+ ],
+ "children": []
+ }]
+ }
+ }
+]
+```
+
+### Error response
+**Code** : `500 Internal Server Error`
+
+**Content examples**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## UserTracker
+### Get specific user usage tracking information
+Fetch specific user usage given a Partition and displays general information about the users managed by YuniKorn.
+
+**URL** : `/ws/v1/partition/{partitionName}/usage/user/{userName}`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content example**
+
+```json
+{
+ "userName": "user1",
+ "groups": {
+ "app1": "tester"
+ },
+ "queues":
+ {
+ "queuePath": "root",
+ "resourceUsage": {
+ "memory": 12000000000,
+ "vcore": 12000
+ },
+ "runningApplications": ["app1", "app2"],
+ "children": [
+ {
+ "queuePath": "root.default",
+ "resourceUsage": {
+ "memory": 6000000000,
+ "vcore": 6000
+ },
+ "runningApplications": ["app1"],
+ "children": []
+ },
+ {
+ "queuePath": "root.test",
+ "resourceUsage": {
+ "memory": 6000000000,
+ "vcore": 6000
+ },
+ "runningApplications": [
+ "app2"
+ ],
+ "children": []
+ }]
+ }
+}
+```
+
+### Error response
+
+**Code** : `500 Internal Server Error`
+
+**Content examples**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## GroupsTracker
+### Get groups usage tracking information
+Fetch all groups usage given a Partition and displays general information about the groups managed by YuniKorn.
+
+**URL** : `/ws/v1/partition/{partitionName}/usage/groups`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content example**
+
+```json
+[
+ {
+ "groupName": "group1",
+ "applications": ["app1", "app2"],
+ "queues":
+ {
+ "queuePath": "root",
+ "resourceUsage": {
+ "memory": 12000000000,
+ "vcore": 12000
+ },
+ "runningApplications": ["app1", "app2"],
+ "children": [
+ {
+ "queuePath": "root.default",
+ "resourceUsage": {
+ "memory": 6000000000,
+ "vcore": 6000
+ },
+ "runningApplications": ["app1"],
+ "children": []
+ },
+ {
+ "queuePath": "root.test",
+ "resourceUsage": {
+ "memory": 6000000000,
+ "vcore": 6000
+ },
+ "runningApplications": [
+ "app2"
+ ],
+ "children": []
+ }]
+ }
+ },
+ {
+ "groupName": "group2",
+ "applications": ["app1", "app2", "app3"],
+ "queues":
+ {
+ "queuePath": "root",
+ "resourceUsage": {
+ "memory": 11000000000,
+ "vcore": 10000
+ },
+ "runningApplications": ["app1", "app2", "app3"],
+ "children": [
+ {
+ "queuePath": "root.default",
+ "resourceUsage": {
+ "memory": 5000000000,
+ "vcore": 5000
+ },
+ "runningApplications": ["app1"],
+ "children": []
+ },
+ {
+ "queuePath": "root.test",
+ "resourceUsage": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "runningApplications": [
+ "app3"
+ ],
+ "children": []
+ }]
+ }
+ }
+]
+```
+
+### Error response
+
+**Code** : `500 Internal Server Error`
+
+**Content examples**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## GroupTracker
+### Get specific group usage tracking information
+
+Fetch specific group usage given a Partition and displays general information about the groups managed by YuniKorn.
+
+**URL** : `/ws/v1/partition/{partitionName}/usage/group/{groupName}`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content example**
+
+```json
+{
+ "groupName": "group1",
+ "applications": ["app1", "app2"],
+ "queues":
+ {
+ "queuePath": "root",
+ "resourceUsage": {
+ "memory": 12000000000,
+ "vcore": 12000
+ },
+ "runningApplications": ["app1", "app2"],
+ "children": [
+ {
+ "queuePath": "root.default",
+ "resourceUsage": {
+ "memory": 6000000000,
+ "vcore": 6000
+ },
+ "runningApplications": ["app1"],
+ "children": []
+ },
+ {
+ "queuePath": "root.test",
+ "resourceUsage": {
+ "memory": 6000000000,
+ "vcore": 6000
+ },
+ "runningApplications": [
+ "app2"
+ ],
+ "children": []
+ }]
+ }
+}
+```
+
+### Error response
+
+**Code** : `500 Internal Server Error`
+
+**Content examples**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## Nodes
+
+### Partition nodes
+
+Fetch all Nodes associated with given Partition and displays general information about the nodes managed by YuniKorn.
+Node details include host and rack name, capacity, resources, utilization, and allocations.
+
+**URL** : `/ws/v1/partition/{partitionName}/nodes`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+Here you can see an example response from a 2-node cluster having 3 allocations.
+
+```json
+[
+ {
+ "nodeID": "node-0001",
+ "hostName": "",
+ "rackName": "",
+ "attributes": {
+ "beta.kubernetes.io/arch": "amd64",
+ "beta.kubernetes.io/os": "linux",
+ "kubernetes.io/arch": "amd64",
+ "kubernetes.io/hostname": "node-0001",
+ "kubernetes.io/os": "linux",
+ "node-role.kubernetes.io/control-plane": "",
+ "node-role.kubernetes.io/master": "",
+ "node.kubernetes.io/exclude-from-external-load-balancers": "",
+ "ready": "true",
+ "si.io/hostname": "node-0001",
+ "si.io/rackname": "/rack-default",
+ "si/instance-type": "",
+ "si/node-partition": "[mycluster]default"
+ },
+ "capacity": {
+ "ephemeral-storage": 75850798569,
+ "hugepages-1Gi": 0,
+ "hugepages-2Mi": 0,
+ "memory": 14577000000,
+ "pods": 110,
+ "vcore": 10000
+ },
+ "allocated": {
+ "memory": 6000000000,
+ "vcore": 6000
+ },
+ "occupied": {
+ "memory": 154000000,
+ "vcore" :750
+ },
+ "available": {
+ "ephemeral-storage": 75850798569,
+ "hugepages-1Gi": 0,
+ "hugepages-2Mi": 0,
+ "memory": 6423000000,
+ "pods": 110,
+ "vcore": 1250
+ },
+ "utilized": {
+ "memory": 3,
+ "vcore": 13
+ },
+ "allocations": [
+ {
+ "allocationKey": "54e5d77b-f4c3-4607-8038-03c9499dd99d",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0001",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task0"
+ },
+ "requestTime": 1648754034098912461,
+ "allocationTime": 1648754035973982920,
+ "allocationDelay": 1875070459,
+ "uuid": "08033f9a-4699-403c-9204-6333856b41bd",
+ "resource": {
+ "memory": 2000000000,
+ "vcore": 2000
+ },
+ "priority": "0",
+ "nodeId": "node-0001",
+ "applicationId": "application-0001",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderUsed": false
+ },
+ {
+ "allocationKey": "deb12221-6b56-4fe9-87db-ebfadce9aa20",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0002",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task0"
+ },
+ "requestTime": 1648754034098912461,
+ "allocationTime": 1648754035973982920,
+ "allocationDelay": 1875070459,
+ "uuid": "9af35d44-2d6f-40d1-b51d-758859e6b8a8",
+ "resource": {
+ "memory": 4000000000,
+ "vcore": 4000
+ },
+ "priority": "0",
+ "nodeId": "node-0001",
+ "applicationId": "application-0002",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderUsed": false
+ }
+ ],
+ "schedulable": true
+ },
+ {
+ "nodeID": "node-0002",
+ "hostName": "",
+ "rackName": "",
+ "attributes": {
+ "beta.kubernetes.io/arch": "amd64",
+ "beta.kubernetes.io/os": "linux",
+ "kubernetes.io/arch": "amd64",
+ "kubernetes.io/hostname": "node-0002",
+ "kubernetes.io/os": "linux",
+ "ready": "false",
+ "si.io/hostname": "node-0002",
+ "si.io/rackname": "/rack-default",
+ "si/instance-type": "",
+ "si/node-partition": "[mycluster]default"
+ },
+ "capacity": {
+ "ephemeral-storage": 75850798569,
+ "hugepages-1Gi": 0,
+ "hugepages-2Mi": 0,
+ "memory": 14577000000,
+ "pods": 110,
+ "vcore": 10000
+ },
+ "allocated": {
+ "memory": 2000000000,
+ "vcore": 2000
+ },
+ "occupied": {
+ "memory": 154000000,
+ "vcore" :750
+ },
+ "available": {
+ "ephemeral-storage": 75850798569,
+ "hugepages-1Gi": 0,
+ "hugepages-2Mi": 0,
+ "memory": 6423000000,
+ "pods": 110,
+ "vcore": 1250
+ },
+ "utilized": {
+ "memory": 8,
+ "vcore": 38
+ },
+ "allocations": [
+ {
+ "allocationKey": "af3bd2f3-31c5-42dd-8f3f-c2298ebdec81",
+ "allocationTags": {
+ "kubernetes.io/label/app": "sleep",
+ "kubernetes.io/label/applicationId": "application-0001",
+ "kubernetes.io/label/queue": "root.default",
+ "kubernetes.io/meta/namespace": "default",
+ "kubernetes.io/meta/podName": "task1"
+ },
+ "requestTime": 1648754034098912461,
+ "allocationTime": 1648754035973982920,
+ "allocationDelay": 1875070459,
+ "uuid": "96beeb45-5ed2-4c19-9a83-2ac807637b3b",
+ "resource": {
+ "memory": 2000000000,
+ "vcore": 2000
+ },
+ "priority": "0",
+ "nodeId": "node-0002",
+ "applicationId": "application-0001",
+ "partition": "default",
+ "placeholder": false,
+ "placeholderUsed": false
+ }
+ ],
+ "schedulable": true,
+ "isReserved": false,
+ "reservations": []
+ }
+]
+```
+
+### Error response
+
+**Code** : `500 Internal Server Error`
+
+**Content examples**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## Node
+
+### Partition node
+
+Fetch a Node associated with given Partition and Node ID and displays general information about the node managed by YuniKorn.
+Node details include host and rack name, capacity, resources, utilization, and allocations.
+
+**URL** : `/ws/v1/partition/{partitionName}/node/{nodeId}`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```json
+{
+ "nodeID":"node-0001",
+ "hostName":"",
+ "rackName":"",
+ "capacity":{
+ "ephemeral-storage":75850798569,
+ "hugepages-1Gi":0,
+ "hugepages-2Mi":0,
+ "memory":14577000000,
+ "pods":110,
+ "vcore":10000
+ },
+ "allocated":{
+ "memory":6000000000,
+ "vcore":6000
+ },
+ "occupied":{
+ "memory":154000000,
+ "vcore":750
+ },
+ "available":{
+ "ephemeral-storage":75850798569,
+ "hugepages-1Gi":0,
+ "hugepages-2Mi":0,
+ "memory":6423000000,
+ "pods":110,
+ "vcore":1250
+ },
+ "utilized":{
+ "memory":3,
+ "vcore":13
+ },
+ "allocations":[
+ {
+ "allocationKey":"54e5d77b-f4c3-4607-8038-03c9499dd99d",
+ "allocationTags":{
+ "kubernetes.io/label/app":"sleep",
+ "kubernetes.io/label/applicationId":"application-0001",
+ "kubernetes.io/label/queue":"root.default",
+ "kubernetes.io/meta/namespace":"default",
+ "kubernetes.io/meta/podName":"task0"
+ },
+ "requestTime":1648754034098912461,
+ "allocationTime":1648754035973982920,
+ "allocationDelay":1875070459,
+ "uuid":"08033f9a-4699-403c-9204-6333856b41bd",
+ "resource":{
+ "memory":2000000000,
+ "vcore":2000
+ },
+ "priority":"0",
+ "nodeId":"node-0001",
+ "applicationId":"application-0001",
+ "partition":"default",
+ "placeholder":false,
+ "placeholderUsed":false
+ },
+ {
+ "allocationKey":"deb12221-6b56-4fe9-87db-ebfadce9aa20",
+ "allocationTags":{
+ "kubernetes.io/label/app":"sleep",
+ "kubernetes.io/label/applicationId":"application-0002",
+ "kubernetes.io/label/queue":"root.default",
+ "kubernetes.io/meta/namespace":"default",
+ "kubernetes.io/meta/podName":"task0"
+ },
+ "requestTime":1648754034098912461,
+ "allocationTime":1648754035973982920,
+ "allocationDelay":1875070459,
+ "uuid":"9af35d44-2d6f-40d1-b51d-758859e6b8a8",
+ "resource":{
+ "memory":4000000000,
+ "vcore":4000
+ },
+ "priority":"0",
+ "nodeId":"node-0001",
+ "applicationId":"application-0002",
+ "partition":"default",
+ "placeholder":false,
+ "placeholderUsed":false
+ }
+ ],
+ "schedulable":true
+}
+```
+
+### Error response
+
+**Code** : `500 Internal Server Error`
+
+**Content examples**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## Goroutines info
+
+Dumps the stack traces of the currently running goroutines.
+
+**URL** : `/ws/v1/stack`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```text
+goroutine 356 [running
+]:
+github.com/apache/yunikorn-core/pkg/webservice.getStackInfo.func1(0x30a0060,
+0xc003e900e0,
+0x2)
+ /yunikorn/go/pkg/mod/github.com/apache/yunikorn-core@v0.0.0-20200717041747-f3e1c760c714/pkg/webservice/handlers.go: 41 +0xab
+github.com/apache/yunikorn-core/pkg/webservice.getStackInfo(0x30a0060,
+0xc003e900e0,
+0xc00029ba00)
+ /yunikorn/go/pkg/mod/github.com/apache/yunikorn-core@v0.0.0-20200717041747-f3e1c760c714/pkg/webservice/handlers.go: 48 +0x71
+net/http.HandlerFunc.ServeHTTP(0x2df0e10,
+0x30a0060,
+0xc003e900e0,
+0xc00029ba00)
+ /usr/local/go/src/net/http/server.go: 1995 +0x52
+github.com/apache/yunikorn-core/pkg/webservice.Logger.func1(0x30a0060,
+0xc003e900e0,
+0xc00029ba00)
+ /yunikorn/go/pkg/mod/github.com/apache/yunikorn-core@v0.0.0-20200717041747-f3e1c760c714/pkg/webservice/webservice.go: 65 +0xd4
+net/http.HandlerFunc.ServeHTTP(0xc00003a570,
+0x30a0060,
+0xc003e900e0,
+0xc00029ba00)
+ /usr/local/go/src/net/http/server.go: 1995 +0x52
+github.com/gorilla/mux.(*Router).ServeHTTP(0xc00029cb40,
+0x30a0060,
+0xc003e900e0,
+0xc0063fee00)
+ /yunikorn/go/pkg/mod/github.com/gorilla/mux@v1.7.3/mux.go: 212 +0x140
+net/http.serverHandler.ServeHTTP(0xc0000df520,
+0x30a0060,
+0xc003e900e0,
+0xc0063fee00)
+ /usr/local/go/src/net/http/server.go: 2774 +0xcf
+net/http.(*conn).serve(0xc0000eab40,
+0x30a61a0,
+0xc003b74000)
+ /usr/local/go/src/net/http/server.go: 1878 +0x812
+created by net/http.(*Server).Serve
+ /usr/local/go/src/net/http/server.go: 2884 +0x4c5
+
+goroutine 1 [chan receive,
+ 26 minutes
+]:
+main.main()
+ /yunikorn/pkg/shim/main.go: 52 +0x67a
+
+goroutine 19 [syscall,
+ 26 minutes
+]:
+os/signal.signal_recv(0x1096f91)
+ /usr/local/go/src/runtime/sigqueue.go: 139 +0x9f
+os/signal.loop()
+ /usr/local/go/src/os/signal/signal_unix.go: 23 +0x30
+created by os/signal.init.0
+ /usr/local/go/src/os/signal/signal_unix.go: 29 +0x4f
+
+...
+```
+
+### Error response
+
+**Code** : `500 Internal Server Error`
+
+**Content examples**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## Metrics
+
+Endpoint to retrieve metrics from the Prometheus server.
+The metrics are dumped with help messages and type information.
+
+**URL** : `/ws/v1/metrics`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```text
+# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
+# TYPE go_gc_duration_seconds summary
+go_gc_duration_seconds{quantile="0"} 2.567e-05
+go_gc_duration_seconds{quantile="0.25"} 3.5727e-05
+go_gc_duration_seconds{quantile="0.5"} 4.5144e-05
+go_gc_duration_seconds{quantile="0.75"} 6.0024e-05
+go_gc_duration_seconds{quantile="1"} 0.00022528
+go_gc_duration_seconds_sum 0.021561648
+go_gc_duration_seconds_count 436
+# HELP go_goroutines Number of goroutines that currently exist.
+# TYPE go_goroutines gauge
+go_goroutines 82
+# HELP go_info Information about the Go environment.
+# TYPE go_info gauge
+go_info{version="go1.12.17"} 1
+# HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.
+# TYPE go_memstats_alloc_bytes gauge
+go_memstats_alloc_bytes 9.6866248e+07
+
+...
+
+# HELP yunikorn_scheduler_vcore_nodes_usage Nodes resource usage, by resource name.
+# TYPE yunikorn_scheduler_vcore_nodes_usage gauge
+yunikorn_scheduler_vcore_nodes_usage{range="(10%, 20%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="(20%,30%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="(30%,40%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="(40%,50%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="(50%,60%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="(60%,70%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="(70%,80%]"} 1
+yunikorn_scheduler_vcore_nodes_usage{range="(80%,90%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="(90%,100%]"} 0
+yunikorn_scheduler_vcore_nodes_usage{range="[0,10%]"} 0
+```
+
+## Configuration validation
+
+**URL** : `/ws/v1/validate-conf`
+
+**Method** : `POST`
+
+**Auth required** : NO
+
+### Success response
+
+Regardless whether the configuration is allowed or not if the server was able to process the request, it will yield a 200 HTTP status code.
+
+**Code** : `200 OK`
+
+#### Allowed configuration
+
+Sending the following simple configuration yields an accept
+
+```yaml
+partitions:
+ - name: default
+ queues:
+ - name: root
+ queues:
+ - name: test
+```
+
+Reponse
+
+```json
+{
+ "allowed": true,
+ "reason": ""
+}
+```
+
+#### Disallowed configuration
+
+The following configuration is not allowed due to the "wrong_text" field put into the yaml file.
+
+```yaml
+partitions:
+ - name: default
+ queues:
+ - name: root
+ queues:
+ - name: test
+ - wrong_text
+```
+
+Reponse
+
+```json
+{
+ "allowed": false,
+ "reason": "yaml: unmarshal errors:\n line 7: cannot unmarshal !!str `wrong_text` into configs.PartitionConfig"
+}
+```
+
+## Configuration
+
+Endpoint to retrieve the current scheduler configuration
+
+**URL** : `/ws/v1/config`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content example**
+
+```yaml
+partitions:
+- name: default
+ queues:
+ - name: root
+ parent: true
+ submitacl: '*'
+ placementrules:
+ - name: tag
+ create: true
+ value: namespace
+checksum: D75996C07D5167F41B33E27CCFAEF1D5C55BE3C00EE6526A7ABDF8435DB4078E
+```
+
+## Application history
+
+Endpoint to retrieve historical data about the number of total applications by timestamp.
+
+**URL** : `/ws/v1/history/apps`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```json
+[
+ {
+ "timestamp": 1595939966153460000,
+ "totalApplications": "1"
+ },
+ {
+ "timestamp": 1595940026152892000,
+ "totalApplications": "1"
+ },
+ {
+ "timestamp": 1595940086153799000,
+ "totalApplications": "2"
+ },
+ {
+ "timestamp": 1595940146154497000,
+ "totalApplications": "2"
+ },
+ {
+ "timestamp": 1595940206155187000,
+ "totalApplications": "2"
+ }
+]
+```
+
+### Error response
+
+**Code** : `500 Internal Server Error`
+
+**Content examples**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+## Container history
+
+Endpoint to retrieve historical data about the number of total containers by timestamp.
+
+**URL** : `/ws/v1/history/containers`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```json
+[
+ {
+ "timestamp": 1595939966153460000,
+ "totalContainers": "1"
+ },
+ {
+ "timestamp": 1595940026152892000,
+ "totalContainers": "1"
+ },
+ {
+ "timestamp": 1595940086153799000,
+ "totalContainers": "3"
+ },
+ {
+ "timestamp": 1595940146154497000,
+ "totalContainers": "3"
+ },
+ {
+ "timestamp": 1595940206155187000,
+ "totalContainers": "3"
+ }
+]
+```
+
+### Error response
+
+**Code** : `500 Internal Server Error`
+
+**Content examples**
+
+```json
+{
+ "status_code": 500,
+ "message": "system error message. for example, json: invalid UTF-8 in string: ..",
+ "description": "system error message. for example, json: invalid UTF-8 in string: .."
+}
+```
+
+
+## Endpoint healthcheck
+
+Endpoint to retrieve historical data about critical logs, negative resource on node/cluster/app, ...
+
+**URL** : `/ws/v1/scheduler/healthcheck`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```json
+{
+ "Healthy": true,
+ "HealthChecks": [
+ {
+ "Name": "Scheduling errors",
+ "Succeeded": true,
+ "Description": "Check for scheduling error entries in metrics",
+ "DiagnosisMessage": "There were 0 scheduling errors logged in the metrics"
+ },
+ {
+ "Name": "Failed nodes",
+ "Succeeded": true,
+ "Description": "Check for failed nodes entries in metrics",
+ "DiagnosisMessage": "There were 0 failed nodes logged in the metrics"
+ },
+ {
+ "Name": "Negative resources",
+ "Succeeded": true,
+ "Description": "Check for negative resources in the partitions",
+ "DiagnosisMessage": "Partitions with negative resources: []"
+ },
+ {
+ "Name": "Negative resources",
+ "Succeeded": true,
+ "Description": "Check for negative resources in the nodes",
+ "DiagnosisMessage": "Nodes with negative resources: []"
+ },
+ {
+ "Name": "Consistency of data",
+ "Succeeded": true,
+ "Description": "Check if a node's allocated resource <= total resource of the node",
+ "DiagnosisMessage": "Nodes with inconsistent data: []"
+ },
+ {
+ "Name": "Consistency of data",
+ "Succeeded": true,
+ "Description": "Check if total partition resource == sum of the node resources from the partition",
+ "DiagnosisMessage": "Partitions with inconsistent data: []"
+ },
+ {
+ "Name": "Consistency of data",
+ "Succeeded": true,
+ "Description": "Check if node total resource = allocated resource + occupied resource + available resource",
+ "DiagnosisMessage": "Nodes with inconsistent data: []"
+ },
+ {
+ "Name": "Consistency of data",
+ "Succeeded": true,
+ "Description": "Check if node capacity >= allocated resources on the node",
+ "DiagnosisMessage": "Nodes with inconsistent data: []"
+ },
+ {
+ "Name": "Reservation check",
+ "Succeeded": true,
+ "Description": "Check the reservation nr compared to the number of nodes",
+ "DiagnosisMessage": "Reservation/node nr ratio: [0.000000]"
+ }
+ ]
+}
+```
+
+## Retrieve full state dump
+
+Endpoint to retrieve the following information in a single response:
+
+* List of partitions
+* List of applications (running and completed)
+* Application history
+* Nodes
+* Utilization of nodes
+* Generic cluster information
+* Cluster utilization
+* Container history
+* Queues
+* RMDiagnostics
+
+**URL** : `/ws/v1/fullstatedump`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+The output of this REST query can be rather large, and it is a combination of those which have already been demonstrated.
+
+The `RMDiagnostics` shows the content of the K8Shim cache. The exact content is version dependent and has not stabilised.
+The current content shows the cached objects:
+* nodes
+* pods
+* priorityClasses
+* schedulingState (pod status)
+
+### Failure response
+
+**Code**: `500 Internal Server Error`
+
+## Enable or disable periodic state dump
+
+Endpoint to enable a state dump to be written periodically.
+
+**Status** : Deprecated and ignored since v1.2.0, no replacement.
+
+**URL** : `/ws/v1/periodicstatedump/{switch}/{periodSeconds}`
+
+**Method** : `PUT`
+
+**Auth required** : NO
+
+### Success response
+
+None
+
+### Error response
+
+**Code**: `400 Bad Request`
+
+## Get log level
+Retrieve the current log level.
+
+**URL** : `/ws/v1/loglevel`
+
+**Method** : `GET`
+
+**Auth required** : NO
+
+### Success response
+
+**Code**: `200 OK`
+
+**Content examples**
+
+```
+info
+```
+
+## Set log level
+Set the log level.
+
+**URL** : `/ws/v1/loglevel/{level}`
+
+**Method** : `PUT`
+
+**Auth required** : NO
+
+### Success response
+
+**Code**: `200 OK`
+
+### Error response
+
+**Code**: `400 Bad Request`
+
+**Content examples**
+
+```json
+{
+ "status_code":400,
+ "message":"failed to change log level, old level active",
+ "description":"failed to change log level, old level active"
+}
+```
diff --git a/versioned_docs/version-1.3.0/api/system.md b/versioned_docs/version-1.3.0/api/system.md
new file mode 100644
index 0000000000..1d685ffa58
--- /dev/null
+++ b/versioned_docs/version-1.3.0/api/system.md
@@ -0,0 +1,225 @@
+---
+id: system
+title: System
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+These endpoints are for the [pprof](https://github.com/google/pprof) profiling tool.
+
+## pprof
+
+**URL** : `/debug/pprof/`
+
+**Method** : `GET`
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```text
+/debug/pprof/
+
+Types of profiles available:
+Count Profile
+273 allocs
+0 block
+0 cmdline
+78 goroutine
+273 heap
+0 mutex
+0 profile
+29 threadcreate
+0 trace
+full goroutine stack dump
+Profile Descriptions:
+
+allocs: A sampling of all past memory allocations
+block: Stack traces that led to blocking on synchronization primitives
+cmdline: The command line invocation of the current program
+goroutine: Stack traces of all current goroutines
+heap: A sampling of memory allocations of live objects. You can specify the gc GET parameter to run GC before taking the heap sample.
+mutex: Stack traces of holders of contended mutexes
+profile: CPU profile. You can specify the duration in the seconds GET parameter. After you get the profile file, use the go tool pprof command to investigate the profile.
+threadcreate: Stack traces that led to the creation of new OS threads
+trace: A trace of execution of the current program. You can specify the duration in the seconds GET parameter. After you get the trace file, use the go tool trace command to investigate the trace.
+```
+
+## Heap
+
+**URL** : `/debug/pprof/heap`
+
+**Method** : `GET`
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```proto
+// binary data from proto
+```
+
+## Thread create
+
+**URL** : `/debug/pprof/threadcreate`
+
+**Method** : `GET`
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```proto
+// binary data from proto
+```
+
+## Goroutine
+
+**URL** : `/debug/pprof/goroutine`
+
+**Method** : `GET`
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```proto
+// binary data from proto
+```
+
+## Allocations
+
+**URL** : `/debug/pprof/allocs`
+
+**Method** : `GET`
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```proto
+// binary data from proto
+```
+
+## Block
+
+**URL** : `/debug/pprof/block`
+
+**Method** : `GET`
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```proto
+// binary data from proto
+```
+
+## Mutex
+
+**URL** : `/debug/pprof/mutex`
+
+**Method** : `GET`
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```proto
+// binary data from proto
+```
+
+## Cmdline
+
+**URL** : `/debug/pprof/cmdline`
+
+**Method** : `GET`
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```proto
+// binary data from proto
+```
+
+## Profile
+
+**URL** : `/debug/pprof/profile`
+
+**Method** : `GET`
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```proto
+// binary data from proto
+```
+
+## Symbol
+
+**URL** : `/debug/pprof/symbol`
+
+**Method** : `GET`
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```proto
+// binary data from proto
+```
+
+## Trace
+
+**URL** : `/debug/pprof/trace`
+
+**Method** : `GET`
+
+### Success response
+
+**Code** : `200 OK`
+
+**Content examples**
+
+```proto
+// binary data from proto
+```
diff --git a/versioned_docs/version-1.3.0/archived_design/cross_queue_preemption.md b/versioned_docs/version-1.3.0/archived_design/cross_queue_preemption.md
new file mode 100644
index 0000000000..51c803308a
--- /dev/null
+++ b/versioned_docs/version-1.3.0/archived_design/cross_queue_preemption.md
@@ -0,0 +1,126 @@
+---
+id: cross_queue_preemption
+title: Cross Queue Preemption
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+## Problems:
+
+According to lessons we learned from YARN Scheduler preemption.
+
+**Here're top bad things:**
+
+- Preemption is a shotgun instead of a sniper, when a preemption decision is made, nobody knows if preempted resources will go to demanding queue/app/user or not.
+- Preemption logic and allocation is different, we have to implement (and mimic) what we have done in scheduler allocation logic.
+
+**Here're top good things:**
+
+- Preemption is fast (thanks to the shotgun), reclaiming thousands of containers only takes ~ 1 sec.
+- We have understand how painful it is to handle DRF, multiple preemption policies (inter/intra-queue, shotgun/surgical preemption, etc.) And we have developed some good logic
+to make sure better modularization and plug-ability
+
+## Answer some questions for design/implementation choices
+
+**1\. Do we really want preemption-delay? (Or we just want to control pace)**
+
+In CS, we have preemption-delay, which select victims in preemption candidates, wait for a certain time before killing it.
+
+The purposes of preemption delay are: a. give heads-up time to apps so
+they can prepare bad things happen (unfortunately no app do anything for these heads up, at least from what I knew). b. control preemption pace.
+
+And in practice, I found it causes a lot of issues, for example when a
+cluster state keep changing, it is very hard to ensure accurate preemption.
+
+**Proposal:**
+
+Remove the preemption-delay, keep the logics of controlling preemption pace. (such as ```yarn.resourcemanager.monitor.capacity.preemption
+.total_preemption_per_round```). And we can do allocation together with preemption.
+This don't mean containers will be stopped immediately after preemption issued. Instead, RM can control delays between signal a container and kill a container. Such as grace
+termination of POD in K8s: https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods
+
+**2\. Do we want to do preemption for every scheduling logic, or we can do periodically?**
+
+In CS, we have preemption logic runs periodically, like every 1 sec or 3 sec.
+
+Since preemption logic involves some heavy logics, like calculating shares of queues/apps. And when doing accurate preemption, we may need to scan nodes for preemption candidate.
+Considering this, I propose to have preemption runs periodically. But it is important to note that, we need to try to use as much code as possible for
+allocation-inside-preemption, otherwise there will be too much duplicated logic and very hard to be maintained in the future.
+
+**3\. Preemption cost and function**
+
+We found it is helpful to add cost for preemption, such as container live time, priority, type of container. It could be a cost function (Which returns a numeric value) or it
+could be a comparator (which compare two allocations for preemption ask).
+
+## Pseudo code
+
+Logic of allocation (invoked every allocation cycle)
+
+```
+input:
+ - nAlloc, allocate N allocations for this allocation cycle.
+
+for partition:
+ askCandidates := findAskCandidates(nAlloc, preemption=false)
+
+ allocated, failed_to_allocated := tryAllocate(askCandidates);
+
+ send-allocated-to-cache-to-commit;
+
+ update-missed-opportunity (allocated, failed_to_allocated);
+
+ nAlloc -= len(allocated)
+```
+
+Logic of preemption (invoked every preemption cycle)
+
+```
+// It has to be done for every preemption-policy because calculation is different.
+for preemption-policy:
+ preempt_results := policy.preempt()
+ for preempt_results:
+ send-preempt-result-to-cache-to-commit;
+ updated-missed-opportunity (allocated)
+```
+
+Inside preemption policy
+
+```
+inter-queue-preempt-policy:
+ calculate-preemption-quotas;
+
+ for partitions:
+ total_preempted := resource(0);
+
+ while total_preempted < partition-limited:
+ // queues will be sorted by allocating - preempting
+ // And ignore any key in preemption_mask
+ askCandidates := findAskCandidates(N, preemption=true)
+
+ preempt_results := tryAllocate(askCandidates, preemption=true);
+
+ total_preempted += sigma(preempt_result.allocResource)
+
+ send-allocated-to-cache-to-commit;
+
+ update-missed-opportunity (allocated, failed_to_allocated);
+
+ update-preemption-mask(askCandidates.allocKeys - preempt_results.allocKeys)
+```
\ No newline at end of file
diff --git a/versioned_docs/version-1.3.0/archived_design/k8shim.md b/versioned_docs/version-1.3.0/archived_design/k8shim.md
new file mode 100644
index 0000000000..0f9a848ee5
--- /dev/null
+++ b/versioned_docs/version-1.3.0/archived_design/k8shim.md
@@ -0,0 +1,74 @@
+---
+id: k8shim
+title: Kubernetes Shim Design
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+Github repo: https://github.com/apache/yunikorn-k8shim
+
+Please read the [architecture](../design/architecture.md) doc before reading this one, you will need to understand
+the 3 layer design of YuniKorn before getting to understand what is the Kubernetes shim.
+
+## The Kubernetes shim
+
+The YuniKorn Kubernetes shim is responsible for talking to Kubernetes, it is responsible for translating the Kubernetes
+cluster resources, and resource requests via scheduler interface and send them to the scheduler core.
+And when a scheduler decision is made, it is responsible for binding the pod to the specific node. All the communication
+between the shim and the scheduler core is through the scheduler-interface.
+
+## The admission controller
+
+The admission controller runs in a separate pod, it runs a
+[mutation webhook](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)
+and a [validation webhook](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook), where:
+
+1. The `mutation webhook` mutates pod spec by:
+ - Adding `schedulerName: yunikorn`
+ - By explicitly specifying the scheduler name, the pod will be scheduled by YuniKorn scheduler.
+ - Adding `applicationId` label
+ - When a label `applicationId` exists, reuse the given applicationId.
+ - When a label `spark-app-selector` exists, reuse the given spark app ID.
+ - Otherwise, assign a generated application ID for this pod, using convention: `yunikorn-<namespace>-autogen`. This is unique per namespace.
+ - Adding `queue` label
+ - When a label `queue` exists, reuse the given queue name. Note, if placement rule is enabled, values set in the label is ignored.
+ - Otherwise, adds `queue: root.default`
+ - Adding `disableStateAware` label
+ - If pod was assigned a generated applicationId by the admission controller, also set `disableStateAware: true`. This causes the generated application
+ to immediately transition from the `Starting` to `Running` state so that it will not block other applications.
+2. The `validation webhook` validates the configuration set in the configmap
+ - This is used to prevent writing malformed configuration into the configmap.
+ - The validation webhook calls scheduler [validation REST API](api/scheduler.md#configuration-validation) to validate configmap updates.
+
+### Admission controller deployment
+
+By default, the admission controller is deployed as part of the YuniKorn Helm chart installation. This can be disabled if necessary (though not recommended) by setting the Helm parameter `embedAdmissionController` to `false`.
+
+On startup, the admission controller performs a series of tasks to ensure that it is properly registered with Kubernetes:
+1. Loads a Kubernetes secret called `admission-controller-secrets`. This secret stores a pair of CA certificates which are used to sign the TLS server certificate used by the admission controller.
+2. If the secret cannot be found or either CA certificate is within 90 days of expiration, generates new certificate(s). If a certificate is expiring, a new one is generated with an expiration of 12 months in the future. If both certificates are missing or expiring, the second certificate is generated with an expiration of 6 months in the future. This ensures that both certificates do not expire at the same time, and that there is an overlap of trusted certificates.
+3. If the CA certificates were created or updated, writes the secrets back to Kubernetes.
+4. Generates an ephemeral TLS server certificate signed by the CA certificate with the latest expiration date.
+5. Validates, and if necessary, creates or updates the Kubernetes webhook configurations named `yunikorn-admission-controller-validations` and `yunikorn-admission-controller-mutations`. If the CA certificates have changed, the webhooks will also be updated. These webhooks allow the Kubernetes API server to connect to the admission controller service to perform configmap validations and pod mutations.
+6. Starts up the admission controller HTTPS server.
+
+Additionally, the admission controller also starts a background task to wait for CA certificates to expire. Once either certificate is expiring within the next 30 days, new CA and server certificates are generated, the webhook configurations are updated, and the HTTPS server is quickly restarted. This ensures that certificates rotate properly without downtime.
+
+In production clusters, it is recommended to deploy the admission controller with two replicas by setting the Helm parameter `admissionController.replicaCount` to `2`. This will ensure that at least one admission controller webhook is reachable by the Kubernetes API server at all times. In this configuration, the CA certificates and webhook configurations are shared between the instances.
diff --git a/versioned_docs/version-1.3.0/archived_design/namespace_resource_quota.md b/versioned_docs/version-1.3.0/archived_design/namespace_resource_quota.md
new file mode 100644
index 0000000000..90830b6a17
--- /dev/null
+++ b/versioned_docs/version-1.3.0/archived_design/namespace_resource_quota.md
@@ -0,0 +1,183 @@
+---
+id: namespace_resource_quota
+title: Namespace Resource Quota
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+In K8s, user can setup namespace with [resource quotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/) to limit aggregated resource consumption in this namespace. The validation of namespace resource quotas is handled in api-server directly, therefore YuniKorn simply honors the quotas like the default scheduler.
+
+## Best practice
+
+It is not mandatory to setup YuniKorn queues with respect of namespaces.
+However, in practice, it makes more sense to do so.
+Namespace is often used to set a cap for resource consumptions per user-group/team,
+YuniKorn queue is also meant to divide cluster resource into multiple groups.
+Let's go through an example.
+
+### 1. Setup namespace
+
+Namespace: `advertisement`:
+```
+apiVersion: v1
+kind: ResourceQuota
+metadata:
+ name: advertisement
+spec:
+ hard:
+ requests.cpu: "200m"
+ requests.memory: 2000Mi
+ limits.cpu: "200m"
+ limits.memory: 4000Mi
+```
+Create the namespace
+```
+kubectl create namespace advertisement
+kubectl create -f ./advertisement.yaml --namespace=advertisement
+kubectl get quota --namespace=advertisement
+kubectl describe quota advertisement --namespace=advertisement
+
+// output
+Name: advertisement
+Namespace: advertisement
+Resource Used Hard
+-------- ---- ----
+limits.cpu 0 200m
+limits.memory 0 4000Mi
+requests.cpu 0 200m
+requests.memory 0 2000Mi
+```
+
+### 2. Setup YuniKorn queues
+
+Queue: `advertisement`:
+```
+name: advertisement
+resources:
+ guaranteed:
+ vcore: 100
+ memory: 1000
+ max:
+ vcore: 200
+ memory: 2000
+```
+
+ensure `QueueMaxResource <= NamespaceResourceQuotaRequests`
+
+### 3. Mapping applications to queues & namespace
+
+In a pod spec
+
+```
+apiVersion: v1
+kind: Pod
+metadata:
+ namespace: advertisement
+ labels:
+ app: sleep
+ applicationId: "application_2019_01_22_00001"
+ queue: "root.advertisement"
+ name: task0
+spec:
+ schedulerName: yunikorn
+ containers:
+ - name: sleep-5s
+ image: "alpine:latest"
+ command: ["/bin/ash", "-ec", "while :; do echo '.'; sleep 5 ; done"]
+ resources:
+ requests:
+ cpu: "50m"
+ memory: "800M"
+ limits:
+ cpu: "100m"
+ memory: "1000M"
+```
+
+Check Quota
+
+```
+kubectl describe quota advertisement --namespace=advertisement
+
+Name: advertisement
+Namespace: advertisement
+Resource Used Hard
+-------- ---- ----
+limits.cpu 100m 200m
+limits.memory 1G 4000Mi
+requests.cpu 50m 200m
+requests.memory 800M 2000Mi
+```
+
+Now submit another application,
+
+```
+apiVersion: v1
+kind: Pod
+metadata:
+ namespace: advertisement
+ labels:
+ app: sleep
+ applicationId: "application_2019_01_22_00002"
+ queue: "root.advertisement"
+ name: task1
+spec:
+ schedulerName: yunikorn
+ containers:
+ - name: sleep-5s
+ image: "alpine:latest"
+ command: ["/bin/ash", "-ec", "while :; do echo '.'; sleep 5 ; done"]
+ resources:
+ requests:
+ cpu: "200m"
+ memory: "800M"
+ limits:
+ cpu: "200m"
+ memory: "1000M"
+```
+
+pod will not be able to submitted to api-server, because the requested cpu `200m` + used cpu `100m` = `300m` which exceeds the resource quota.
+
+```
+kubectl create -f pod_ns_adv_task1.yaml
+Error from server (Forbidden): error when creating "pod_ns_adv_task1.yaml": pods "task1" is forbidden: exceeded quota: advertisement, requested: limits.cpu=200m,requests.cpu=200m, used: limits.cpu=100m,requests.cpu=50m, limited: limits.cpu=200m,requests.cpu=200m
+```
+
+## Future Work
+
+For compatibility, we should respect namespaces and resource quotas.
+Resource quota is overlapped with queue configuration in many ways,
+for example the `requests` quota is just like queue's max resource. However,
+there are still a few features resource quota can do but queue cannot, such as
+
+1. Resource `limits`. The aggregated resource from all pods in a namespace cannot exceed this limit.
+2. Storage Resource Quota, e.g storage size, PVC number, etc.
+3. Object Count Quotas, e.g count of PVCs, services, configmaps, etc.
+4. Resource Quota can map to priority class.
+
+Probably we can build something similar to cover (3) in this list.
+But it would be hard to completely support all these cases.
+
+But currently, setting applications mapping to a queue as well as a corresponding namespace is over complex.
+Some future improvements might be:
+
+1. Automatically detects namespaces in k8s-shim and map them to queues. Behind the scenes, we automatically generates queue configuration based on namespace definition. Generated queues are attached under root queue.
+2. When new namespace added/updated/removed, similarly to (1), we automatically update queues.
+3. User can add more configuration to queues, e.g add queue ACL, add child queues on the generated queues.
+4. Applications submitted to namespaces are transparently submitted to corresponding queues.
\ No newline at end of file
diff --git a/versioned_docs/version-1.3.0/archived_design/predicates.md b/versioned_docs/version-1.3.0/archived_design/predicates.md
new file mode 100644
index 0000000000..9233a25f36
--- /dev/null
+++ b/versioned_docs/version-1.3.0/archived_design/predicates.md
@@ -0,0 +1,80 @@
+---
+id: predicates
+title: Support K8s Predicates
+---
+
+<!--
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+-->
+
+## Design
+
+Predicates are a set of pre-registered functions in K8s, the scheduler invokes these functions to check if a pod
+is eligible to be allocated onto a node. Common predicates are: node-selector, pod affinity/anti-affinity etc. To support
+these predicates in YuniKorn, we don't intend to re-implement everything on our own, but to re-use the core predicates
+code as much as possible.
+
+YuniKorn-core is agnostic about underneath RMs, so the predicates functions are implemented in K8s-shim as a `SchedulerPlugin`.
+SchedulerPlugin is a way to plug/extend scheduler capabilities. Shim can implement such plugin and register itself to
+yunikorn-core, so plugged function can be invoked in the scheduler core. Find all supported plugins in
+[types](https://github.com/apache/yunikorn-core/blob/master/pkg/plugins/types.go).
+
+## Workflow
+
+First, RM needs to register itself to yunikorn-core, it advertises what scheduler plugin interfaces are supported.
+E.g a RM could implement `PredicatePlugin` interface and register itself to yunikorn-core. Then yunikorn-core will
+call PredicatePlugin API to run predicates before making allocation decisions.
+
+
+Following workflow demonstrates how allocation looks like when predicates are involved.
+
+```
+pending pods: A, B
+shim sends requests to core, including A, B
+core starts to schedule A, B
+ partition -> queue -> app -> request
+ schedule A (1)
+ run predicates (3)
+ generate predicates metadata (4)
+ run predicate functions one by one with the metadata
+ success
+ proposal: A->N
+ schedule B (2)
+ run predicates (calling shim API)
+ generate predicates metadata
+ run predicate functions one by one with the metadata
+ success
+ proposal: B->N
+commit the allocation proposal for A and notify k8s-shim
+commit the allocation proposal for B and notify k8s-shim
+shim binds pod A to N
+shim binds pod B to N
+```
+
+(1) and (2) are running in parallel.
+
+(3) yunikorn-core calls a `schedulerPlugin` API to run predicates, this API is implemented on k8s-shim side.
+
+(4) K8s-shim generates metadata based on current scheduler cache, the metadata includes some intermittent states about nodes and pods.
+
+## Predicates White-list
+
+Intentionally, we only support a white-list of predicates. Majorly due to 2 reasons,
+* Predicate functions are time-consuming, it has negative impact on scheduler performance. To support predicates that are only necessary can minimize the impact. This will be configurable via CLI options;
+* The implementation depends heavily on K8s default scheduler code, though we reused some unit tests, the coverage is still a problem. We'll continue to improve the coverage when adding new predicates.
+
+The white-list currently is defined in [PredicateManager](https://github.com/apache/yunikorn-k8shim/blob/master/pkg/plugin/predicates/predicate_manager.go).
diff --git a/versioned_docs/version-1.3.0/archived_design/scheduler_core_design.md b/versioned_docs/version-1.3.0/archived_design/scheduler_core_design.md
new file mode 100644
index 0000000000..c3da548c03
--- /dev/null
+++ b/versioned_docs/version-1.3.0/archived_design/scheduler_core_design.md
@@ -0,0 +1,401 @@
+---
+id: scheduler_core_design
+title: Scheduler Core Design
+---
+
+<!--
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ -->
+
+:::caution
+The scheduler core design has changed. [YUNIKORN-317](https://issues.apache.org/jira/browse/YUNIKORN-317) was committed and has removed the scheduler cache.
+This document will not be maintained and is just for historical reference.
+See [scheduler cache removal design](../design/cache_removal.md)
+:::
+
+Github repo: https://github.com/apache/yunikorn-core
+
+Scheduler core encapsulates all scheduling algorithms, it collects resources from underneath resource management
+platforms (like YARN/K8s), and is responsible for container allocation requests. It makes the decision where is the
+best spot for each request and then sends response allocations to the resource management platform.
+Scheduler core is agnostic about underneath platforms, all the communications are through the [scheduler interface](https://github.com/apache/yunikorn-scheduler-interface).
+
+## Components:
+
+```
+
+ +---------------+ +--------------+
+ |K8s Shim | |YARN Shim |
+ +---------------+ +--------------+
+
+ +--------------+ +------------+
+ Scheduler- | GRPC Protocol| |Go API |
+ Interface: +--------------+ +------------+
+
++---------------------------------------------------------------------------+
+ +--------------------+
+ |Scheduler API Server|
+ +-------------+ +---------+----------+
+ |AdminService | |
+ +-------------+ |Write Ops +----------------+
+ +-------------+ V ++Scheduler |
+ |Configurator | +-------------------+ Allocate || And |
+ +-------------+ |Cache Event Handler+<-----------------| |
+ +----------> +-------------------+ Preempt ++Preemptor |
+ Update Cfg Handled by policies +----------------+
+ + (Stateless)
+ +------v--------+
+ |Scheduler Cache|
+ +---------------+
+ +---------------------------------------------+
+ |--------+ +------+ +----------+ +----------+ |
+ ||Node | |Queue | |Allocation| |Requests | |
+ |--------+ +------+ +----------+ +----------+ |
+ +---------------------------------------------+
+```
+
+### Scheduler API Server (RMProxy)
+
+Responsible for communication between RM and Scheduler, which implements scheduler-interface GRPC protocol,
+or just APIs. (For intra-process communication w/o Serde).
+
+### Scheduler Cache
+
+Caches all data related to scheduler state, such as used resources of each queues, nodes, allocations.
+Relationship between allocations and nodes, etc. Should not include in-flight data for resource allocation.
+For example to-be-preempted allocation candidates. Fair share resource of queues, etc.
+
+### Scheduler Cache Event Handler
+
+Handles all events which needs to update scheduler internal state. So all the write operations will be carefully handled.
+
+### Admin Service
+
+Handles request from Admin, which can also load configurations from storage and update scheduler policies.
+
+### Scheduler and Preemptor
+
+Handles Scheduler's internal state. (Which is not belong to scheduelr cache), such as internal reservations, etc.
+Scheduler and preemptor will work together, make scheduling or preemption decisions. All allocate/preempt request
+will be handled by event handler.
+
+## Scheduler's responsibility
+
+- According to resource usages between queues, sort queues, applications, and figure out order of application allocation. (This will be used by preemption as well).
+- It is possible that we cannot satisfy some of the allocation request, we need to skip them and find next request.
+- It is possible that some allocation request cannot be satisfied because of resource fragmentation. We need to reserve room for such requests.
+- Different nodes may belong to different disjoint partitions, we can make independent scheduler runs
+- Be able to config and change ordering policies for apps, queues.
+- Application can choose their own way to manage sort of nodes.
+
+## Preemption
+
+- It is important to know "who wants the resource", so we can do preemption based on allocation orders.
+- When do preemption, it is also efficient to trigger allocation op. Think about how to do it.
+- Preemption needs to take care about queue resource balancing.
+
+## Communication between Shim and Core
+
+YuniKorn-Shim (like https://github.com/apache/yunikorn-k8shim) communicates with core by
+using scheduler-interface (https://github.com/apache/yunikorn-scheduler-interface).
+Scheduler interface has Go API or GRPC. Currently, yunikorn-k8shim is using Go API to communicate with yunikorn-core
+to avoid extra overhead introduced by GRPC.
+
+**Shim (like K8shim) first need to register with core:**
+
+```go
+func (m *RMProxy) RegisterResourceManager(request *si.RegisterResourceManagerRequest, callback api.ResourceManagerCallback) (*si.RegisterResourceManagerResponse, error)
+```
+
+Which indicate ResourceManager's name, a callback function for updateResponse. The design of core is be able to do scheduling for multiple clusters (such as multiple K8s cluster) just with one core instance.
+
+**Shim interacts with core by invoking RMProxy's Update API frequently, which updates new allocation request, allocation to kill, node updates, etc.**
+
+```go
+func (m *RMProxy) Update(request *si.UpdateRequest) error
+```
+
+Response of update (such as new allocated container) will be received by registered callback.
+
+## Configurations & Semantics
+
+Example of configuration:
+
+- Partition is name space.
+- Same queues can under different partitions, but enforced to have same hierarchy.
+
+ Good:
+
+ ```
+ partition=x partition=y
+ a a
+ / \ / \
+ b c b c
+ ```
+
+ Good (c in partition y acl=""):
+
+ ```
+ partition=x partition=y
+ a a
+ / \ /
+ b c b
+ ```
+
+ Bad (c in different hierarchy)
+
+ ```
+ partition=x partition=y
+ a a
+ / \ / \
+ b c b d
+ /
+ c
+ ```
+
+ Bad (Duplicated c)
+
+ ```
+ partition=x
+ a
+ / \
+ b c
+ /
+ c
+
+ ```
+
+- Different hierarchies can be added
+
+ ```scheduler-conf.yaml
+ partitions:
+ - name: default
+ queues:
+ root:
+ configs:
+ acls:
+ childrens:
+ - a
+ - b
+ - c
+ - ...
+ a:
+ configs:
+ acls:
+ capacity: (capacity is not allowed to set for root)
+ max-capacity: ...
+ mapping-policies:
+ ...
+ - name: partition_a:
+ queues:
+ root:...
+ ```
+
+## How scheduler do allocation
+
+Scheduler runs a separate goroutine to look at asks and available resources, and do resource allocation. Here's allocation logic in pseudo code:
+
+Entry point of scheduler allocation is `scheduler.go: func (s *Scheduler) schedule()`
+
+```
+# First of all, YuniKorn has partition concept, a logical resource pool can consists
+# of one of multiple physical dis-joint partitions. It is similar to YARN's node
+# partition concept.
+
+for partition : partitions:
+ # YuniKorn can reserve allocations for picky asks (such as large request, etc.)
+ # Before doing regular allocation, YuniKorn look at reservedAllocations first.
+ for reservedAllocation : partition.reservedAllocations:
+ reservedAllocation.tryAllocate(..)
+
+ # After tried all reserved allocation, YuniKorn will go to regular allocation
+ partition.tryAllocate(..)
+
+ # If there's any allocation created, scheduler will create an AllocationProposal
+ # and send to Cache to "commit" the AllocationProposal
+```
+
+**Allocation by hierchical of queues**
+
+Inside `partition.tryAllocate`
+
+It recursively traverse from root queue and down to lower level, for each level, logic is inside `pkg/scheduler/scheduling_queue.go func (sq *SchedulingQueue) tryAllocate`
+
+Remember YuniKorn natively supports hierarchical of queues. For ParentQueue (which has sub queues under the parent queue), it uses queue's own sorting policy to sort subqueues and try to allocate from most preferred queue to least-preferred queue.
+
+For LeafQueue (which has applications inside the queue), it uses queue's own sorting policy to sort applications belong to the queue and allocate based on the sorted order.
+
+(All sorting policies can be configured differently at each level.)
+
+**Allocation by application**
+
+When it goes to Application, see (`scheduler_application.go: func (sa *SchedulingApplication) tryAllocate`), It first sort the pending resource requests belong to the application (based on requests' priority). And based on the selected request, and configured node-sorting policy, it sorts nodes belong to the partition and try to allocate resources on the sorted nodes.
+
+When application trying to allocate resources on nodes, it will invokes PredicatePlugin to make sure Shim can confirm the node is good. (For example K8shim runs predicates check for allocation pre-check).
+
+**Allocation completed by scheduler**
+
+Once allocation is done, scheduler will create an AllocationProposal and send to Cache to do further check, we will cover details in the upcoming section.
+
+## Flow of events
+
+Like mentioned before, all communications between components like RMProxy/Cache/Schedulers are done by using async event handler.
+
+RMProxy/Cache/Scheduler include local event queues and event handlers. RMProxy and Scheduler have only one queue (For example: `pkg/scheduler/scheduler.go: handleSchedulerEvent`), and Cache has two queues (One for events from RMProxy, and one for events from Scheduler, which is designed for better performance).
+
+We will talk about how events flowed between components:
+
+**Events for ResourceManager registration and updates:**
+
+```
+Update from ResourceManager -> RMProxy -> RMUpdateRequestEvent Send to Cache
+New ResourceManager registration -> RMProxy -> RegisterRMEvent Send to Cache
+```
+
+**Cache Handles RM Updates**
+
+There're many fields inside RM Update event (`RMUpdateRequestEvent`), among them, we have following categories:
+
+```
+1) Update for Application-related updates
+2) Update for New allocation ask and release.
+3) Node (Such as kubelet) update (New node, remove node, node resource change, etc.)
+```
+
+More details can be found at:
+
+```
+func (m *ClusterInfo) processRMUpdateEvent(event *cacheevent.RMUpdateRequestEvent)
+
+inside cluster_info.go
+```
+
+**Cache send RM updates to Scheduler**
+
+For most cases, Cache propagate updates from RM to scheduler directly (including Application, Node, Asks, etc.). And it is possible that some updates from RM is not valid (such as adding an application to a non-existed queue), for such cases, cache can send an event back to RMProxy and notify the ResourceManager. (See `RMApplicationUpdateEvent.RejectedApplications`)
+
+**Cache handles scheduler config**
+
+Cache also handles scheduler's config changes, see
+
+```go
+func (m *ClusterInfo) processRMConfigUpdateEvent(event *commonevents.ConfigUpdateRMEvent)
+```
+
+Similar to other RM updates, it propages news to scheduelr.
+
+**Scheduler do allocation**
+
+Once an AllocationProposal created by scheduler, scheduler sends `AllocationProposalBundleEvent` to Cache to commit.
+
+Cache look at AllocationProposal under lock, and commit these proposals. The reason to do proposal/commit is Scheduler can run in multi-threads which could cause conflict for resource allocation. This approach is inspired by Borg/Omega/YARN Global Scheduling.
+
+Cache checks more states such as queue resources, node resources (we cannot allocate more resource than nodes' available), etc. Once check is done, Cache updates internal data strcture and send confirmation to Scheduler to update the same, and scheduler sends allocated Allocation to RMProxy so Shim can do further options. For example, K8shim will `bind` an allocation (POD) to kubelet.
+
+```
+Job Add:
+--------
+RM -> Cache -> Scheduler (Implemented)
+
+Job Remove:
+-----------
+RM -> Scheduler -> Cache (Implemented)
+Released allocations: (Same as normal release) (Implemented)
+Note: Make sure remove from scheduler first to avoid new allocated created.
+
+Scheduling Request Add:
+-----------------------
+RM -> Cache -> Scheduler (Implemented)
+Note: Will check if requested job exists, queue exists, etc.
+When any request invalid:
+ Cache -> RM (Implemented)
+ Scheduler -> RM (Implemented)
+
+Scheduling Request remove:
+-------------------------
+RM -> Scheduler -> Cache (Implemented)
+Note: Make sure removed from scheduler first to avoid new container allocated
+
+Allocation remove (Preemption)
+-----------------
+Scheduler -> Cache -> RM (TODO)
+ (confirmation)
+
+Allocation remove (RM voluntarilly ask)
+---------------------------------------
+RM -> Scheduler -> Cache -> RM. (Implemented)
+ (confirmation)
+
+Node Add:
+---------
+RM -> Cache -> Scheduler (Implemented)
+Note: Inside Cache, update allocated resources.
+Error handling: Reject Node to RM (Implemented)
+
+Node Remove:
+------------
+Implemented in cache side
+RM -> Scheduler -> Cache (TODO)
+
+Allocation Proposal:
+--------------------
+Scheduler -> Cache -> RM
+When rejected/accepted:
+ Cache -> Scheduler
+
+Initial: (TODO)
+--------
+1. Admin configured partitions
+2. Cache initializes
+3. Scheduler copies configurations
+
+Relations between Entities
+-------------------------
+1. RM includes one or multiple:
+ - Partitions
+ - Jobs
+ - Nodes
+ - Queues
+
+2. One queue:
+ - Under one partition
+ - Under one RM.
+
+3. One job:
+ - Under one queue (Job with same name can under different partitions)
+ - Under one partition
+
+RM registration: (TODO)
+----------------
+1. RM send registration
+2. If RM already registered, remove old one, including everything belong to RM.
+
+RM termination (TODO)
+--------------
+Just remove the old one.
+
+Update of queues (TODO)
+------------------------
+Admin Service -> Cache
+
+About partition (TODO)
+-----------------------
+Internal partition need to be normalized, for example, RM specify node with partition = xyz.
... 12642 lines suppressed ...
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: issues-help@yunikorn.apache.org