You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@yunikorn.apache.org by GitBox <gi...@apache.org> on 2022/01/16 08:11:16 UTC
[GitHub] [incubator-yunikorn-site] cdmikechen opened a new pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
cdmikechen opened a new pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108
At present, most website pages and some design documents have been completed.
This is a great project. It is expected to improve the subsequent parts before version 1.0.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] cdmikechen commented on a change in pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
cdmikechen commented on a change in pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#discussion_r785641289
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/design/gang_scheduling.md
##########
@@ -0,0 +1,608 @@
+---
+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.
+ -->
+# 帮派调度实现
+一种新的调度应用程序的方法，它考虑了应用程序随着时间的推移预计会产生的资源需求。
+它通过预留资源来保证应用程序的预期需求资源。
+
+这个实现有两个部分：
+* Kubernetes Shim
+* Core（以后成为核心）和 scheduling (调度)
+
+本文档描述了核心端的实现。
+
+## 文档目标
+本文档描述了以下实现设计要点：
+1. 定义 shim 到核心通信所需的调整（调度器接口）
+2. 调度器存储对象变化
+3. 调度器逻辑变化
+
+## 排除的设计点
+目前，本设计文档未涵盖 Kubernetes shim 端实现。
+
+本设计将 _不_ 讨论核心端的广义抢占。
+
+## 通用流程
+该流由提交的 pod 触发，该 pod 触发应用程序创建。
+在 Spark 应用程序中，第一个 Pod 是驱动程序 Pod。
+如果流程是从应用程序 CRD 的创建触发的，则不会有第一个 pod。
+然而，这超出了核心调度逻辑。从核心方面来看，这两种情况应该没有区别。
+更多细节在 [调度器逻辑更改](#scheduler-logic-changes) 章节中。
+
+提交申请的流程。图中的数字对应于图下方的描述。
+
+
+
+应用程序启动期间shim和核心的组合流程：
+* 提交的应用程序定义了任务组。 (1)
+* shim 创建应用程序并将应用程序传递给核心。 (2)
+* shim 为任务组的每个成员创建 placeholder（占位）pod。 (3)
+* 按照正常行为，pod 作为具有正确信息集的应用程序的 AllocationAsk（资源分配请求）被处理并传递给核心。 (4)
+* 占位 AllocationAsk 由核心调度，就好像它们是正常的 AllocationAsk 一样。 (5)
+* 所有分配，即使它们是由调度器分配的占位 AllocationAsks 的结果，也会被传送回 shim。
+* 原始的实际 pod 作为 AllocationAsk 传递给核心。 (6)
+* 在实际 pod 和所有占位 pod 被调度后，shim 启动触发应用程序创建实际 pod。 (7)
+
+在第一个实际 pod 启动后，以下 pod 都应该以相同的方式处理 (8)：
+* 在 k8s 上创建了一个实际 pod。
+* 处理 pod 并创建一个 AllocationAsk。
+* 调度器处理 AllocationAsk（更多细节见下文）并用实际分配替换预留资源。
+
+## 应用提交处理
+### 预留资源总大小
+
+如果请求一个或多个任务组，应用程序应该提供它要请求的所有任务组成员的总大小。
+如果应用程序在限制了资源的队列中被调度，则需要总资源大小。
+
+该值对于三种情况很重要：
+1. 帮派请求大于队列配额
+2. 开始预调度
+3. 预调度时的资源压力
+
+进一步的细节将在下面的 [在设置了配额的队列中进行调度](#scheduling-in-queues-with-a-quota-set) 中给出
+
+从 shim 传递的信息应该是 AddApplicationRequest 中的一部分。
+任务组的建立或成员数量的详细信息不相关。
+所有任务组成员请求的总资源使用以下方法计算：
+
+
+
+placeholderAsk（占位/资源预留请求）的总计信息作为可选字段添加到 AddApplicationRequest 消息中。
+可以由 shim 根据 pod 描述中提供的 CRD 或注释进行计算。
+
+如果占位请求大于队列上设置的队列配额，则必须拒绝申请。
+这种拒绝是基于我们不能以任何方式满足请求的事实。
+对于所有其他情况，会接受申请并进行正常的安排。
+
+### 使用 FAIR（公平）排序策略处理队列
+Queue sorting for the queue that the application runs in must be set to _FIFO_ or _StateAware_.
+如果将应用程序提交到设置了 FAIR 排序策略的队列，则必须拒绝该应用程序。
+应用程序运行所在队列的队列排序必须设置为 _FIFO_ 或 _StateAware_。
+
+其他队列策略不能保证一次只处理一个 _新的_ 应用程序。
+在 _公平_ 策略的情况下，我们可以同时分配多个 _新的_ 应用程序，从而无法强制实施配额管理。
+使用 _公平_ 策略的另一个副作用可能是我们得到多个应用程序但只有部分能保证分配。
+
+由于核心无法将占位情况放置在任何节点上，因此可以触发自动缩放。
+如果队列使用 _公平_ 排序，这可能会导致其他应用程序使用放大的节点而不是预留资源从而再次破坏帮派调度。
+
+## 在设置了配额的队列中进行调度
+上面已经描述的主要情况是处理大于队列上设置的配额的总占位请求大小。
+提交申请时，我们已经可以评估我们无法满足该要求并拒绝该请求。
+
+在总占位请求确实适合队列的情况下，我们不应该开始调度，直到队列中有足够的可用资源来满足总请求。
+然而，这不会停止对队列中其他应用程序的调度。
+已在队列中运行的应用程序可能会请求更多资源。
+从应用程序的角度来看，它可以请求的资源没有限制。
+应用程序上定义的联邦是有保证的资源数量，而不是应用程序可以请求的最大资源数量。
+
+我们拥有的队列层次结构是很复杂的。
+配额可能不是直接在应用程序运行的队列上设置的。
+它可以设置在某一个父队列上面。
+这种情况可能会变得复杂，我们需要保证记住我们可以实时锁定调度。
+
+在第一阶段中，我们应该关注这样一种情况，即请求的联邦资源也是应用程序将请求的最大资源数。
+当我们查看队列时，我们应该关注具有配额的单个队列级别。
+
+这两个假设对于没有使用从命名空间到队列的动态映射进行动态分配的 spark 用例是正确的。
+
+此外，我们假设队列上设置的配额可以完全分配。
+如果集群没有足够的资源，集群将扩展，直到为所有队列提供全部配额所需的大小。
+
+这也可以在某些用例中利用抢占，例如抢占应用程序超过其总的联邦大小的分配。
+在某些用例中，也可以利用抢占，比如在应用程序的总帮派规模上抢占分配。
+
+通过允许指定时间和应用程序来等待占位分配，或开始使用保留资源的时间，可以添加进一步的增强功能。
+
+## 调度器逻辑变化
+调度器逻辑的变化需要考虑周期的两个部分：
+* 占位请求及其分配。
+* 替换占位的分配。
+
+我们的基本假设是所有 pod 都会向核心生成占位 pod 请求。
+如果我们不使用应用程序 CRD，这包括触发应用程序创建的 pod。
+这个假设是必须的，才能确保调度器核心可以在提交应用程序的两种方式中以相同的方式运行。
+占位 Pod 必须在真正的 Pod 之前与核心通信。
+
+更改占位 AllocationAsks 是第一步。
+作为应用程序创建的一部分，AllocationAsks 被添加。
+添加 AllocationsAsk 通常会根据调度周期触发应用程序状态的更改。
+它将应用程序从 _New_ 状态移动到 _Accepted_ 状态。这与当前设置一致，并且不会更改。
+
+但是，在 AllocationAsk 设置了 _placeholder_ 标志的情况下，分配不应触发状态更改，应用程序保持在 _Accepted_ 状态。
+处理分配请求，直到应用程序没有 pending （挂起）的资源。
+作为安全预防措施，应忽略未设置 _placeholder_ 标志的 AllocationAsk。
+占位 Pod 的所有结果分配都按照正常步骤向 shim 确认。
+这个过程一直持续到没有更多的占位 pod 被分配。
+
+此时的 shim 应为已缓冲的真实 pod 创建分配任务。
+核心不能也不需假设每个应用程序只有一个任务组。
+如果 shim 使用了上述选项1，则核心也无法假设它已收到属于任务组的所有分配任务。
+这也是为什么我们假设每个 pod 都会向核心创建一个占位请求。
+
+第二个变化是用真正的 pod 替换了占位 pod。
+填充程序创建了一个设置了 _任务组名称_ 但未设置 _placeholder_ 标志的 AllocationAsk。
+
+这里描述的过程与通用抢占的过程一致。
+分配由核心释放，然后由 shim 确认。
+对于帮派调度，我们有一个简单的一对一释放关系，在抢占的情况下，我们可以使用具有一对多释放关系的相同流程。
+
+调度器按如下方式处理 AllocationAsk：
+1. 检查应用程序是否有未释放的分配给具有相同 _任务组名称_ 的占位分配。如果没有找到占位分配，将使用正常的分配周期来分配请求。
+2. 一个占位分配被选择并标记为释放。释放占位分配的请求被传送到 shim。这必须是一个异步过程，因为 shim 释放过程取决于底层的 K8s 响应，这可能不是即时的。
+ 注意：此时核心中没有释放任何分配。
+3. 核心“暂停”处理真正的 AllocationAsk，直到 shim 响应确认已释放占位分配。
+ 注意：释放锁以允许调度继续
+4. 在收到来自 shim 的释放确认后，“暂停的” AllocationAsk 处理会结束。
+5. AllocationAsk 分配在与使用的占位相同的节点上。
+ 在任何一种情况下，占位分配的删除都将完成。这一切都需要作为对应用程序、队列和节点的一次更新来实现。
+ * 成功时：创建一个新的分配。
+ * 失败时：尝试在不同的节点上分配，如果失败，AllocationAsk 变得不可调度，并触发扩展。
+6. 将分配传达回shim（如果适用，基于步骤 5）
+
+## 应用程序完成
+应用程序完成一直是一个长期存在的问题。
+目前，应用程序在完成时不会转换到 _completed_ 状态。
+应用程序的当前状态是 [参考文档](./scheduler_object_states.md)。
+但是，此时应用程序将不会达到 _completed_ 状态，而是停留在 _waiting_ 状态。
+
+这提供了许多问题，特别是在长时间运行部署中的内存使用和队列清理的情况下。
+
+### 定义
+由于我们不能依赖在 Kubernetes 上作为 Pod 运行的应用程序来表明它已经完成，因此我们需要定义何时考虑一个应用程序的 _完成_ 。
+在这一点上，我们定义了一个应用程序在定义的时间段内处于 _等待_ 状态时，它会变成 _完成_ 。
+当没有活动分配（已分配资源 > 0）和挂起分配请求（挂起资源 > 0）时，应用程序进入等待状态。
+
+向 _waiting_ 状态的转换已经实现。
+_waiting_ 状态的超时是一项新的功能。
+
+资源预留不被视为活动分配。
+占位请求被视为待处理的资源请求。
+这些情况将在下面的 [清理](#Cleanup) 中处理。
+
+### 清理
+当我们查看帮派调度时，还有一个关于未使用的预留资源、占位请求及其清理的问题。
+预留资源可以在有待处理分配请求或活动分配的任何时候转换为实际分配。
+
+在处理实际分配之前，占位请求将全部转换为占位分配。
+
+进入 _waiting_ 状态已被处理。
+如果将新的分配请求添加到应用程序中，它将转换回 _running_ 状态。
+当我们进入了等待状态，将没有待处理的请求或分配的资源。
+只有可以分配的预留资源。
+
+为了进入 _waiting_ 状态，应用程序必须是干净的。
+但是，我们不能保证在应用程序运行期间应用程序将使用所有预留资源。
+从 _waiting_ 状态转换到 _completed_ 状态根本不需要（占位）分配或请求。
+影响转换的第二种情况是并非所有占位请求都被分配，因此应用程序从不请求任何真正的分配。
+这两种情况可能会阻止应用程序转换出 _accepted_ 或 _waiting_ 状态。
+
+因此，核心中的处理需要考虑两种会影响特定状态的转换的情况：
+1. 占位请求挂起（退出 _accepted_ ）
+2. 占位分配（退出 _waiting_ ）
+
+占位请求挂起：
+挂起的占位符是通过超时来处理的。
+应用程序只能花费有限的时间等待分配所有预留资源。
+这个超时是必需的，因为应用程序的部分占位分配可能会占用集群资源而没有真正使用它们。
+
+应用程序可能排队等待未知时间，等待占位分配开始。
+因此，占位请求的超时不能与应用程序或请求的创建相关联。
+超时必须在分配第一个占位请求时开始。
+
+在所有占位请求都被分配之前，应用程序不能请求真正的分配。
+占位请求也由 shim 跟踪，因为它代表一个 pod。
+在核心中释放请求需要消息在核心和 shim 之间流动以释放该请求。
+但是，在这种情况下，分配预留资源的超时会触发应用程序失败。
+当超时被触发并且占位请求挂起时，应用程序将从它所处的状态转换为 _killed_ 。
+
+本案例的应用状态可以概括为：
+* 申请状态为 _accepted_
+* 占位分配的资源大于零，并且小于 _AddApplicationRequest_ 中的 _placeholderAsk_
+* 待处理资源请求大于零
+
+进入 _killed_ 状态必须自动将应用程序移出队列。
+
+状态更改和占位分配释放可以在单个更新响应消息中处理。 该消息将包含以下内容：
+* _UpdatedApplication_ 用于应用程序的状态变化
+* 一个或多个 _AllocationRelease_ 消息，每个占位一个，_TerminationType_ 设置为 TIMEOUT
+* 一条或多条 _TerminationType_ 设置为 TIMEOUT 的 AllocationAskRelease 消息
+
+shim 首先处理 AllocationAskRelease 消息，然后是 _AllocationResponse_ 消息，最后是 _UpdatedApplication_ 消息。应用程序状态在核心端更改为 _killed_ 状态仅取决于移除所有占位 pod，而不取决于对 _UpdatedApplication_ 消息的响应。
+
+
+
+占位超时期间 shim 和核心的组合流程：
+* 核心超时占位分配。 (1)
+* 删除占位分配被传递到 shim。 (2)
+* 所有占位分配都由 shim 释放，并传回核心。
+* 删除占位分配请求被传递给 shim。 (3)
+* 所有占位分配请求都由 shim 释放，并传回核心。
+* 在占位分配和请求被释放后，核心将应用程序移动到终止状态，将其从队列中移除 (4)。
+* 状态更改在核心和 shim 中完成。 (5)
+
+
+已分配的占位：
+剩余的占位需要由核心释放。
+需要通知 shim 将它们移除。这必须在进入 _完成_ 状态时触发。
+在核心请求释放占位之后，应用程序的状态转换可以继续。
+核心将处理从 shim 返回的占位分配的 _AllocationRelease_ 消息，并将 _TerminationType_ 设置为正常*超时*，而不会触发状态更改。
+
+状态更改和占位分配释放可以在单个更新响应消息中处理。
+该消息将包含以下内容：
+* _UpdatedApplication_ 用于应用程序的状态变化
+* 零个或多个 _AllocationRelease_ 消息，每个占位一个，_TerminationType_ 设置为 *超时*
+
+shim 首先处理 _AllocationResponse_ 消息，然后是 _UpdatedApplication_ 消息。
+应用程序状态在核心端更改为 _完成_ 状态仅依赖于所有占位 pod 的移除，而不依赖于对 _UpdatedApplication_ 消息的响应。
+
+进入 _完成_ 状态会自动将应用程序移出队列。
+这也应该处理我们之前讨论的可能延迟处理来自 shim 的请求的情况，因为我们可以在需要时从 _等待_ 移回 _执行中_ 。
+一个 _完成_ 的应用程序也不应该阻止围绕cron讨论的情况，例如每次调用使用相同的应用程序ID提交。
+具有相同申请ID的 _完成_ 申请不得阻止提交具有相同ID的新申请。
+
+
+cation to the completed state removing it from the queue (6).
+* The state change is finalised in the core and shim. (7)
+在清理应用程序期间 shim 和核心的组合流程：
+* 在 Kubernetes 层发布了一个 pod。 (1)
+* shim 将分配释放传递给核心。 (2)
+* 如果没有挂起或活动的分配，核心会将应用程序转换为等待状态。 (3)
+* 等待状态超时并触发清理。 (4)
+* 删除占位符配被传递到 shim。 (5)
+* 所有占位分配都由 shim 释放，并传回核心。
+* 释放所有占位后，核心将应用程序移动到完成状态，将其从队列中删除 (6)。
+* 状态更改在核心和 shim 中完成。 (7)
+
+## 应用恢复
+在应用程序恢复期间，占位 Pod 与节点上的任何其他 Pod 一样被恢复。
+这些 pod 由 shim 作为节点现有分配的一部分传递到核心。
+现有的分配在核心中没有相应的 _分配请求_。 核心根据恢复的信息生成 _分配请求_ 。
+
+对于联邦调度，_分配请求_ 包含 _任务组名称_ 和 _占位_ 标志。
+在恢复期间，相同的信息必须是 _分配_ 消息的一部分。
+这是因为在两个方向上使用相同的消息，从 RM 到调度器，反之亦然，这意味着我们需要更新消息及其处理。
+
+如果 _分配_ 消息中缺少信息，则恢复的分配将不会在核心中被正确标记。
+恢复的分配将被视为常规分配。
+这意味着它作为替换占位的正常分配周期的一部分被跳过。
+
+逻辑变化只需要现有分配的恢复将接口消息中的字段复制到内核中的分配对象中。
+
+## 接口变化
+需要对 shim 和核心之间的通信进行多次更改，以支持所需的帮派信息。
+
+应用程序必须提供占位请求的总大小，以防止接受永远无法运行的应用程序。
+
+从 shim 发送到核心以进行分配请求的当前对象在 AllocationAsk 中定义。
+由于从调度器核心传回的结果消息不会更改，因此分配不会更改。。但是，对于使用相同分配消息从 shim 到核心的恢复，必须包含与帮派相关的字段。
+必须将与帮派相关的字段添加到这两个消息中。
+
+分配释放请求和响应请求需要支持双向通信，并且需要进行重大更改。
+
Review comment:
@yuchaoran2011
是的，这里有两个原因。
第一个是我在翻译 gang scheduling 的时候遇到了一些困难。在我翻译的过程中发现这篇文章里面存在着很多我难以理解的句子，我结合上下文也很难翻译和猜测出来原作者的意思；同时，这里面有一些单词拼接的专有词汇我还是有一些拿捏不准，不知道是完全翻译成中文还是保留原样，因为可能这些单词在实际的代码或者使用过程中可能会有一些语义在里面，翻译成中文后反倒会让读了文章的使用者对应不上关系。
第二个是我原来的翻译顺序是按照我自己文档目录树的顺序翻译的，但是考虑到读者的阅读顺序，从website开始按照官网的顺序进行翻译可能更加好。所以我将当时翻译一半的内容先停了下来。
我个人的想法是在后续的会议中如果我参与，可能会请教一下各位前辈一些专有名词的翻译。其实有很多的专有名词已经约定俗成，在很多情况下不翻译可能让读者更好地进行理解。
当前的翻译并不是全部的，为了保证文档的完整性，我暂时将未完成的部分也追加到目录下，以防止发生文档找不到的情况
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] cdmikechen commented on pull request #108: [YUNIKORN-1031] Add Chinese translation for homepage
Posted by GitBox <gi...@apache.org>.
cdmikechen commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1020899945
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] yuchaoran2011 commented on a change in pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
yuchaoran2011 commented on a change in pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#discussion_r785644482
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/design/gang_scheduling.md
##########
@@ -0,0 +1,608 @@
+---
+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.
+ -->
+# 帮派调度实现
+一种新的调度应用程序的方法，它考虑了应用程序随着时间的推移预计会产生的资源需求。
+它通过预留资源来保证应用程序的预期需求资源。
+
+这个实现有两个部分：
+* Kubernetes Shim
+* Core（以后成为核心）和 scheduling (调度)
+
+本文档描述了核心端的实现。
+
+## 文档目标
+本文档描述了以下实现设计要点：
+1. 定义 shim 到核心通信所需的调整（调度器接口）
+2. 调度器存储对象变化
+3. 调度器逻辑变化
+
+## 排除的设计点
+目前，本设计文档未涵盖 Kubernetes shim 端实现。
+
+本设计将 _不_ 讨论核心端的广义抢占。
+
+## 通用流程
+该流由提交的 pod 触发，该 pod 触发应用程序创建。
+在 Spark 应用程序中，第一个 Pod 是驱动程序 Pod。
+如果流程是从应用程序 CRD 的创建触发的，则不会有第一个 pod。
+然而，这超出了核心调度逻辑。从核心方面来看，这两种情况应该没有区别。
+更多细节在 [调度器逻辑更改](#scheduler-logic-changes) 章节中。
+
+提交申请的流程。图中的数字对应于图下方的描述。
+
+
+
+应用程序启动期间shim和核心的组合流程：
+* 提交的应用程序定义了任务组。 (1)
+* shim 创建应用程序并将应用程序传递给核心。 (2)
+* shim 为任务组的每个成员创建 placeholder（占位）pod。 (3)
+* 按照正常行为，pod 作为具有正确信息集的应用程序的 AllocationAsk（资源分配请求）被处理并传递给核心。 (4)
+* 占位 AllocationAsk 由核心调度，就好像它们是正常的 AllocationAsk 一样。 (5)
+* 所有分配，即使它们是由调度器分配的占位 AllocationAsks 的结果，也会被传送回 shim。
+* 原始的实际 pod 作为 AllocationAsk 传递给核心。 (6)
+* 在实际 pod 和所有占位 pod 被调度后，shim 启动触发应用程序创建实际 pod。 (7)
+
+在第一个实际 pod 启动后，以下 pod 都应该以相同的方式处理 (8)：
+* 在 k8s 上创建了一个实际 pod。
+* 处理 pod 并创建一个 AllocationAsk。
+* 调度器处理 AllocationAsk（更多细节见下文）并用实际分配替换预留资源。
+
+## 应用提交处理
+### 预留资源总大小
+
+如果请求一个或多个任务组，应用程序应该提供它要请求的所有任务组成员的总大小。
+如果应用程序在限制了资源的队列中被调度，则需要总资源大小。
+
+该值对于三种情况很重要：
+1. 帮派请求大于队列配额
+2. 开始预调度
+3. 预调度时的资源压力
+
+进一步的细节将在下面的 [在设置了配额的队列中进行调度](#scheduling-in-queues-with-a-quota-set) 中给出
+
+从 shim 传递的信息应该是 AddApplicationRequest 中的一部分。
+任务组的建立或成员数量的详细信息不相关。
+所有任务组成员请求的总资源使用以下方法计算：
+
+
+
+placeholderAsk（占位/资源预留请求）的总计信息作为可选字段添加到 AddApplicationRequest 消息中。
+可以由 shim 根据 pod 描述中提供的 CRD 或注释进行计算。
+
+如果占位请求大于队列上设置的队列配额，则必须拒绝申请。
+这种拒绝是基于我们不能以任何方式满足请求的事实。
+对于所有其他情况，会接受申请并进行正常的安排。
+
+### 使用 FAIR（公平）排序策略处理队列
+Queue sorting for the queue that the application runs in must be set to _FIFO_ or _StateAware_.
+如果将应用程序提交到设置了 FAIR 排序策略的队列，则必须拒绝该应用程序。
+应用程序运行所在队列的队列排序必须设置为 _FIFO_ 或 _StateAware_。
+
+其他队列策略不能保证一次只处理一个 _新的_ 应用程序。
+在 _公平_ 策略的情况下，我们可以同时分配多个 _新的_ 应用程序，从而无法强制实施配额管理。
+使用 _公平_ 策略的另一个副作用可能是我们得到多个应用程序但只有部分能保证分配。
+
+由于核心无法将占位情况放置在任何节点上，因此可以触发自动缩放。
+如果队列使用 _公平_ 排序，这可能会导致其他应用程序使用放大的节点而不是预留资源从而再次破坏帮派调度。
+
+## 在设置了配额的队列中进行调度
+上面已经描述的主要情况是处理大于队列上设置的配额的总占位请求大小。
+提交申请时，我们已经可以评估我们无法满足该要求并拒绝该请求。
+
+在总占位请求确实适合队列的情况下，我们不应该开始调度，直到队列中有足够的可用资源来满足总请求。
+然而，这不会停止对队列中其他应用程序的调度。
+已在队列中运行的应用程序可能会请求更多资源。
+从应用程序的角度来看，它可以请求的资源没有限制。
+应用程序上定义的联邦是有保证的资源数量，而不是应用程序可以请求的最大资源数量。
+
+我们拥有的队列层次结构是很复杂的。
+配额可能不是直接在应用程序运行的队列上设置的。
+它可以设置在某一个父队列上面。
+这种情况可能会变得复杂，我们需要保证记住我们可以实时锁定调度。
+
+在第一阶段中，我们应该关注这样一种情况，即请求的联邦资源也是应用程序将请求的最大资源数。
+当我们查看队列时，我们应该关注具有配额的单个队列级别。
+
+这两个假设对于没有使用从命名空间到队列的动态映射进行动态分配的 spark 用例是正确的。
+
+此外，我们假设队列上设置的配额可以完全分配。
+如果集群没有足够的资源，集群将扩展，直到为所有队列提供全部配额所需的大小。
+
+这也可以在某些用例中利用抢占，例如抢占应用程序超过其总的联邦大小的分配。
+在某些用例中，也可以利用抢占，比如在应用程序的总帮派规模上抢占分配。
+
+通过允许指定时间和应用程序来等待占位分配，或开始使用保留资源的时间，可以添加进一步的增强功能。
+
+## 调度器逻辑变化
+调度器逻辑的变化需要考虑周期的两个部分：
+* 占位请求及其分配。
+* 替换占位的分配。
+
+我们的基本假设是所有 pod 都会向核心生成占位 pod 请求。
+如果我们不使用应用程序 CRD，这包括触发应用程序创建的 pod。
+这个假设是必须的，才能确保调度器核心可以在提交应用程序的两种方式中以相同的方式运行。
+占位 Pod 必须在真正的 Pod 之前与核心通信。
+
+更改占位 AllocationAsks 是第一步。
+作为应用程序创建的一部分，AllocationAsks 被添加。
+添加 AllocationsAsk 通常会根据调度周期触发应用程序状态的更改。
+它将应用程序从 _New_ 状态移动到 _Accepted_ 状态。这与当前设置一致，并且不会更改。
+
+但是，在 AllocationAsk 设置了 _placeholder_ 标志的情况下，分配不应触发状态更改，应用程序保持在 _Accepted_ 状态。
+处理分配请求，直到应用程序没有 pending （挂起）的资源。
+作为安全预防措施，应忽略未设置 _placeholder_ 标志的 AllocationAsk。
+占位 Pod 的所有结果分配都按照正常步骤向 shim 确认。
+这个过程一直持续到没有更多的占位 pod 被分配。
+
+此时的 shim 应为已缓冲的真实 pod 创建分配任务。
+核心不能也不需假设每个应用程序只有一个任务组。
+如果 shim 使用了上述选项1，则核心也无法假设它已收到属于任务组的所有分配任务。
+这也是为什么我们假设每个 pod 都会向核心创建一个占位请求。
+
+第二个变化是用真正的 pod 替换了占位 pod。
+填充程序创建了一个设置了 _任务组名称_ 但未设置 _placeholder_ 标志的 AllocationAsk。
+
+这里描述的过程与通用抢占的过程一致。
+分配由核心释放，然后由 shim 确认。
+对于帮派调度，我们有一个简单的一对一释放关系，在抢占的情况下，我们可以使用具有一对多释放关系的相同流程。
+
+调度器按如下方式处理 AllocationAsk：
+1. 检查应用程序是否有未释放的分配给具有相同 _任务组名称_ 的占位分配。如果没有找到占位分配，将使用正常的分配周期来分配请求。
+2. 一个占位分配被选择并标记为释放。释放占位分配的请求被传送到 shim。这必须是一个异步过程，因为 shim 释放过程取决于底层的 K8s 响应，这可能不是即时的。
+ 注意：此时核心中没有释放任何分配。
+3. 核心“暂停”处理真正的 AllocationAsk，直到 shim 响应确认已释放占位分配。
+ 注意：释放锁以允许调度继续
+4. 在收到来自 shim 的释放确认后，“暂停的” AllocationAsk 处理会结束。
+5. AllocationAsk 分配在与使用的占位相同的节点上。
+ 在任何一种情况下，占位分配的删除都将完成。这一切都需要作为对应用程序、队列和节点的一次更新来实现。
+ * 成功时：创建一个新的分配。
+ * 失败时：尝试在不同的节点上分配，如果失败，AllocationAsk 变得不可调度，并触发扩展。
+6. 将分配传达回shim（如果适用，基于步骤 5）
+
+## 应用程序完成
+应用程序完成一直是一个长期存在的问题。
+目前，应用程序在完成时不会转换到 _completed_ 状态。
+应用程序的当前状态是 [参考文档](./scheduler_object_states.md)。
+但是，此时应用程序将不会达到 _completed_ 状态，而是停留在 _waiting_ 状态。
+
+这提供了许多问题，特别是在长时间运行部署中的内存使用和队列清理的情况下。
+
+### 定义
+由于我们不能依赖在 Kubernetes 上作为 Pod 运行的应用程序来表明它已经完成，因此我们需要定义何时考虑一个应用程序的 _完成_ 。
+在这一点上，我们定义了一个应用程序在定义的时间段内处于 _等待_ 状态时，它会变成 _完成_ 。
+当没有活动分配（已分配资源 > 0）和挂起分配请求（挂起资源 > 0）时，应用程序进入等待状态。
+
+向 _waiting_ 状态的转换已经实现。
+_waiting_ 状态的超时是一项新的功能。
+
+资源预留不被视为活动分配。
+占位请求被视为待处理的资源请求。
+这些情况将在下面的 [清理](#Cleanup) 中处理。
+
+### 清理
+当我们查看帮派调度时，还有一个关于未使用的预留资源、占位请求及其清理的问题。
+预留资源可以在有待处理分配请求或活动分配的任何时候转换为实际分配。
+
+在处理实际分配之前，占位请求将全部转换为占位分配。
+
+进入 _waiting_ 状态已被处理。
+如果将新的分配请求添加到应用程序中，它将转换回 _running_ 状态。
+当我们进入了等待状态，将没有待处理的请求或分配的资源。
+只有可以分配的预留资源。
+
+为了进入 _waiting_ 状态，应用程序必须是干净的。
+但是，我们不能保证在应用程序运行期间应用程序将使用所有预留资源。
+从 _waiting_ 状态转换到 _completed_ 状态根本不需要（占位）分配或请求。
+影响转换的第二种情况是并非所有占位请求都被分配，因此应用程序从不请求任何真正的分配。
+这两种情况可能会阻止应用程序转换出 _accepted_ 或 _waiting_ 状态。
+
+因此，核心中的处理需要考虑两种会影响特定状态的转换的情况：
+1. 占位请求挂起（退出 _accepted_ ）
+2. 占位分配（退出 _waiting_ ）
+
+占位请求挂起：
+挂起的占位符是通过超时来处理的。
+应用程序只能花费有限的时间等待分配所有预留资源。
+这个超时是必需的，因为应用程序的部分占位分配可能会占用集群资源而没有真正使用它们。
+
+应用程序可能排队等待未知时间，等待占位分配开始。
+因此，占位请求的超时不能与应用程序或请求的创建相关联。
+超时必须在分配第一个占位请求时开始。
+
+在所有占位请求都被分配之前，应用程序不能请求真正的分配。
+占位请求也由 shim 跟踪，因为它代表一个 pod。
+在核心中释放请求需要消息在核心和 shim 之间流动以释放该请求。
+但是，在这种情况下，分配预留资源的超时会触发应用程序失败。
+当超时被触发并且占位请求挂起时，应用程序将从它所处的状态转换为 _killed_ 。
+
+本案例的应用状态可以概括为：
+* 申请状态为 _accepted_
+* 占位分配的资源大于零，并且小于 _AddApplicationRequest_ 中的 _placeholderAsk_
+* 待处理资源请求大于零
+
+进入 _killed_ 状态必须自动将应用程序移出队列。
+
+状态更改和占位分配释放可以在单个更新响应消息中处理。 该消息将包含以下内容：
+* _UpdatedApplication_ 用于应用程序的状态变化
+* 一个或多个 _AllocationRelease_ 消息，每个占位一个，_TerminationType_ 设置为 TIMEOUT
+* 一条或多条 _TerminationType_ 设置为 TIMEOUT 的 AllocationAskRelease 消息
+
+shim 首先处理 AllocationAskRelease 消息，然后是 _AllocationResponse_ 消息，最后是 _UpdatedApplication_ 消息。应用程序状态在核心端更改为 _killed_ 状态仅取决于移除所有占位 pod，而不取决于对 _UpdatedApplication_ 消息的响应。
+
+
+
+占位超时期间 shim 和核心的组合流程：
+* 核心超时占位分配。 (1)
+* 删除占位分配被传递到 shim。 (2)
+* 所有占位分配都由 shim 释放，并传回核心。
+* 删除占位分配请求被传递给 shim。 (3)
+* 所有占位分配请求都由 shim 释放，并传回核心。
+* 在占位分配和请求被释放后，核心将应用程序移动到终止状态，将其从队列中移除 (4)。
+* 状态更改在核心和 shim 中完成。 (5)
+
+
+已分配的占位：
+剩余的占位需要由核心释放。
+需要通知 shim 将它们移除。这必须在进入 _完成_ 状态时触发。
+在核心请求释放占位之后，应用程序的状态转换可以继续。
+核心将处理从 shim 返回的占位分配的 _AllocationRelease_ 消息，并将 _TerminationType_ 设置为正常*超时*，而不会触发状态更改。
+
+状态更改和占位分配释放可以在单个更新响应消息中处理。
+该消息将包含以下内容：
+* _UpdatedApplication_ 用于应用程序的状态变化
+* 零个或多个 _AllocationRelease_ 消息，每个占位一个，_TerminationType_ 设置为 *超时*
+
+shim 首先处理 _AllocationResponse_ 消息，然后是 _UpdatedApplication_ 消息。
+应用程序状态在核心端更改为 _完成_ 状态仅依赖于所有占位 pod 的移除，而不依赖于对 _UpdatedApplication_ 消息的响应。
+
+进入 _完成_ 状态会自动将应用程序移出队列。
+这也应该处理我们之前讨论的可能延迟处理来自 shim 的请求的情况，因为我们可以在需要时从 _等待_ 移回 _执行中_ 。
+一个 _完成_ 的应用程序也不应该阻止围绕cron讨论的情况，例如每次调用使用相同的应用程序ID提交。
+具有相同申请ID的 _完成_ 申请不得阻止提交具有相同ID的新申请。
+
+
+cation to the completed state removing it from the queue (6).
+* The state change is finalised in the core and shim. (7)
+在清理应用程序期间 shim 和核心的组合流程：
+* 在 Kubernetes 层发布了一个 pod。 (1)
+* shim 将分配释放传递给核心。 (2)
+* 如果没有挂起或活动的分配，核心会将应用程序转换为等待状态。 (3)
+* 等待状态超时并触发清理。 (4)
+* 删除占位符配被传递到 shim。 (5)
+* 所有占位分配都由 shim 释放，并传回核心。
+* 释放所有占位后，核心将应用程序移动到完成状态，将其从队列中删除 (6)。
+* 状态更改在核心和 shim 中完成。 (7)
+
+## 应用恢复
+在应用程序恢复期间，占位 Pod 与节点上的任何其他 Pod 一样被恢复。
+这些 pod 由 shim 作为节点现有分配的一部分传递到核心。
+现有的分配在核心中没有相应的 _分配请求_。 核心根据恢复的信息生成 _分配请求_ 。
+
+对于联邦调度，_分配请求_ 包含 _任务组名称_ 和 _占位_ 标志。
+在恢复期间，相同的信息必须是 _分配_ 消息的一部分。
+这是因为在两个方向上使用相同的消息，从 RM 到调度器，反之亦然，这意味着我们需要更新消息及其处理。
+
+如果 _分配_ 消息中缺少信息，则恢复的分配将不会在核心中被正确标记。
+恢复的分配将被视为常规分配。
+这意味着它作为替换占位的正常分配周期的一部分被跳过。
+
+逻辑变化只需要现有分配的恢复将接口消息中的字段复制到内核中的分配对象中。
+
+## 接口变化
+需要对 shim 和核心之间的通信进行多次更改，以支持所需的帮派信息。
+
+应用程序必须提供占位请求的总大小，以防止接受永远无法运行的应用程序。
+
+从 shim 发送到核心以进行分配请求的当前对象在 AllocationAsk 中定义。
+由于从调度器核心传回的结果消息不会更改，因此分配不会更改。。但是，对于使用相同分配消息从 shim 到核心的恢复，必须包含与帮派相关的字段。
+必须将与帮派相关的字段添加到这两个消息中。
+
+分配释放请求和响应请求需要支持双向通信，并且需要进行重大更改。
+
Review comment:
Thanks for the clarification. I agree it's hard to find counterparts in Chinese for some terminologies. You are welcome to join the [weekly community meeting](https://yunikorn.apache.org/community/get_involved) for Mandarin speakers to discuss with people. It's at 1pm China Standard Time on Wednesday.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] yangwwei commented on a change in pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
yangwwei commented on a change in pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#discussion_r786444483
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/design/gang_scheduling.md
##########
@@ -0,0 +1,608 @@
+---
+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.
+ -->
+# 帮派调度实现
+一种新的调度应用程序的方法，它考虑了应用程序随着时间的推移预计会产生的资源需求。
+它通过预留资源来保证应用程序的预期需求资源。
+
+这个实现有两个部分：
+* Kubernetes Shim
+* Core（以后成为核心）和 scheduling (调度)
+
+本文档描述了核心端的实现。
+
+## 文档目标
+本文档描述了以下实现设计要点：
+1. 定义 shim 到核心通信所需的调整（调度器接口）
+2. 调度器存储对象变化
+3. 调度器逻辑变化
+
+## 排除的设计点
+目前，本设计文档未涵盖 Kubernetes shim 端实现。
+
+本设计将 _不_ 讨论核心端的广义抢占。
+
+## 通用流程
+该流由提交的 pod 触发，该 pod 触发应用程序创建。
+在 Spark 应用程序中，第一个 Pod 是驱动程序 Pod。
+如果流程是从应用程序 CRD 的创建触发的，则不会有第一个 pod。
+然而，这超出了核心调度逻辑。从核心方面来看，这两种情况应该没有区别。
+更多细节在 [调度器逻辑更改](#scheduler-logic-changes) 章节中。
+
+提交申请的流程。图中的数字对应于图下方的描述。
+
+
+
+应用程序启动期间shim和核心的组合流程：
+* 提交的应用程序定义了任务组。 (1)
+* shim 创建应用程序并将应用程序传递给核心。 (2)
+* shim 为任务组的每个成员创建 placeholder（占位）pod。 (3)
+* 按照正常行为，pod 作为具有正确信息集的应用程序的 AllocationAsk（资源分配请求）被处理并传递给核心。 (4)
+* 占位 AllocationAsk 由核心调度，就好像它们是正常的 AllocationAsk 一样。 (5)
+* 所有分配，即使它们是由调度器分配的占位 AllocationAsks 的结果，也会被传送回 shim。
+* 原始的实际 pod 作为 AllocationAsk 传递给核心。 (6)
+* 在实际 pod 和所有占位 pod 被调度后，shim 启动触发应用程序创建实际 pod。 (7)
+
+在第一个实际 pod 启动后，以下 pod 都应该以相同的方式处理 (8)：
+* 在 k8s 上创建了一个实际 pod。
+* 处理 pod 并创建一个 AllocationAsk。
+* 调度器处理 AllocationAsk（更多细节见下文）并用实际分配替换预留资源。
+
+## 应用提交处理
+### 预留资源总大小
+
+如果请求一个或多个任务组，应用程序应该提供它要请求的所有任务组成员的总大小。
+如果应用程序在限制了资源的队列中被调度，则需要总资源大小。
+
+该值对于三种情况很重要：
+1. 帮派请求大于队列配额
+2. 开始预调度
+3. 预调度时的资源压力
+
+进一步的细节将在下面的 [在设置了配额的队列中进行调度](#scheduling-in-queues-with-a-quota-set) 中给出
+
+从 shim 传递的信息应该是 AddApplicationRequest 中的一部分。
+任务组的建立或成员数量的详细信息不相关。
+所有任务组成员请求的总资源使用以下方法计算：
+
+
+
+placeholderAsk（占位/资源预留请求）的总计信息作为可选字段添加到 AddApplicationRequest 消息中。
+可以由 shim 根据 pod 描述中提供的 CRD 或注释进行计算。
+
+如果占位请求大于队列上设置的队列配额，则必须拒绝申请。
+这种拒绝是基于我们不能以任何方式满足请求的事实。
+对于所有其他情况，会接受申请并进行正常的安排。
+
+### 使用 FAIR（公平）排序策略处理队列
+Queue sorting for the queue that the application runs in must be set to _FIFO_ or _StateAware_.
+如果将应用程序提交到设置了 FAIR 排序策略的队列，则必须拒绝该应用程序。
+应用程序运行所在队列的队列排序必须设置为 _FIFO_ 或 _StateAware_。
+
+其他队列策略不能保证一次只处理一个 _新的_ 应用程序。
+在 _公平_ 策略的情况下，我们可以同时分配多个 _新的_ 应用程序，从而无法强制实施配额管理。
+使用 _公平_ 策略的另一个副作用可能是我们得到多个应用程序但只有部分能保证分配。
+
+由于核心无法将占位情况放置在任何节点上，因此可以触发自动缩放。
+如果队列使用 _公平_ 排序，这可能会导致其他应用程序使用放大的节点而不是预留资源从而再次破坏帮派调度。
+
+## 在设置了配额的队列中进行调度
+上面已经描述的主要情况是处理大于队列上设置的配额的总占位请求大小。
+提交申请时，我们已经可以评估我们无法满足该要求并拒绝该请求。
+
+在总占位请求确实适合队列的情况下，我们不应该开始调度，直到队列中有足够的可用资源来满足总请求。
+然而，这不会停止对队列中其他应用程序的调度。
+已在队列中运行的应用程序可能会请求更多资源。
+从应用程序的角度来看，它可以请求的资源没有限制。
+应用程序上定义的联邦是有保证的资源数量，而不是应用程序可以请求的最大资源数量。
+
+我们拥有的队列层次结构是很复杂的。
+配额可能不是直接在应用程序运行的队列上设置的。
+它可以设置在某一个父队列上面。
+这种情况可能会变得复杂，我们需要保证记住我们可以实时锁定调度。
+
+在第一阶段中，我们应该关注这样一种情况，即请求的联邦资源也是应用程序将请求的最大资源数。
+当我们查看队列时，我们应该关注具有配额的单个队列级别。
+
+这两个假设对于没有使用从命名空间到队列的动态映射进行动态分配的 spark 用例是正确的。
+
+此外，我们假设队列上设置的配额可以完全分配。
+如果集群没有足够的资源，集群将扩展，直到为所有队列提供全部配额所需的大小。
+
+这也可以在某些用例中利用抢占，例如抢占应用程序超过其总的联邦大小的分配。
+在某些用例中，也可以利用抢占，比如在应用程序的总帮派规模上抢占分配。
+
+通过允许指定时间和应用程序来等待占位分配，或开始使用保留资源的时间，可以添加进一步的增强功能。
+
+## 调度器逻辑变化
+调度器逻辑的变化需要考虑周期的两个部分：
+* 占位请求及其分配。
+* 替换占位的分配。
+
+我们的基本假设是所有 pod 都会向核心生成占位 pod 请求。
+如果我们不使用应用程序 CRD，这包括触发应用程序创建的 pod。
+这个假设是必须的，才能确保调度器核心可以在提交应用程序的两种方式中以相同的方式运行。
+占位 Pod 必须在真正的 Pod 之前与核心通信。
+
+更改占位 AllocationAsks 是第一步。
+作为应用程序创建的一部分，AllocationAsks 被添加。
+添加 AllocationsAsk 通常会根据调度周期触发应用程序状态的更改。
+它将应用程序从 _New_ 状态移动到 _Accepted_ 状态。这与当前设置一致，并且不会更改。
+
+但是，在 AllocationAsk 设置了 _placeholder_ 标志的情况下，分配不应触发状态更改，应用程序保持在 _Accepted_ 状态。
+处理分配请求，直到应用程序没有 pending （挂起）的资源。
+作为安全预防措施，应忽略未设置 _placeholder_ 标志的 AllocationAsk。
+占位 Pod 的所有结果分配都按照正常步骤向 shim 确认。
+这个过程一直持续到没有更多的占位 pod 被分配。
+
+此时的 shim 应为已缓冲的真实 pod 创建分配任务。
+核心不能也不需假设每个应用程序只有一个任务组。
+如果 shim 使用了上述选项1，则核心也无法假设它已收到属于任务组的所有分配任务。
+这也是为什么我们假设每个 pod 都会向核心创建一个占位请求。
+
+第二个变化是用真正的 pod 替换了占位 pod。
+填充程序创建了一个设置了 _任务组名称_ 但未设置 _placeholder_ 标志的 AllocationAsk。
+
+这里描述的过程与通用抢占的过程一致。
+分配由核心释放，然后由 shim 确认。
+对于帮派调度，我们有一个简单的一对一释放关系，在抢占的情况下，我们可以使用具有一对多释放关系的相同流程。
+
+调度器按如下方式处理 AllocationAsk：
+1. 检查应用程序是否有未释放的分配给具有相同 _任务组名称_ 的占位分配。如果没有找到占位分配，将使用正常的分配周期来分配请求。
+2. 一个占位分配被选择并标记为释放。释放占位分配的请求被传送到 shim。这必须是一个异步过程，因为 shim 释放过程取决于底层的 K8s 响应，这可能不是即时的。
+ 注意：此时核心中没有释放任何分配。
+3. 核心“暂停”处理真正的 AllocationAsk，直到 shim 响应确认已释放占位分配。
+ 注意：释放锁以允许调度继续
+4. 在收到来自 shim 的释放确认后，“暂停的” AllocationAsk 处理会结束。
+5. AllocationAsk 分配在与使用的占位相同的节点上。
+ 在任何一种情况下，占位分配的删除都将完成。这一切都需要作为对应用程序、队列和节点的一次更新来实现。
+ * 成功时：创建一个新的分配。
+ * 失败时：尝试在不同的节点上分配，如果失败，AllocationAsk 变得不可调度，并触发扩展。
+6. 将分配传达回shim（如果适用，基于步骤 5）
+
+## 应用程序完成
+应用程序完成一直是一个长期存在的问题。
+目前，应用程序在完成时不会转换到 _completed_ 状态。
+应用程序的当前状态是 [参考文档](./scheduler_object_states.md)。
+但是，此时应用程序将不会达到 _completed_ 状态，而是停留在 _waiting_ 状态。
+
+这提供了许多问题，特别是在长时间运行部署中的内存使用和队列清理的情况下。
+
+### 定义
+由于我们不能依赖在 Kubernetes 上作为 Pod 运行的应用程序来表明它已经完成，因此我们需要定义何时考虑一个应用程序的 _完成_ 。
+在这一点上，我们定义了一个应用程序在定义的时间段内处于 _等待_ 状态时，它会变成 _完成_ 。
+当没有活动分配（已分配资源 > 0）和挂起分配请求（挂起资源 > 0）时，应用程序进入等待状态。
+
+向 _waiting_ 状态的转换已经实现。
+_waiting_ 状态的超时是一项新的功能。
+
+资源预留不被视为活动分配。
+占位请求被视为待处理的资源请求。
+这些情况将在下面的 [清理](#Cleanup) 中处理。
+
+### 清理
+当我们查看帮派调度时，还有一个关于未使用的预留资源、占位请求及其清理的问题。
+预留资源可以在有待处理分配请求或活动分配的任何时候转换为实际分配。
+
+在处理实际分配之前，占位请求将全部转换为占位分配。
+
+进入 _waiting_ 状态已被处理。
+如果将新的分配请求添加到应用程序中，它将转换回 _running_ 状态。
+当我们进入了等待状态，将没有待处理的请求或分配的资源。
+只有可以分配的预留资源。
+
+为了进入 _waiting_ 状态，应用程序必须是干净的。
+但是，我们不能保证在应用程序运行期间应用程序将使用所有预留资源。
+从 _waiting_ 状态转换到 _completed_ 状态根本不需要（占位）分配或请求。
+影响转换的第二种情况是并非所有占位请求都被分配，因此应用程序从不请求任何真正的分配。
+这两种情况可能会阻止应用程序转换出 _accepted_ 或 _waiting_ 状态。
+
+因此，核心中的处理需要考虑两种会影响特定状态的转换的情况：
+1. 占位请求挂起（退出 _accepted_ ）
+2. 占位分配（退出 _waiting_ ）
+
+占位请求挂起：
+挂起的占位符是通过超时来处理的。
+应用程序只能花费有限的时间等待分配所有预留资源。
+这个超时是必需的，因为应用程序的部分占位分配可能会占用集群资源而没有真正使用它们。
+
+应用程序可能排队等待未知时间，等待占位分配开始。
+因此，占位请求的超时不能与应用程序或请求的创建相关联。
+超时必须在分配第一个占位请求时开始。
+
+在所有占位请求都被分配之前，应用程序不能请求真正的分配。
+占位请求也由 shim 跟踪，因为它代表一个 pod。
+在核心中释放请求需要消息在核心和 shim 之间流动以释放该请求。
+但是，在这种情况下，分配预留资源的超时会触发应用程序失败。
+当超时被触发并且占位请求挂起时，应用程序将从它所处的状态转换为 _killed_ 。
+
+本案例的应用状态可以概括为：
+* 申请状态为 _accepted_
+* 占位分配的资源大于零，并且小于 _AddApplicationRequest_ 中的 _placeholderAsk_
+* 待处理资源请求大于零
+
+进入 _killed_ 状态必须自动将应用程序移出队列。
+
+状态更改和占位分配释放可以在单个更新响应消息中处理。 该消息将包含以下内容：
+* _UpdatedApplication_ 用于应用程序的状态变化
+* 一个或多个 _AllocationRelease_ 消息，每个占位一个，_TerminationType_ 设置为 TIMEOUT
+* 一条或多条 _TerminationType_ 设置为 TIMEOUT 的 AllocationAskRelease 消息
+
+shim 首先处理 AllocationAskRelease 消息，然后是 _AllocationResponse_ 消息，最后是 _UpdatedApplication_ 消息。应用程序状态在核心端更改为 _killed_ 状态仅取决于移除所有占位 pod，而不取决于对 _UpdatedApplication_ 消息的响应。
+
+
+
+占位超时期间 shim 和核心的组合流程：
+* 核心超时占位分配。 (1)
+* 删除占位分配被传递到 shim。 (2)
+* 所有占位分配都由 shim 释放，并传回核心。
+* 删除占位分配请求被传递给 shim。 (3)
+* 所有占位分配请求都由 shim 释放，并传回核心。
+* 在占位分配和请求被释放后，核心将应用程序移动到终止状态，将其从队列中移除 (4)。
+* 状态更改在核心和 shim 中完成。 (5)
+
+
+已分配的占位：
+剩余的占位需要由核心释放。
+需要通知 shim 将它们移除。这必须在进入 _完成_ 状态时触发。
+在核心请求释放占位之后，应用程序的状态转换可以继续。
+核心将处理从 shim 返回的占位分配的 _AllocationRelease_ 消息，并将 _TerminationType_ 设置为正常*超时*，而不会触发状态更改。
+
+状态更改和占位分配释放可以在单个更新响应消息中处理。
+该消息将包含以下内容：
+* _UpdatedApplication_ 用于应用程序的状态变化
+* 零个或多个 _AllocationRelease_ 消息，每个占位一个，_TerminationType_ 设置为 *超时*
+
+shim 首先处理 _AllocationResponse_ 消息，然后是 _UpdatedApplication_ 消息。
+应用程序状态在核心端更改为 _完成_ 状态仅依赖于所有占位 pod 的移除，而不依赖于对 _UpdatedApplication_ 消息的响应。
+
+进入 _完成_ 状态会自动将应用程序移出队列。
+这也应该处理我们之前讨论的可能延迟处理来自 shim 的请求的情况，因为我们可以在需要时从 _等待_ 移回 _执行中_ 。
+一个 _完成_ 的应用程序也不应该阻止围绕cron讨论的情况，例如每次调用使用相同的应用程序ID提交。
+具有相同申请ID的 _完成_ 申请不得阻止提交具有相同ID的新申请。
+
+
+cation to the completed state removing it from the queue (6).
+* The state change is finalised in the core and shim. (7)
+在清理应用程序期间 shim 和核心的组合流程：
+* 在 Kubernetes 层发布了一个 pod。 (1)
+* shim 将分配释放传递给核心。 (2)
+* 如果没有挂起或活动的分配，核心会将应用程序转换为等待状态。 (3)
+* 等待状态超时并触发清理。 (4)
+* 删除占位符配被传递到 shim。 (5)
+* 所有占位分配都由 shim 释放，并传回核心。
+* 释放所有占位后，核心将应用程序移动到完成状态，将其从队列中删除 (6)。
+* 状态更改在核心和 shim 中完成。 (7)
+
+## 应用恢复
+在应用程序恢复期间，占位 Pod 与节点上的任何其他 Pod 一样被恢复。
+这些 pod 由 shim 作为节点现有分配的一部分传递到核心。
+现有的分配在核心中没有相应的 _分配请求_。 核心根据恢复的信息生成 _分配请求_ 。
+
+对于联邦调度，_分配请求_ 包含 _任务组名称_ 和 _占位_ 标志。
+在恢复期间，相同的信息必须是 _分配_ 消息的一部分。
+这是因为在两个方向上使用相同的消息，从 RM 到调度器，反之亦然，这意味着我们需要更新消息及其处理。
+
+如果 _分配_ 消息中缺少信息，则恢复的分配将不会在核心中被正确标记。
+恢复的分配将被视为常规分配。
+这意味着它作为替换占位的正常分配周期的一部分被跳过。
+
+逻辑变化只需要现有分配的恢复将接口消息中的字段复制到内核中的分配对象中。
+
+## 接口变化
+需要对 shim 和核心之间的通信进行多次更改，以支持所需的帮派信息。
+
+应用程序必须提供占位请求的总大小，以防止接受永远无法运行的应用程序。
+
+从 shim 发送到核心以进行分配请求的当前对象在 AllocationAsk 中定义。
+由于从调度器核心传回的结果消息不会更改，因此分配不会更改。。但是，对于使用相同分配消息从 shim 到核心的恢复，必须包含与帮派相关的字段。
+必须将与帮派相关的字段添加到这两个消息中。
+
+分配释放请求和响应请求需要支持双向通信，并且需要进行重大更改。
+
Review comment:
hi @cdmikechen thank you so much for initiating the effort!! and thanks for @yuchaoran2011 's help to review.
I do not think we need to wait for everything ready before committing patches, we can change YUNIKORN-1029 to an umbrella and do this incrementally. Actually, I am gonna propose in the next community, we should do a split for the reviewers for people who can help to review.
for your questions
> 第一个是我在翻译 gang scheduling 的时候遇到了一些困难
Understood, that's why we need to work together more closely : )
> 第二个是我原来的翻译顺序是按照我自己文档目录树的顺序翻译的，但是考虑到读者的阅读顺序，从website开始按照官网的顺序进行翻译可能更加好。所以我将当时翻译一半的内容先停了下来。
I think we should focus on the user-facing doc first. such as quick start, download, roadmap, community, user guide etc. for developer-facing docs, that can come later, such as design docs.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] yangwwei commented on pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
yangwwei commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1015110413
I have done the first-round review, I have skipped design docs in this round because I want to focus more on the user-facing docs. Please check my comments, besides that, a couple of more questions
1. Are we planning to translate the home page as well?
2. I noticed that all the files are under `docusaurus-plugin-content-docs/version-0.12.1/`, is this only done for the v0.12.1 doc? I think we need to get the master doc done first. Note, our source docs are under https://github.com/apache/incubator-yunikorn-site/tree/master/docs, and version docs are all generated. I am not familiar with how docusaurus support different languages, but we need to make sure the CN docs are also generated from the master doc.
3. Have you tested this locally and how it looks like? If you haven't done this, you can see how to do this locally in this here: https://github.com/apache/incubator-yunikorn-site#make-changes.
and a few suggestions
1. We need to use consistent terminology in the doc, such as gang scheduling, placement rules, resource quota, leaf queue, and so on. Once all review feedback is received, please don't forget to do a double-check on these terminology words.
2. Please focus on the user-facing doc first, that's gonna hit more users : )
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] cdmikechen commented on pull request #108: [YUNIKORN-1031] Add Chinese translation for homepage
Posted by GitBox <gi...@apache.org>.
cdmikechen commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1020899945
@yangwwei
Hi~ I have deleted the doc related pages and I will remind you after I merge your pr.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] cdmikechen commented on a change in pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
cdmikechen commented on a change in pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#discussion_r786707938
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/get_started/core_features.md
##########
@@ -0,0 +1,72 @@
+---
+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 提供了一个集中的视图来监视资源队列的使用情况，它可以帮助您了解不同租户是如何使用资源的。
+此外，通过利用最小/最大队列容量，它可以定义每个租户的弹性资源消耗。
+
+## 作业排序和排队
+
+应用可以在工作队列中正确排队，排序策略决定哪个应用程序可以首先获得资源。
+这个策略可以是多种多样的，例如简单的 `FIFO`、`Fair`、`StateAware`或基于`Priority`的策略。
+队列可以维持应用的顺序，调度器根据不同的策略为作业分配相应的资源。这种行为更容易被理解和控制。
+
+此外，当配置队列最大容量时，作业和任务可以在资源队列中正确排队。
+如果剩余的容量不够，它们可以排队等待，直到释放一些资源。这简化了客户端操作。
+与默认调度程序不同，资源由命名空间资源配额限制，这是由配额许可控制器强制执行的。
+如果下面的命名空间没有足够的配额，Pod就不能被创建。
+客户端需要复杂的逻辑来处理此类场景，例如按条件重试。
+
+## 资源公平性
+
+在多租户环境中，许多用户共享集群资源。
+为了避免租户争夺资源或者可能的资源不足，需要做到更细粒度的公平性需求，以此来实现跨用户以及跨团队/组织的公平性。
+考虑到权重或优先级，一些更重要的应用可以获得超过其配额的更多的需求资源。
+这往往与资源预算有关，更细粒度的公平模式可以进一步提高资源控制。
Review comment:
@yangwwei
This is often associated with resource budget, a more fine-grained fairness mode can further improve the expense control.
还有这一句，需要将 expense control 意译一下吗？
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] yangwwei commented on pull request #108: [YUNIKORN-1031] Add Chinese translation for homepage
Posted by GitBox <gi...@apache.org>.
yangwwei commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1021857925
hi @cdmikechen I thought you will split your PRs into smaller ones, that will be easier for review. Can you help to do that?
For example, the first change I expect will be a PR for https://issues.apache.org/jira/browse/YUNIKORN-1031. Which only contains the necessary changes for introducing the CN language option and the translation for the home page.
Then you can create separate PRs for each of the sub-tasks, and we can assign different reviewers to review your changes more easily. Does that make sense?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] yangwwei commented on pull request #108: [YUNIKORN-1031] Add Chinese translation for homepage
Posted by GitBox <gi...@apache.org>.
yangwwei commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1020856697
hi @cdmikechen any updates?
Please split this PR into smaller ones and link them to the sub-tasks under https://issues.apache.org/jira/browse/YUNIKORN-1029. Thanks
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] yangwwei commented on pull request #108: [YUNIKORN-1031] Add Chinese translation for homepage
Posted by GitBox <gi...@apache.org>.
yangwwei commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1022668991
> @yangwwei 抱歉，我现在可能理解了您的意思。我原来的考虑是把首页和如下的几个章节作为初次PR提交的主页内容。  因为我会假设一个正常访问页面的朋友，一部分人是为了下载最新/指定版本软件，一部分人或者是为了查看一下release note，还有的人是为了查看文档寻求一些详细内容的解答。抛开doc部分内容来说，对于前一部分的人来讲，从一个中文页面转到英文界面会让人感觉有一定的阻断性。我当时觉得把 `docusaurus-plugin-content-pages` 内部分作为一次性的提交是可以的，所以在上一次提交的时候把其他doc章节的内容都进行了删除。 另外一点考量是一次性提交一个部分/章节内的几篇翻译文档应该是一个较为有效率的事情。我实际上在拆分子任务的时候，大概在�
�里计划了每次提交需要涉及多少部分。
>
> 不过，如果您认为我们的第一次PR应该只包含独立的页面，我会进行修改的。
OK，谢谢你的解释，这样也是OK的。我会来review这一个。感谢！
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] cdmikechen commented on pull request #108: [YUNIKORN-1031] Add Chinese translation for homepage
Posted by GitBox <gi...@apache.org>.
cdmikechen commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1022186136
@yangwwei
抱歉，我现在可能理解了您的意思。我原来的考虑是把首页和如下的几个章节作为初次PR提交的主页内容。
因为我会假设一个正常访问页面的朋友，一部分人是为了下载最新/指定版本软件，一部分人或者是为了查看一下release note，还有的人是为了查看文档寻求一些详细内容的解答。抛开doc部分内容来说，对于前一部分的人来讲，从一个中文页面转到英文界面会让人感觉有一定的阻断性。我当时觉得把 `docusaurus-plugin-content-pages` 内部分作为一次性的提交是可以的，所以在上一次提交的时候把其他doc章节的内容都进行了删除。
另外一点考量是一次性提交一个部分/章节内的几篇翻译文档应该是一个较为有效率的事情。我实际上在拆分子任务的时候，大概在心里计划了每次提交需要涉及多少部分。
不过，如果您认为我们的第一次PR应该只包含独立的页面，我会进行修改的。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] yangwwei commented on a change in pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
yangwwei commented on a change in pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#discussion_r786411896
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/api/scheduler.md
##########
@@ -0,0 +1,1317 @@
+---
+id: scheduler
+title: 调度
Review comment:
调度器
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/design/architecture.md
##########
@@ -0,0 +1,56 @@
+---
+id: architecture
+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.
+-->
+
+Apache YuniKorn (Incubating) 是一个用于容器编排器系统的轻量级通用资源调度器。
+它的创建是为了在大规模、多租户和云原生环境中高效地实现各种工作负载的细粒度资源共享。
+YuniKorn为无状态批处理和有状态服务组成的混合工作负载带来了统一的、跨平台的调度体验。
+
+YuniKorn现在支持K8s并可以作为自定义K8s调度程序部署。
+YuniKorn的架构设计还允许添加不同的 shim（中介）层，并采用不同的ResourceManager实现，包括 Apache Hadoop YARN 或任何的其他系统。
+
+## 架构
+
+下图说明了YuniKorn的高级体系结构。
+
+<img src={require('./../assets/architecture.png').default} />
+
+## 组件
+
+### 调度器接口
+
+[调度器接口](https://github.com/apache/incubator-yunikorn-scheduler-interface) 是一个抽象层。资源管理平台（如YARN/K8s）将通过GRPC/编程语言绑定等API与之对话。
+
+### 调度器核心
+
+调度器核心封装了所有的调度算法，它从底层的资源管理平台（如YARN/K8s）收集资源，并负责容器分配请求。
+它决定每个请求的最佳位置，然后将响应分配发送到资源管理平台。
+调度器核心对底层平台是不可知的，所有的通信都是通过 [调度器接口](https://github.com/apache/incubator-yunikorn-scheduler-interface)。
+请阅读更多有关调度器核心的设计内容 [链接](scheduler_core_design.md)。
+
+### Kubernetes shim
+
+YuniKorn Kubernetes shim负责与Kubernetes交互，它负责转换Kubernetes集群资源，并通过调度器接口将资源请求发送到调度器核心。
Review comment:
它负责转换Kubernetes集群资源 -> 它负责翻译Kubernetes集群的资源请求信息
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/get_started/core_features.md
##########
@@ -0,0 +1,72 @@
+---
+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 提供了一个集中的视图来监视资源队列的使用情况，它可以帮助您了解不同租户是如何使用资源的。
+此外，通过利用最小/最大队列容量，它可以定义每个租户的弹性资源消耗。
+
+## 作业排序和排队
+
+应用可以在工作队列中正确排队，排序策略决定哪个应用程序可以首先获得资源。
Review comment:
> 应用可以在工作队列中正确排队，排序策略决定哪个应用程序可以首先获得资源。
YuniKorn 将每个资源队列中的队列进行排队，排序策略决定哪个应用程序可以首先获得资源。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/get_started/core_features.md
##########
@@ -0,0 +1,72 @@
+---
+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 提供了一个集中的视图来监视资源队列的使用情况，它可以帮助您了解不同租户是如何使用资源的。
+此外，通过利用最小/最大队列容量，它可以定义每个租户的弹性资源消耗。
+
+## 作业排序和排队
+
+应用可以在工作队列中正确排队，排序策略决定哪个应用程序可以首先获得资源。
+这个策略可以是多种多样的，例如简单的 `FIFO`、`Fair`、`StateAware`或基于`Priority`的策略。
+队列可以维持应用的顺序，调度器根据不同的策略为作业分配相应的资源。这种行为更容易被理解和控制。
+
+此外，当配置队列最大容量时，作业和任务可以在资源队列中正确排队。
+如果剩余的容量不够，它们可以排队等待，直到释放一些资源。这简化了客户端操作。
+与默认调度程序不同，资源由命名空间资源配额限制，这是由配额许可控制器强制执行的。
+如果下面的命名空间没有足够的配额，Pod就不能被创建。
+客户端需要复杂的逻辑来处理此类场景，例如按条件重试。
+
+## 资源公平性
+
+在多租户环境中，许多用户共享集群资源。
+为了避免租户争夺资源或者可能的资源不足，需要做到更细粒度的公平性需求，以此来实现跨用户以及跨团队/组织的公平性。
+考虑到权重或优先级，一些更重要的应用可以获得超过其配额的更多的需求资源。
+这往往与资源预算有关，更细粒度的公平模式可以进一步提高资源控制。
Review comment:
> 这往往与资源预算有关，更细粒度的公平模式可以进一步提高资源控制。
这往往与资源预算有关，更细粒度的公平模式可以进一步提高资源共享的效率。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/placement_rules.md
##########
@@ -0,0 +1,356 @@
+---
+id: placement_rules
+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#placement-rules-definition) 中有描述。
+一个放置策略可以连接多个规则。
+[访问控制列表](user_guide/acls.md) 和规则过滤器根据规则定义，并根据规则强制执行。
+本文档通过示例说明了如何构建作为调度器一部分的策略，包括规则用法。
+
+## 配置
+规则是作为调度器队列配置的一部分按分区定义的。
+规则的定义顺序就是规则的执行顺序。
+如果某个规则与策略匹配，则该策略将停止执行其余规则。
+
+匹配规则生成一个完全限定的队列名称。
+这意味着返回的名称从 _root_ 队列开始。
+可以生成的队列层次结构中的层级数目没有限制。
+
+当执行规则时，已执行规则的结果是未知的，不会被考虑在内。
+与尚未执行的规则类似：规则不能影响其他规则，除非它们被配置为 [父级](#parent-parameter) 规则。
+
+如果策略不生成队列名称并且没有更多规则，则应用程序将被拒绝。
+
+配置中规则放置定义的基本结构：
+```yaml
+placementrules:
+ - name: <第一个规则名称>
+ - name: <第二个规则名称>
+```
+每个规则都可以在配置中采用一组预定义的参数。
+[规则](#rules) 章节的描述中给出了可以使用的规则名称。
+配置中的规则名称不区分大小写。
+规则名称必须遵循以下命名约定：
+* 以字母开头：a-z 或 A-Z
+* 后跟 0 个或多个字符 a-z、A-Z、0-9 或 _
+
+未知的规则，即名称未映射到下面定义的规则，将导致放置管理器的初始化错误。
+如果参数不正确，规则也可以在初始化期间抛出解析异常或错误。
+有错误的规则集永远不会变为活动状态。
+
+如果放置管理器具有活动规则集，则将其视为已初始化。
+当重新加载配置时，将创建一个新规则集来替换活动规则集。
+如果加载的新规则集包含错误，即被破坏，则放置管理器将忽略新规则集。
+这意味着放置管理器保持在加载损坏的规则集时的状态。
+如果放置管理器在已经初始化的情况下继续使用现有的活动规则集，它将记录有关损坏和忽略的配置的消息。
Review comment:
放置管理器 -> 放置策略管理器
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/placement_rules.md
##########
@@ -0,0 +1,356 @@
+---
+id: placement_rules
+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#placement-rules-definition) 中有描述。
+一个放置策略可以连接多个规则。
+[访问控制列表](user_guide/acls.md) 和规则过滤器根据规则定义，并根据规则强制执行。
+本文档通过示例说明了如何构建作为调度器一部分的策略，包括规则用法。
+
+## 配置
+规则是作为调度器队列配置的一部分按分区定义的。
+规则的定义顺序就是规则的执行顺序。
+如果某个规则与策略匹配，则该策略将停止执行其余规则。
+
+匹配规则生成一个完全限定的队列名称。
+这意味着返回的名称从 _root_ 队列开始。
+可以生成的队列层次结构中的层级数目没有限制。
+
+当执行规则时，已执行规则的结果是未知的，不会被考虑在内。
+与尚未执行的规则类似：规则不能影响其他规则，除非它们被配置为 [父级](#parent-parameter) 规则。
+
+如果策略不生成队列名称并且没有更多规则，则应用程序将被拒绝。
+
+配置中规则放置定义的基本结构：
+```yaml
+placementrules:
+ - name: <第一个规则名称>
+ - name: <第二个规则名称>
+```
+每个规则都可以在配置中采用一组预定义的参数。
+[规则](#rules) 章节的描述中给出了可以使用的规则名称。
+配置中的规则名称不区分大小写。
+规则名称必须遵循以下命名约定：
+* 以字母开头：a-z 或 A-Z
+* 后跟 0 个或多个字符 a-z、A-Z、0-9 或 _
+
+未知的规则，即名称未映射到下面定义的规则，将导致放置管理器的初始化错误。
+如果参数不正确，规则也可以在初始化期间抛出解析异常或错误。
+有错误的规则集永远不会变为活动状态。
+
+如果放置管理器具有活动规则集，则将其视为已初始化。
+当重新加载配置时，将创建一个新规则集来替换活动规则集。
+如果加载的新规则集包含错误，即被破坏，则放置管理器将忽略新规则集。
+这意味着放置管理器保持在加载损坏的规则集时的状态。
Review comment:
放置管理器 -> 放置策略管理器
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/queue_config.md
##########
@@ -0,0 +1,349 @@
+---
+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` 更改文件名。
+更改文件名后必须在 deployment 详细信息中进行相应的更改，无论是 `configmap` 还是包含在 docker 容器中的文件。
+
+配置的示例文件位于调度器核心内 [queues.yaml](https://github.com/apache/incubator-yunikorn-core/blob/master/config/queues.yaml)。
+
+## 分区
+分区是调度器配置的顶层。
+配置中可以定义多个分区。
+
+配置中分区定义的基本结构：
+```yaml
+partitions:
+ - name: <name of the 1st partition>
+ - name: <name of the 2nd partition>
+```
+分区的默认名称是 `default`。
+分区定义包含特定 shim 的调度程器的完整配置。
+每个 shim 使用自己唯一的分区。
+
+分区必须至少定义以下键：
+* 名称
+* [队列](#queues)
+
+队列配置释义如下。
+
+可以选择为分区定义以下键：
+* [布置规则](#placement-rules)
+* [限制](#limits)
+* 节点排序策略
+* 抢占
+
+布置规则和限制在它们自己的章节中进行了详解
+
+`nodesortpolicy` 定义了节点为分区排序的方式。
+可以使用的值的详细信息在 [排序策略](sorting_policies.md#node-sorting) 文档中可以参考。
+
+抢占键目前只能有一个子键：_enabled_ 。
+这个布尔值定义了整个分区的抢占行为。
+
+_enabled_ 的默认值为 _false_ 。
+允许值：_true_ 或 _false_ ，任何其他值都会导致解析错误。
+
+设置了 _preemption_ 标志和 `nodesortpolicy` 为 _fair_ 的示例 `partition` yaml 描述：
+```yaml
+partitions:
+ - name: <分区名称>
+ nodesortpolicy: fair
+ preemption:
+ enabled: true
+```
+注意:
+目前，Kubernetes 唯一的 shim 不支持除 `default` 分区之外的任何其他分区。
+这已为 shim 在 [jira](https://issues.apache.org/jira/browse/YUNIKORN-22) 上进行了记录。
+
+### 队列
+
+YuniKorn 通过利用资源队列来管理资源。资源队列具有以下特征：
+- 队列可以有 **等级制的** 结构
Review comment:
等级制度 -> 层级结构
##########
File path: i18n/zh-cn/docusaurus-plugin-content-pages/community/how_to_contribute.md
##########
@@ -0,0 +1,107 @@
+---
+id: how_to_contribute
+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 使用：
+* JIRA 用于问题跟踪。
+* GitHub 用于 Pull Requests(以后简称拉取请求)来管理代码审查和更改本身。
+* MarkDown 用于文档的源代码树。
+
+## 发现问题
+我们使用 JIRA 问题库来跟踪该项目的错误。
+找到您想要处理的问题，或者如果您发现了新问题，请提交新问题。
+有关报告问题的帮助，请查看 [如何报告问题](reporting_issues)。
+
+开始使用代码库的最简单方法是选择一个非常简单的 JIRA 问题并开始工作。
+这将帮助您熟悉代码库、构建系统、审查过程等。
+我们在 [此处](https://issues.apache.org/jira/issues/?jql=project%3DYUNIKORN%20AND%20status%3DOpen%20AND%20labels%3Dnewbie) 标记这些入门错误。
+
+如果没有人在处理现有问题，请您在只想打算尽快处理该问题时将其分配给自己。
+如果您选择现有的 JIRA，请查找链接到 JIRA ticket 的拉取请求。
+有人可能已经在处理它并且没有分配 ticket。
+具有拉取请求链接的 JIRA 将具有标签 `pull-request-available`，并且可以在问题链接下找到拉取请求的链接。
+
+对于任何不只是微不足道的更改，例如拼写错误或一行代码更改，讨论您在该问题上的预期方法是一个好主意。
+如果您在开始编写修复程序之前已经从 YuniKorn 社区获得了支持，那么您更有可能审查并提交您的补丁程序。
+
+如果您无法将 JIRA 分配给自己，请请求社区帮助分配并将您添加到 JIRA 的贡献者列表中。
+
+## 修复问题
+必须在 `master` 分支上创建修复或改进。
+将相关的 YuniKorn 项目 fork 到您自己的项目中并签出 `master` 分支。
+确保在开始之前签出最新的代码修订。
+创建一个分支来处理，一个好名字是你正在处理的 JIRA ID。
+
+现在可以开始编码了！在编写补丁时，请牢记以下几点：
+
+在您的补丁中需要包含测试。
+如果您的补丁添加了功能或修复了错误并且不包括测试，则通常不会被接受。
+如果您不确定如何为特定组件编写测试，请在 JIRA 上寻求指导。
+
+请让您的补丁只修改了 JIRA 描述的问题。
+如果我们对每个补丁的范围保持记录，这对每个人都会更好。
+一般来说，如果您在处理特定功能时发现错误，请为该错误提交 JIRA，并检查您是否可以将其分配给自己并独立于该功能进行修复。
+这有助于我们区分错误修复和功能，并让我们构建稳定的维护版本。
+
+确保您已遵守 [编码指南](coding_guidelines) 中的建议。
+在您提交之前，您还应该使用 `make test` 运行完整的测试套件。
+这样能确保所有测试都通过。
+
+最后，请写一个好的、清晰的提交信息，并带有一个简短的描述性标题。
+描述性标题必须以您正在处理的 JIRA ID 开头。
+一个例子是：`[YUNIKORN-2] Support Gang Scheduling`。
+提交消息将用于预填充拉取请求的信息。
+消息中的 JIRA ID 将自动链接拉取请求和 JIRA。
+下面的消息可用于解释问题是什么，以及如何解决。
+
+## 创建拉取请求
+请使用您的补丁在 github 上创建一个拉取请求。
+有关所有的详细信息，请参阅 [开启拉取请求](https://help.github.com/articles/using-pull-requests/)。
+
+对于提交者：您可以使用 GitHub UI 创建新分支、推送更改并创建 PR。
+对于贡献者：您已经 fork 了存储库并将您的更改提交到您的 fork。
+使用 GitHub UI 使用 `compare across forks` 选项创建 PR。
+
+拉取请求描述必须包含您正在处理的 JIRA 链接。
+如果您如上所述设置提交消息，则拉取请求将自动获取它。
+如果您没有这样做，您可以修改拉取请求的描述以添加 JIRA ID。
+例如，链接到 [YUNIKORN-2](https://issues.apache.org/jira/browse/YUNIKORN-2) 的拉取请求应具有如下描述：
+`[YUNIKORN-2] Support Gang Scheduling`
+
+## 提交更改
+当更改被批准后，它将被提交到存储库的 `master` 分支。
+提交消息必须在第一行包含 JIRA，并且应该包含 `Closes #1`，这样一个提交将自动关闭 PR。
+JIRA 不会自动关闭。
+
+## 报告安全问题
+YuniKorn 社区非常关心安全问题，并将积极解决任何安全问题作为重中之重。
+我们遵循 Apache 安全指南来处理安全问题，请参阅 Apache 文档关于 [处理安全问题](https://www.apache.org/security/)。
+如果您发现任何安全问题，请将漏洞报告发送至 security@apache.org，YuniKorn 安全团队将立即评估问题并与报告者一起制定修复计划。
+在与安全团队合作之前，请不要将问题透露给任何公共论坛。
+
+## 如果扔有问题？
Review comment:
如果仍有问题？
错别字扔
##########
File path: i18n/zh-cn/docusaurus-plugin-content-pages/release-announce/0.10.0.md
##########
@@ -0,0 +1,54 @@
+---
+id: rn-0.10.0
+title: 发布公告 v0.10.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.
+-->
+# 发布公告 v0.10.0
+我们非常高兴地宣布 Apache YuniKorn (Incubating) 社区已投票发布 0.10.0。Apache YuniKorn (Incubating) 是一个独立的资源调度器，旨在管理和调度容器编排框架上的大数据工作负载，支持本地和云端的用例。
+
+此版本中添加的显著功能是联邦调度，YuniKorn 现在可以在 Kubernetes 上运行应用程序时提供联邦调度功能。除此之外，此版本还包括各种错误修复和改进。
Review comment:
此版本中添加的显著功能是 gang scheduling， YuniKorn 现在可以在 Kubernetes 上运行应用程序时提供gang scheduling 调度功能。除此之外，此版本还包括各种错误修复和改进。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/design/architecture.md
##########
@@ -0,0 +1,56 @@
+---
+id: architecture
+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.
+-->
+
+Apache YuniKorn (Incubating) 是一个用于容器编排器系统的轻量级通用资源调度器。
+它的创建是为了在大规模、多租户和云原生环境中高效地实现各种工作负载的细粒度资源共享。
Review comment:
目标是为了在大规模、多租户和云原生的环境中高效地实现各种工作负载的细粒度资源调度以及共享。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/get_started/core_features.md
##########
@@ -0,0 +1,72 @@
+---
+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 提供了一个集中的视图来监视资源队列的使用情况，它可以帮助您了解不同租户是如何使用资源的。
+此外，通过利用最小/最大队列容量，它可以定义每个租户的弹性资源消耗。
Review comment:
此外，用户可以利用设置最小/最大队列容量来为每个租户设定其弹性资源配额。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/design/architecture.md
##########
@@ -0,0 +1,56 @@
+---
+id: architecture
+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.
+-->
+
+Apache YuniKorn (Incubating) 是一个用于容器编排器系统的轻量级通用资源调度器。
+它的创建是为了在大规模、多租户和云原生环境中高效地实现各种工作负载的细粒度资源共享。
+YuniKorn为无状态批处理和有状态服务组成的混合工作负载带来了统一的、跨平台的调度体验。
+
+YuniKorn现在支持K8s并可以作为自定义K8s调度程序部署。
+YuniKorn的架构设计还允许添加不同的 shim（中介）层，并采用不同的ResourceManager实现，包括 Apache Hadoop YARN 或任何的其他系统。
+
+## 架构
+
+下图说明了YuniKorn的高级体系结构。
Review comment:
下图说明了YuniKorn的系统架构。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/get_started/core_features.md
##########
@@ -0,0 +1,72 @@
+---
+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可以识别用户、应用程序或者队列，并在做出调度决策时，考虑更多的因素，如资源、排序等。
+这使我们能够对资源配额、资源公平性和优先级进行细粒度控制，这是多租户计算系统最重要的需求。
Review comment:
YuniKorn的关键特性之一就是支持应用感知。在默认的K8s调度程序中，它只能根据Pod进行调度，而不能基于用户、作业或者队列进行更细粒度的调度。与之不同的是，YuniKorn可以识别用户、作业或者队列，并在做出调度决策时，考虑更多与它们相关的因素，如资源、排序等。这使我们能够对资源配额、资源公平性和优先级进行细粒度控制，这是多租户计算系统最重要的需求。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/get_started/core_features.md
##########
@@ -0,0 +1,72 @@
+---
+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 提供了一个集中的视图来监视资源队列的使用情况，它可以帮助您了解不同租户是如何使用资源的。
+此外，通过利用最小/最大队列容量，它可以定义每个租户的弹性资源消耗。
+
+## 作业排序和排队
+
+应用可以在工作队列中正确排队，排序策略决定哪个应用程序可以首先获得资源。
+这个策略可以是多种多样的，例如简单的 `FIFO`、`Fair`、`StateAware`或基于`Priority`的策略。
+队列可以维持应用的顺序，调度器根据不同的策略为作业分配相应的资源。这种行为更容易被理解和控制。
Review comment:
> 队列可以维持应用的顺序，调度器根据不同的策略为作业分配相应的资源。这种行为更容易被理解和控制。
队列中的应用会根据预定义的排序策略进行排序，而后按顺序调度。用户可以基于自身需求设置不同的排队策略，以满足不同的业务场景需求。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/placement_rules.md
##########
@@ -0,0 +1,356 @@
+---
+id: placement_rules
+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#placement-rules-definition) 中有描述。
Review comment:
放置规则的基本信息
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/get_started/get_started.md
##########
@@ -0,0 +1,71 @@
+---
+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 Charts在现有的Kubernetes集群上部署YuniKorn。
+我们建议使用Helm 3或更高版本。
+
+```shell script
+helm repo add yunikorn https://apache.github.io/incubator-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的charts，您可以找到我们的细节教程 [点击这里](../developer_guide/deployment.md) 。
Review comment:
如果你不想使用helm charts
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/get_started/get_started.md
##########
@@ -0,0 +1,71 @@
+---
+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 Charts在现有的Kubernetes集群上部署YuniKorn。
+我们建议使用Helm 3或更高版本。
+
+```shell script
+helm repo add yunikorn https://apache.github.io/incubator-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的charts，您可以找到我们的细节教程 [点击这里](../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
+kubectl port-forward svc/yunikorn-service 9080:9080 -n yunikorn
+```
Review comment:
This might be done in a bit older version. In the latest doc, we just need to do port-forwarding for port 9889: https://yunikorn.apache.org/docs/next/#access-the-web-ui. So, please change this to:
```shell script
kubectl port-forward svc/yunikorn-service 9889:9889 -n yunikorn
```
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/get_started/get_started.md
##########
@@ -0,0 +1,71 @@
+---
+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 Charts在现有的Kubernetes集群上部署YuniKorn。
+我们建议使用Helm 3或更高版本。
+
+```shell script
+helm repo add yunikorn https://apache.github.io/incubator-yunikorn-release
+helm repo update
+kubectl create namespace yunikorn
+helm install yunikorn yunikorn/yunikorn --namespace yunikorn
+```
+
+默认情况下，helm chart将在集群中安装调度器、web服务器和 admission-controller。
+安装 `admission-controller` 后，它只需将所有流量路由到YuniKorn即可。
Review comment:
`admission-controller` 一旦安装，它将把所有集群流量路由到 YuniKorn。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/get_started/core_features.md
##########
@@ -0,0 +1,72 @@
+---
+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 提供了一个集中的视图来监视资源队列的使用情况，它可以帮助您了解不同租户是如何使用资源的。
+此外，通过利用最小/最大队列容量，它可以定义每个租户的弹性资源消耗。
+
+## 作业排序和排队
+
+应用可以在工作队列中正确排队，排序策略决定哪个应用程序可以首先获得资源。
+这个策略可以是多种多样的，例如简单的 `FIFO`、`Fair`、`StateAware`或基于`Priority`的策略。
+队列可以维持应用的顺序，调度器根据不同的策略为作业分配相应的资源。这种行为更容易被理解和控制。
+
+此外，当配置队列最大容量时，作业和任务可以在资源队列中正确排队。
+如果剩余的容量不够，它们可以排队等待，直到释放一些资源。这简化了客户端操作。
+与默认调度程序不同，资源由命名空间资源配额限制，这是由配额许可控制器强制执行的。
+如果下面的命名空间没有足够的配额，Pod就不能被创建。
+客户端需要复杂的逻辑来处理此类场景，例如按条件重试。
+
+## 资源公平性
+
+在多租户环境中，许多用户共享集群资源。
+为了避免租户争夺资源或者可能的资源不足，需要做到更细粒度的公平性需求，以此来实现跨用户以及跨团队/组织的公平性。
+考虑到权重或优先级，一些更重要的应用可以获得超过其配额的更多的需求资源。
+这往往与资源预算有关，更细粒度的公平模式可以进一步提高资源控制。
+
+## 资源预留
+
+YuniKorn会自动为未完成的请求进行资源预订。
Review comment:
YuniKorn会自动为未完成的请求进行资源预留。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/get_started/core_features.md
##########
@@ -0,0 +1,72 @@
+---
+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 提供了一个集中的视图来监视资源队列的使用情况，它可以帮助您了解不同租户是如何使用资源的。
+此外，通过利用最小/最大队列容量，它可以定义每个租户的弹性资源消耗。
+
+## 作业排序和排队
+
+应用可以在工作队列中正确排队，排序策略决定哪个应用程序可以首先获得资源。
+这个策略可以是多种多样的，例如简单的 `FIFO`、`Fair`、`StateAware`或基于`Priority`的策略。
+队列可以维持应用的顺序，调度器根据不同的策略为作业分配相应的资源。这种行为更容易被理解和控制。
+
+此外，当配置队列最大容量时，作业和任务可以在资源队列中正确排队。
+如果剩余的容量不够，它们可以排队等待，直到释放一些资源。这简化了客户端操作。
+与默认调度程序不同，资源由命名空间资源配额限制，这是由配额许可控制器强制执行的。
+如果下面的命名空间没有足够的配额，Pod就不能被创建。
+客户端需要复杂的逻辑来处理此类场景，例如按条件重试。
+
+## 资源公平性
+
+在多租户环境中，许多用户共享集群资源。
+为了避免租户争夺资源或者可能的资源不足，需要做到更细粒度的公平性需求，以此来实现跨用户以及跨团队/组织的公平性。
+考虑到权重或优先级，一些更重要的应用可以获得超过其配额的更多的需求资源。
+这往往与资源预算有关，更细粒度的公平模式可以进一步提高资源控制。
+
+## 资源预留
+
+YuniKorn会自动为未完成的请求进行资源预订。
+如果Pod无法分配，YuniKorn将尝试在一个满足条件的节点上保留它，并在这个保留节点上暂时分配pod（在尝试其他节点之前）。
+这种机制可以避免这个Pod被后来提交的更小、更不挑剔的豆荚所挤占。
+此功能在批处理工作负载场景中非常重要，因为当对集群提交大量异构Pod时，很有可能一些Pod会被抛弃，即使它们提交得更早。
Review comment:
> 如果Pod无法分配，YuniKorn将尝试在一个满足条件的节点上保留它，并在这个保留节点上暂时分配pod（在尝试其他节点之前）。
这种机制可以避免这个Pod被后来提交的更小、更不挑剔的豆荚所挤占。
此功能在批处理工作负载场景中非常重要，因为当对集群提交大量异构Pod时，很有可能一些Pod会被抛弃，即使它们提交得更早。
如果 Pod 在一段时间内午无法被分配，YuniKorn将尝试在一个满足条件的节点上为其预留资源，并在这个节点上暂停分配资源给其他的 Pod；同时，YuniKorn 将提升改 Pod 调度的优先级，尽可能尽快把它分配到某个节点 （倾向但不限于预留的节点）。这种机制可以避免这个 Pod 需要的资源被后来提交的更小的、更不挑剔的 Pod 所挤占。此功能在批处理工作负载场景中非常重要，因为当对集群提交大量异构Pod时，很有可能一些Pod会处于“饥饿”状态，即使它们提交得更早。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/placement_rules.md
##########
@@ -0,0 +1,356 @@
+---
+id: placement_rules
+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#placement-rules-definition) 中有描述。
+一个放置策略可以连接多个规则。
+[访问控制列表](user_guide/acls.md) 和规则过滤器根据规则定义，并根据规则强制执行。
+本文档通过示例说明了如何构建作为调度器一部分的策略，包括规则用法。
+
+## 配置
+规则是作为调度器队列配置的一部分按分区定义的。
+规则的定义顺序就是规则的执行顺序。
+如果某个规则与策略匹配，则该策略将停止执行其余规则。
+
+匹配规则生成一个完全限定的队列名称。
+这意味着返回的名称从 _root_ 队列开始。
+可以生成的队列层次结构中的层级数目没有限制。
+
+当执行规则时，已执行规则的结果是未知的，不会被考虑在内。
+与尚未执行的规则类似：规则不能影响其他规则，除非它们被配置为 [父级](#parent-parameter) 规则。
+
+如果策略不生成队列名称并且没有更多规则，则应用程序将被拒绝。
+
+配置中规则放置定义的基本结构：
+```yaml
+placementrules:
+ - name: <第一个规则名称>
+ - name: <第二个规则名称>
+```
+每个规则都可以在配置中采用一组预定义的参数。
+[规则](#rules) 章节的描述中给出了可以使用的规则名称。
+配置中的规则名称不区分大小写。
+规则名称必须遵循以下命名约定：
+* 以字母开头：a-z 或 A-Z
+* 后跟 0 个或多个字符 a-z、A-Z、0-9 或 _
+
+未知的规则，即名称未映射到下面定义的规则，将导致放置管理器的初始化错误。
+如果参数不正确，规则也可以在初始化期间抛出解析异常或错误。
+有错误的规则集永远不会变为活动状态。
+
+如果放置管理器具有活动规则集，则将其视为已初始化。
+当重新加载配置时，将创建一个新规则集来替换活动规则集。
+如果加载的新规则集包含错误，即被破坏，则放置管理器将忽略新规则集。
Review comment:
放置管理器 -> 放置策略管理器
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/placement_rules.md
##########
@@ -0,0 +1,356 @@
+---
+id: placement_rules
+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#placement-rules-definition) 中有描述。
+一个放置策略可以连接多个规则。
+[访问控制列表](user_guide/acls.md) 和规则过滤器根据规则定义，并根据规则强制执行。
+本文档通过示例说明了如何构建作为调度器一部分的策略，包括规则用法。
+
+## 配置
+规则是作为调度器队列配置的一部分按分区定义的。
+规则的定义顺序就是规则的执行顺序。
+如果某个规则与策略匹配，则该策略将停止执行其余规则。
+
+匹配规则生成一个完全限定的队列名称。
+这意味着返回的名称从 _root_ 队列开始。
+可以生成的队列层次结构中的层级数目没有限制。
+
+当执行规则时，已执行规则的结果是未知的，不会被考虑在内。
+与尚未执行的规则类似：规则不能影响其他规则，除非它们被配置为 [父级](#parent-parameter) 规则。
+
+如果策略不生成队列名称并且没有更多规则，则应用程序将被拒绝。
+
+配置中规则放置定义的基本结构：
+```yaml
+placementrules:
+ - name: <第一个规则名称>
+ - name: <第二个规则名称>
+```
+每个规则都可以在配置中采用一组预定义的参数。
+[规则](#rules) 章节的描述中给出了可以使用的规则名称。
+配置中的规则名称不区分大小写。
+规则名称必须遵循以下命名约定：
+* 以字母开头：a-z 或 A-Z
+* 后跟 0 个或多个字符 a-z、A-Z、0-9 或 _
+
+未知的规则，即名称未映射到下面定义的规则，将导致放置管理器的初始化错误。
+如果参数不正确，规则也可以在初始化期间抛出解析异常或错误。
+有错误的规则集永远不会变为活动状态。
+
+如果放置管理器具有活动规则集，则将其视为已初始化。
+当重新加载配置时，将创建一个新规则集来替换活动规则集。
+如果加载的新规则集包含错误，即被破坏，则放置管理器将忽略新规则集。
+这意味着放置管理器保持在加载损坏的规则集时的状态。
+如果放置管理器在已经初始化的情况下继续使用现有的活动规则集，它将记录有关损坏和忽略的配置的消息。
+
+规则结果中的 点 "." 字符串会被替换为 "\_dot_" 。
+点被替换的原因是因为它用作完全限定队列名称中的层次结构分隔符。
Review comment:
点被替换的原因是它在定义资源队列时被用作父队列与子队列中间的分隔符。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/placement_rules.md
##########
@@ -0,0 +1,356 @@
+---
+id: placement_rules
+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#placement-rules-definition) 中有描述。
+一个放置策略可以连接多个规则。
+[访问控制列表](user_guide/acls.md) 和规则过滤器根据规则定义，并根据规则强制执行。
+本文档通过示例说明了如何构建作为调度器一部分的策略，包括规则用法。
+
+## 配置
+规则是作为调度器队列配置的一部分按分区定义的。
+规则的定义顺序就是规则的执行顺序。
+如果某个规则与策略匹配，则该策略将停止执行其余规则。
+
+匹配规则生成一个完全限定的队列名称。
+这意味着返回的名称从 _root_ 队列开始。
+可以生成的队列层次结构中的层级数目没有限制。
+
+当执行规则时，已执行规则的结果是未知的，不会被考虑在内。
+与尚未执行的规则类似：规则不能影响其他规则，除非它们被配置为 [父级](#parent-parameter) 规则。
+
+如果策略不生成队列名称并且没有更多规则，则应用程序将被拒绝。
+
+配置中规则放置定义的基本结构：
+```yaml
+placementrules:
+ - name: <第一个规则名称>
+ - name: <第二个规则名称>
+```
+每个规则都可以在配置中采用一组预定义的参数。
+[规则](#rules) 章节的描述中给出了可以使用的规则名称。
+配置中的规则名称不区分大小写。
+规则名称必须遵循以下命名约定：
+* 以字母开头：a-z 或 A-Z
+* 后跟 0 个或多个字符 a-z、A-Z、0-9 或 _
+
+未知的规则，即名称未映射到下面定义的规则，将导致放置管理器的初始化错误。
+如果参数不正确，规则也可以在初始化期间抛出解析异常或错误。
+有错误的规则集永远不会变为活动状态。
+
+如果放置管理器具有活动规则集，则将其视为已初始化。
Review comment:
放置管理器 -> 放置策略管理器
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/get_started/get_started.md
##########
@@ -0,0 +1,71 @@
+---
+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 Charts在现有的Kubernetes集群上部署YuniKorn。
+我们建议使用Helm 3或更高版本。
+
+```shell script
+helm repo add yunikorn https://apache.github.io/incubator-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的charts，您可以找到我们的细节教程 [点击这里](../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
+kubectl port-forward svc/yunikorn-service 9080:9080 -n yunikorn
+```
+
+`9889` 是 Web UI 的默认端口, `9080` 是调度器 Restful 服务的默认端口，web UI 会从中检索信息。
+完成此操作后，web UI将在以下地址可用: http://localhost:9889 。
Review comment:
`9889` 是 Web UI 的默认端口 。 完成此操作后，web UI将在以下地址可用: http://localhost:9889 。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/placement_rules.md
##########
@@ -0,0 +1,356 @@
+---
+id: placement_rules
+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#placement-rules-definition) 中有描述。
+一个放置策略可以连接多个规则。
+[访问控制列表](user_guide/acls.md) 和规则过滤器根据规则定义，并根据规则强制执行。
+本文档通过示例说明了如何构建作为调度器一部分的策略，包括规则用法。
+
+## 配置
+规则是作为调度器队列配置的一部分按分区定义的。
+规则的定义顺序就是规则的执行顺序。
+如果某个规则与策略匹配，则该策略将停止执行其余规则。
+
+匹配规则生成一个完全限定的队列名称。
+这意味着返回的名称从 _root_ 队列开始。
+可以生成的队列层次结构中的层级数目没有限制。
+
+当执行规则时，已执行规则的结果是未知的，不会被考虑在内。
+与尚未执行的规则类似：规则不能影响其他规则，除非它们被配置为 [父级](#parent-parameter) 规则。
+
+如果策略不生成队列名称并且没有更多规则，则应用程序将被拒绝。
+
+配置中规则放置定义的基本结构：
+```yaml
+placementrules:
+ - name: <第一个规则名称>
+ - name: <第二个规则名称>
+```
+每个规则都可以在配置中采用一组预定义的参数。
+[规则](#rules) 章节的描述中给出了可以使用的规则名称。
+配置中的规则名称不区分大小写。
+规则名称必须遵循以下命名约定：
+* 以字母开头：a-z 或 A-Z
+* 后跟 0 个或多个字符 a-z、A-Z、0-9 或 _
+
+未知的规则，即名称未映射到下面定义的规则，将导致放置管理器的初始化错误。
+如果参数不正确，规则也可以在初始化期间抛出解析异常或错误。
+有错误的规则集永远不会变为活动状态。
+
+如果放置管理器具有活动规则集，则将其视为已初始化。
+当重新加载配置时，将创建一个新规则集来替换活动规则集。
+如果加载的新规则集包含错误，即被破坏，则放置管理器将忽略新规则集。
+这意味着放置管理器保持在加载损坏的规则集时的状态。
+如果放置管理器在已经初始化的情况下继续使用现有的活动规则集，它将记录有关损坏和忽略的配置的消息。
+
+规则结果中的 点 "." 字符串会被替换为 "\_dot_" 。
+点被替换的原因是因为它用作完全限定队列名称中的层次结构分隔符。
+替换点发生在构建完整队列层次结构并且结果合格之前。
+这意味着我们允许用户名和/或标签值包含点，而这些点不会影响队列层次结构。
+例如，对于配置中必须用点映射到用户名的队列，您必须按如下方式指定它们：
+具有用户 `user.name` 的用户规则将生成队列名称 `root.user_dot_name` 作为输出。
+如果必须将该“用户队列”添加到配置中，则应使用 `user_dot_name` 名称。
+
+### creat 参数
+create 参数是一个布尔标志，它定义如果由规则生成的队列不存在时是否可以创建它。
+我们无法保证队列是否能创建，因为现有队列可能会阻止创建队列。
+如果规则生成的队列不存在且标志未设置为 _true_ ，则规则的结果将失败。
+
+带有 `create` 标志的规则的基本 yaml 配置：
+```yaml
+placementrules:
+ - name: <规则名称>
+ create: true
+```
+
+默认值为 _false_ 。
+允许值：_true_ 或 _false_，任何其他值都会导致解析错误。
+
+### parent 参数
+parent 参数允许指定为当前规则生成父队列的规则。
+父规则可以嵌套，一个父规则 _可以_ 包含另一个父规则。
+可以嵌套的父规则没有强制限制。
+
+父规则被视为在列表顶层指定的规则，因此与放置定义中的任何其他规则具有相同的参数和要求。
+例外情况是，在已生成完全限定队列的规则上使用父规则被视为配置错误。
+此错误只会出现在 [fixed](#fixed-rule) 类型的规则上，有关详细信息，请参阅规则规范。
+
+注意：规则的执行会向下遍历父规则列表，并首先执行列表中的最后一个。
+这意味着最后一个父规则将在根的正下方生成队列。
+有关详细信息，请参阅示例。
+
+具有 `parent` 规则的规则的基本 yaml 配置：
+```yaml
+placementrules:
+ - name: <规则名称>
+ parent:
+ name: <父规则名称>
+```
+
+parent 的默认值为 _no_ 。
+
+### filter 参数
+规则上的 filter 允许过滤该规则适用的用户。
+filter 是一个复杂的配置对象。
+
+可配置的 _用户_ 和 _组_ 可以是以下两种类型之一：
+* 一个正则表达式
+* 用户或组的列表。
+
+如果用户或组的条目在 yaml 中超过1条，则始终将其视为用户或组的列表。
+列表中的重复条目将被忽略并且不会导致错误。
+不允许在其他列表元素以外指定正则表达式。
+
+用户和组名遵循标准的 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:
+ - <用户名称或正则表达式>
+ - <用户名称>
+ groups:
+ - <组名称或正则表达式>
+ - <组名称>
+```
+
+filter 的默认值为 _no_ 。
+
+### value 参数
+这是一个通用值，可用于传递给规则以实现或更改其行为。
+value 被 [fixed](#fixed-rule) 和 [tag](#tag-rule) 规则使用。
+value 是字符串形式的单个值，不会被系统解释或操作。
+
+设置了 `value` 的规则的基本 yaml 配置：
+```yaml
+placementrules:
+ - name: <规则名称>
+ value: "任意string"
+```
+
+值的默认值为 _no_ 。
+
+## 访问控制列表
+访问控制列表不在规则中定义，但它们会影响放置策略的结果。
+可以在队列上定义两个访问控制列表：
+1.提交 ACL：_submitacl_
+1.管理 ACL：_adminacl_
+
+只有当队列允许通过任一 ACL 进行提交访问时，放置规则才会匹配。
+管理队列 ACL 还提供 _提交_ 访问。
+如果队列不存在或没有设置 ACL，则检查父队列的 ACL。
+重复此递归检查，直到 ACL 提供访问权限或在检查根队列的 ACL 之后。
+
+有关 ACL 语法的更多详细信息，请查看 [ACL 文档](user_guide/acls.md)。
+
+## 规则
+### Provided 规则
+配置中使用的名称：*provided*
+
+返回在提交应用程序期间提供的队列。
+如果队列不是完全限定的，则此规则的行为是完全限定应用程序提供的队列。
+如果设置了父规则，并且应用程序提交中提供的队列完全合格，则不会执行父规则。
Review comment:
原文可能有点问题。
这里想表达的意思是：如果所指定的队列名为全域名 （ 例如 root.a.b.c），那么该应用会被提交到该全域名所指向的队列并忽略其他规则；如果所指定的队列名为非全域名，该规则的父规则将得以执行以此来决定全域名。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/queue_config.md
##########
@@ -0,0 +1,349 @@
+---
+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) 文档。
Review comment:
本文档提供了通用队列配置的相关信息。请同时参考 [访问控制列表](user_guide/acls.md) 和 [放置规则](user_guide/placement_rules.md) 文档。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/queue_config.md
##########
@@ -0,0 +1,349 @@
+---
+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) 中给出。
Review comment:
队列配置的基本信息在 [配置设计文档](design/scheduler_configuration.md) 中有描述。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/queue_config.md
##########
@@ -0,0 +1,349 @@
+---
+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` 更改文件名。
+更改文件名后必须在 deployment 详细信息中进行相应的更改，无论是 `configmap` 还是包含在 docker 容器中的文件。
+
+配置的示例文件位于调度器核心内 [queues.yaml](https://github.com/apache/incubator-yunikorn-core/blob/master/config/queues.yaml)。
+
+## 分区
+分区是调度器配置的顶层。
+配置中可以定义多个分区。
+
+配置中分区定义的基本结构：
+```yaml
+partitions:
+ - name: <name of the 1st partition>
+ - name: <name of the 2nd partition>
+```
+分区的默认名称是 `default`。
+分区定义包含特定 shim 的调度程器的完整配置。
+每个 shim 使用自己唯一的分区。
+
+分区必须至少定义以下键：
+* 名称
+* [队列](#queues)
+
+队列配置释义如下。
+
+可以选择为分区定义以下键：
+* [布置规则](#placement-rules)
+* [限制](#limits)
+* 节点排序策略
+* 抢占
+
+布置规则和限制在它们自己的章节中进行了详解
+
+`nodesortpolicy` 定义了节点为分区排序的方式。
+可以使用的值的详细信息在 [排序策略](sorting_policies.md#node-sorting) 文档中可以参考。
+
+抢占键目前只能有一个子键：_enabled_ 。
+这个布尔值定义了整个分区的抢占行为。
+
+_enabled_ 的默认值为 _false_ 。
+允许值：_true_ 或 _false_ ，任何其他值都会导致解析错误。
+
+设置了 _preemption_ 标志和 `nodesortpolicy` 为 _fair_ 的示例 `partition` yaml 描述：
+```yaml
+partitions:
+ - name: <分区名称>
+ nodesortpolicy: fair
+ preemption:
+ enabled: true
+```
+注意:
+目前，Kubernetes 唯一的 shim 不支持除 `default` 分区之外的任何其他分区。
+这已为 shim 在 [jira](https://issues.apache.org/jira/browse/YUNIKORN-22) 上进行了记录。
Review comment:
> 目前，Kubernetes 唯一的 shim 不支持除 `default` 分区之外的任何其他分区。
这已为 shim 在 [jira](https://issues.apache.org/jira/browse/YUNIKORN-22) 上进行了记录
目前，YuniKorn在Kubernetes上不支持除 `default` 分区之外的任何其他分区。详情请见： [YUNIKORN-22](https://issues.apache.org/jira/browse/YUNIKORN-22)
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/placement_rules.md
##########
@@ -0,0 +1,356 @@
+---
+id: placement_rules
+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#placement-rules-definition) 中有描述。
+一个放置策略可以连接多个规则。
+[访问控制列表](user_guide/acls.md) 和规则过滤器根据规则定义，并根据规则强制执行。
+本文档通过示例说明了如何构建作为调度器一部分的策略，包括规则用法。
+
+## 配置
+规则是作为调度器队列配置的一部分按分区定义的。
+规则的定义顺序就是规则的执行顺序。
+如果某个规则与策略匹配，则该策略将停止执行其余规则。
+
+匹配规则生成一个完全限定的队列名称。
+这意味着返回的名称从 _root_ 队列开始。
+可以生成的队列层次结构中的层级数目没有限制。
+
+当执行规则时，已执行规则的结果是未知的，不会被考虑在内。
+与尚未执行的规则类似：规则不能影响其他规则，除非它们被配置为 [父级](#parent-parameter) 规则。
+
+如果策略不生成队列名称并且没有更多规则，则应用程序将被拒绝。
+
+配置中规则放置定义的基本结构：
+```yaml
+placementrules:
+ - name: <第一个规则名称>
+ - name: <第二个规则名称>
+```
+每个规则都可以在配置中采用一组预定义的参数。
+[规则](#rules) 章节的描述中给出了可以使用的规则名称。
+配置中的规则名称不区分大小写。
+规则名称必须遵循以下命名约定：
+* 以字母开头：a-z 或 A-Z
+* 后跟 0 个或多个字符 a-z、A-Z、0-9 或 _
+
+未知的规则，即名称未映射到下面定义的规则，将导致放置管理器的初始化错误。
+如果参数不正确，规则也可以在初始化期间抛出解析异常或错误。
+有错误的规则集永远不会变为活动状态。
+
+如果放置管理器具有活动规则集，则将其视为已初始化。
+当重新加载配置时，将创建一个新规则集来替换活动规则集。
+如果加载的新规则集包含错误，即被破坏，则放置管理器将忽略新规则集。
+这意味着放置管理器保持在加载损坏的规则集时的状态。
+如果放置管理器在已经初始化的情况下继续使用现有的活动规则集，它将记录有关损坏和忽略的配置的消息。
+
+规则结果中的 点 "." 字符串会被替换为 "\_dot_" 。
+点被替换的原因是因为它用作完全限定队列名称中的层次结构分隔符。
+替换点发生在构建完整队列层次结构并且结果合格之前。
+这意味着我们允许用户名和/或标签值包含点，而这些点不会影响队列层次结构。
+例如，对于配置中必须用点映射到用户名的队列，您必须按如下方式指定它们：
+具有用户 `user.name` 的用户规则将生成队列名称 `root.user_dot_name` 作为输出。
+如果必须将该“用户队列”添加到配置中，则应使用 `user_dot_name` 名称。
+
+### creat 参数
+create 参数是一个布尔标志，它定义如果由规则生成的队列不存在时是否可以创建它。
+我们无法保证队列是否能创建，因为现有队列可能会阻止创建队列。
+如果规则生成的队列不存在且标志未设置为 _true_ ，则规则的结果将失败。
+
+带有 `create` 标志的规则的基本 yaml 配置：
+```yaml
+placementrules:
+ - name: <规则名称>
+ create: true
+```
+
+默认值为 _false_ 。
+允许值：_true_ 或 _false_，任何其他值都会导致解析错误。
+
+### parent 参数
+parent 参数允许指定为当前规则生成父队列的规则。
+父规则可以嵌套，一个父规则 _可以_ 包含另一个父规则。
+可以嵌套的父规则没有强制限制。
+
+父规则被视为在列表顶层指定的规则，因此与放置定义中的任何其他规则具有相同的参数和要求。
+例外情况是，在已生成完全限定队列的规则上使用父规则被视为配置错误。
+此错误只会出现在 [fixed](#fixed-rule) 类型的规则上，有关详细信息，请参阅规则规范。
+
+注意：规则的执行会向下遍历父规则列表，并首先执行列表中的最后一个。
+这意味着最后一个父规则将在根的正下方生成队列。
+有关详细信息，请参阅示例。
+
+具有 `parent` 规则的规则的基本 yaml 配置：
+```yaml
+placementrules:
+ - name: <规则名称>
+ parent:
+ name: <父规则名称>
+```
+
+parent 的默认值为 _no_ 。
+
+### filter 参数
+规则上的 filter 允许过滤该规则适用的用户。
+filter 是一个复杂的配置对象。
+
+可配置的 _用户_ 和 _组_ 可以是以下两种类型之一：
+* 一个正则表达式
+* 用户或组的列表。
+
+如果用户或组的条目在 yaml 中超过1条，则始终将其视为用户或组的列表。
+列表中的重复条目将被忽略并且不会导致错误。
+不允许在其他列表元素以外指定正则表达式。
+
+用户和组名遵循标准的 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:
+ - <用户名称或正则表达式>
+ - <用户名称>
+ groups:
+ - <组名称或正则表达式>
+ - <组名称>
+```
+
+filter 的默认值为 _no_ 。
+
+### value 参数
+这是一个通用值，可用于传递给规则以实现或更改其行为。
+value 被 [fixed](#fixed-rule) 和 [tag](#tag-rule) 规则使用。
+value 是字符串形式的单个值，不会被系统解释或操作。
+
+设置了 `value` 的规则的基本 yaml 配置：
+```yaml
+placementrules:
+ - name: <规则名称>
+ value: "任意string"
+```
+
+值的默认值为 _no_ 。
+
+## 访问控制列表
+访问控制列表不在规则中定义，但它们会影响放置策略的结果。
+可以在队列上定义两个访问控制列表：
+1.提交 ACL：_submitacl_
+1.管理 ACL：_adminacl_
+
+只有当队列允许通过任一 ACL 进行提交访问时，放置规则才会匹配。
+管理队列 ACL 还提供 _提交_ 访问。
+如果队列不存在或没有设置 ACL，则检查父队列的 ACL。
+重复此递归检查，直到 ACL 提供访问权限或在检查根队列的 ACL 之后。
+
+有关 ACL 语法的更多详细信息，请查看 [ACL 文档](user_guide/acls.md)。
+
+## 规则
+### Provided 规则
+配置中使用的名称：*provided*
+
+返回在提交应用程序期间提供的队列。
+如果队列不是完全限定的，则此规则的行为是完全限定应用程序提供的队列。
+如果设置了父规则，并且应用程序提交中提供的队列完全合格，则不会执行父规则。
+
+支持的参数:
+* create
+* parent
+* filter
+
+示例：如果用户名称不存在，则创建由用户传递的队列
Review comment:
> 示例：如果用户名称不存在，则创建由用户传递的队列
示例：如果用户指定的队列不存在与给定的用户名的父队列下，则创建它
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/queue_config.md
##########
@@ -0,0 +1,349 @@
+---
+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` 更改文件名。
+更改文件名后必须在 deployment 详细信息中进行相应的更改，无论是 `configmap` 还是包含在 docker 容器中的文件。
+
+配置的示例文件位于调度器核心内 [queues.yaml](https://github.com/apache/incubator-yunikorn-core/blob/master/config/queues.yaml)。
+
+## 分区
+分区是调度器配置的顶层。
+配置中可以定义多个分区。
+
+配置中分区定义的基本结构：
+```yaml
+partitions:
+ - name: <name of the 1st partition>
+ - name: <name of the 2nd partition>
+```
+分区的默认名称是 `default`。
+分区定义包含特定 shim 的调度程器的完整配置。
+每个 shim 使用自己唯一的分区。
+
+分区必须至少定义以下键：
+* 名称
+* [队列](#queues)
+
+队列配置释义如下。
+
+可以选择为分区定义以下键：
+* [布置规则](#placement-rules)
+* [限制](#limits)
+* 节点排序策略
+* 抢占
+
+布置规则和限制在它们自己的章节中进行了详解
+
+`nodesortpolicy` 定义了节点为分区排序的方式。
+可以使用的值的详细信息在 [排序策略](sorting_policies.md#node-sorting) 文档中可以参考。
+
+抢占键目前只能有一个子键：_enabled_ 。
+这个布尔值定义了整个分区的抢占行为。
+
+_enabled_ 的默认值为 _false_ 。
+允许值：_true_ 或 _false_ ，任何其他值都会导致解析错误。
+
+设置了 _preemption_ 标志和 `nodesortpolicy` 为 _fair_ 的示例 `partition` yaml 描述：
+```yaml
+partitions:
+ - name: <分区名称>
+ nodesortpolicy: fair
+ preemption:
+ enabled: true
+```
+注意:
+目前，Kubernetes 唯一的 shim 不支持除 `default` 分区之外的任何其他分区。
+这已为 shim 在 [jira](https://issues.apache.org/jira/browse/YUNIKORN-22) 上进行了记录。
+
+### 队列
+
+YuniKorn 通过利用资源队列来管理资源。资源队列具有以下特征：
+- 队列可以有 **等级制的** 结构
+- 每个队列都可以预设 **最小/最大容量** ，其中最小容量定义了保障资源，最大容量定义了资源限制（又名资源配额）
+- 任务必须在某个子队列下运行
+- 队列可以是 **静态的**（从配置文件加载）或 **动态的**（由 YuniKorn 内部管理）
+- 队列级别 **资源公平** 由调度器强制执行
+- 作业只能在特定队列下运行
Review comment:
a job can only run under a specific queue
这句话想表达是
一个作业只能运行在某一个特定的队列，即一个作业无法垮队列运行。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/queue_config.md
##########
@@ -0,0 +1,349 @@
+---
+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` 更改文件名。
+更改文件名后必须在 deployment 详细信息中进行相应的更改，无论是 `configmap` 还是包含在 docker 容器中的文件。
+
+配置的示例文件位于调度器核心内 [queues.yaml](https://github.com/apache/incubator-yunikorn-core/blob/master/config/queues.yaml)。
+
+## 分区
+分区是调度器配置的顶层。
+配置中可以定义多个分区。
+
+配置中分区定义的基本结构：
+```yaml
+partitions:
+ - name: <name of the 1st partition>
+ - name: <name of the 2nd partition>
+```
+分区的默认名称是 `default`。
+分区定义包含特定 shim 的调度程器的完整配置。
+每个 shim 使用自己唯一的分区。
+
+分区必须至少定义以下键：
+* 名称
+* [队列](#queues)
+
+队列配置释义如下。
+
+可以选择为分区定义以下键：
+* [布置规则](#placement-rules)
+* [限制](#limits)
+* 节点排序策略
+* 抢占
+
+布置规则和限制在它们自己的章节中进行了详解
+
+`nodesortpolicy` 定义了节点为分区排序的方式。
+可以使用的值的详细信息在 [排序策略](sorting_policies.md#node-sorting) 文档中可以参考。
+
+抢占键目前只能有一个子键：_enabled_ 。
+这个布尔值定义了整个分区的抢占行为。
+
+_enabled_ 的默认值为 _false_ 。
+允许值：_true_ 或 _false_ ，任何其他值都会导致解析错误。
+
+设置了 _preemption_ 标志和 `nodesortpolicy` 为 _fair_ 的示例 `partition` yaml 描述：
+```yaml
+partitions:
+ - name: <分区名称>
+ nodesortpolicy: fair
+ preemption:
+ enabled: true
+```
+注意:
+目前，Kubernetes 唯一的 shim 不支持除 `default` 分区之外的任何其他分区。
+这已为 shim 在 [jira](https://issues.apache.org/jira/browse/YUNIKORN-22) 上进行了记录。
+
+### 队列
+
+YuniKorn 通过利用资源队列来管理资源。资源队列具有以下特征：
+- 队列可以有 **等级制的** 结构
+- 每个队列都可以预设 **最小/最大容量** ，其中最小容量定义了保障资源，最大容量定义了资源限制（又名资源配额）
+- 任务必须在某个子队列下运行
Review comment:
leaf queue 应该翻译为 叶子队列 （即没有子队列的队列）
##########
File path: i18n/zh-cn/docusaurus-plugin-content-pages/community/events.md
##########
@@ -0,0 +1,61 @@
+---
+id: events
+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.
+-->
+
+即将举行的会议
+---
+
+加入我们 **4:30pm - 6:00pm，太平洋标准时间，2021 年 11 月 18 日**
+
+**Wilfred Spiegelenburg** 将向我们介绍 YuniKorn 社区的最新状态。不要错过！将此事件添加到您的日历：[:calendar:](https://calendar.google.com/event?action=TEMPLATE&tmeid=NHE2a2Vvc3FucDRhbDhmamowNGllcmRka24gYXBhY2hlLnl1bmlrb3JuQG0&tmsrc=apache.yunikorn%40gmail.com)
+
+_Abstract_: Apache YuniKorn (Incubating) 今年早些时候发布了 v0.11 版本，其中包含了许多新功能和改进，比如 Gang 调度、REST API 增强和 Kubernetes 1.19 支持。
+在一个月内，我们计划发布主要的 v1.0.0 版本，它将支持 Kubernetes 1.20 和 1.21、改进的节点排序以及大量的小修复和增强功能！
+在本次会议中，我们将深入探讨在 Kubernetes 上使用临时占位 pod 背后的帮派调度实现、通过简化的调度器核心代码和新的节点排序算法显著提高性能。
Review comment:
感觉gang scheduling翻译成帮派调度有点奇怪
要不然这个就不要翻译，直接gang scheduling以避免误导用户
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/placement_rules.md
##########
@@ -0,0 +1,356 @@
+---
+id: placement_rules
+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#placement-rules-definition) 中有描述。
+一个放置策略可以连接多个规则。
+[访问控制列表](user_guide/acls.md) 和规则过滤器根据规则定义，并根据规则强制执行。
+本文档通过示例说明了如何构建作为调度器一部分的策略，包括规则用法。
+
+## 配置
+规则是作为调度器队列配置的一部分按分区定义的。
+规则的定义顺序就是规则的执行顺序。
+如果某个规则与策略匹配，则该策略将停止执行其余规则。
+
+匹配规则生成一个完全限定的队列名称。
+这意味着返回的名称从 _root_ 队列开始。
+可以生成的队列层次结构中的层级数目没有限制。
+
+当执行规则时，已执行规则的结果是未知的，不会被考虑在内。
+与尚未执行的规则类似：规则不能影响其他规则，除非它们被配置为 [父级](#parent-parameter) 规则。
+
+如果策略不生成队列名称并且没有更多规则，则应用程序将被拒绝。
+
+配置中规则放置定义的基本结构：
+```yaml
+placementrules:
+ - name: <第一个规则名称>
+ - name: <第二个规则名称>
+```
+每个规则都可以在配置中采用一组预定义的参数。
+[规则](#rules) 章节的描述中给出了可以使用的规则名称。
+配置中的规则名称不区分大小写。
+规则名称必须遵循以下命名约定：
+* 以字母开头：a-z 或 A-Z
+* 后跟 0 个或多个字符 a-z、A-Z、0-9 或 _
+
+未知的规则，即名称未映射到下面定义的规则，将导致放置管理器的初始化错误。
+如果参数不正确，规则也可以在初始化期间抛出解析异常或错误。
+有错误的规则集永远不会变为活动状态。
+
+如果放置管理器具有活动规则集，则将其视为已初始化。
+当重新加载配置时，将创建一个新规则集来替换活动规则集。
+如果加载的新规则集包含错误，即被破坏，则放置管理器将忽略新规则集。
+这意味着放置管理器保持在加载损坏的规则集时的状态。
+如果放置管理器在已经初始化的情况下继续使用现有的活动规则集，它将记录有关损坏和忽略的配置的消息。
+
+规则结果中的 点 "." 字符串会被替换为 "\_dot_" 。
+点被替换的原因是因为它用作完全限定队列名称中的层次结构分隔符。
+替换点发生在构建完整队列层次结构并且结果合格之前。
+这意味着我们允许用户名和/或标签值包含点，而这些点不会影响队列层次结构。
+例如，对于配置中必须用点映射到用户名的队列，您必须按如下方式指定它们：
+具有用户 `user.name` 的用户规则将生成队列名称 `root.user_dot_name` 作为输出。
+如果必须将该“用户队列”添加到配置中，则应使用 `user_dot_name` 名称。
+
+### creat 参数
+create 参数是一个布尔标志，它定义如果由规则生成的队列不存在时是否可以创建它。
+我们无法保证队列是否能创建，因为现有队列可能会阻止创建队列。
+如果规则生成的队列不存在且标志未设置为 _true_ ，则规则的结果将失败。
+
+带有 `create` 标志的规则的基本 yaml 配置：
+```yaml
+placementrules:
+ - name: <规则名称>
+ create: true
+```
+
+默认值为 _false_ 。
+允许值：_true_ 或 _false_，任何其他值都会导致解析错误。
+
+### parent 参数
+parent 参数允许指定为当前规则生成父队列的规则。
+父规则可以嵌套，一个父规则 _可以_ 包含另一个父规则。
+可以嵌套的父规则没有强制限制。
+
+父规则被视为在列表顶层指定的规则，因此与放置定义中的任何其他规则具有相同的参数和要求。
+例外情况是，在已生成完全限定队列的规则上使用父规则被视为配置错误。
+此错误只会出现在 [fixed](#fixed-rule) 类型的规则上，有关详细信息，请参阅规则规范。
+
+注意：规则的执行会向下遍历父规则列表，并首先执行列表中的最后一个。
+这意味着最后一个父规则将在根的正下方生成队列。
+有关详细信息，请参阅示例。
+
+具有 `parent` 规则的规则的基本 yaml 配置：
+```yaml
+placementrules:
+ - name: <规则名称>
+ parent:
+ name: <父规则名称>
+```
+
+parent 的默认值为 _no_ 。
+
+### filter 参数
+规则上的 filter 允许过滤该规则适用的用户。
+filter 是一个复杂的配置对象。
+
+可配置的 _用户_ 和 _组_ 可以是以下两种类型之一：
+* 一个正则表达式
+* 用户或组的列表。
+
+如果用户或组的条目在 yaml 中超过1条，则始终将其视为用户或组的列表。
+列表中的重复条目将被忽略并且不会导致错误。
+不允许在其他列表元素以外指定正则表达式。
+
+用户和组名遵循标准的 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:
+ - <用户名称或正则表达式>
+ - <用户名称>
+ groups:
+ - <组名称或正则表达式>
+ - <组名称>
+```
+
+filter 的默认值为 _no_ 。
+
+### value 参数
+这是一个通用值，可用于传递给规则以实现或更改其行为。
+value 被 [fixed](#fixed-rule) 和 [tag](#tag-rule) 规则使用。
+value 是字符串形式的单个值，不会被系统解释或操作。
+
+设置了 `value` 的规则的基本 yaml 配置：
+```yaml
+placementrules:
+ - name: <规则名称>
+ value: "任意string"
+```
+
+值的默认值为 _no_ 。
+
+## 访问控制列表
+访问控制列表不在规则中定义，但它们会影响放置策略的结果。
+可以在队列上定义两个访问控制列表：
+1.提交 ACL：_submitacl_
+1.管理 ACL：_adminacl_
+
+只有当队列允许通过任一 ACL 进行提交访问时，放置规则才会匹配。
+管理队列 ACL 还提供 _提交_ 访问。
+如果队列不存在或没有设置 ACL，则检查父队列的 ACL。
+重复此递归检查，直到 ACL 提供访问权限或在检查根队列的 ACL 之后。
+
+有关 ACL 语法的更多详细信息，请查看 [ACL 文档](user_guide/acls.md)。
+
+## 规则
+### Provided 规则
+配置中使用的名称：*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*
+
+根据作为提交应用程序一部分的用户名返回队列。
+
+支持的参数:
+* create
+* parent
+* filter
+
+示例：根据用户名提交到队列，如果队列不存在则不创建队列：
+```yaml
+placementrules:
+ - name: user
+ create: false
+```
+
+使用 `finance.test` 作为用户进行应用提交请求，队列确实存在：<br/>
+结果：`root.finance_dot_test`（注意点 dot 的替换）
+
+使用 `developer` 作为用户进行应用提交请求，队列不存在：<br/>
+结果：失败，执行下一条规则
+
+### 固定规则
+配置中使用的名称：*fixed*
+
+返回在规则参数 _value_ 中配置的名称。
+配置的值必须是合法的队列名称或队列层次结构。
+该名称不必是完全限定的队列名称。
Review comment:
full qualified 最好翻译为全域名？全文需要用统一该翻译
##########
File path: i18n/zh-cn/docusaurus-plugin-content-pages/community/get_involved.md
##########
@@ -0,0 +1,125 @@
+---
+id: get_involved
+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.
+-->
+
+# 进行参与
+
+Apache YuniKorn（Incubating）社区非常多样化，我们有来自阿里巴巴、苹果、Cloudera、Linkedin、微软、Nvidia、腾讯、优步等（按英文字母顺序排序）。
+社区深信这种多样性的重要性和 “The Apache Way” 的价值。
+我们欢迎任何形式的贡献、代码、文档或建议！:smiley: 别等了，现在就加入我们吧！
+
+## 如何加入 YuniKorn 社区
+
+请通过以下渠道之一加入我们：
+
+### 通过 github 贡献
+- 这里解释了贡献项目的基本步骤 - [如何贡献](how_to_contribute)
+
+### 沟通渠道
+
+- Mailing lists:
+ - 对于希望为项目开发做出贡献或讨论的人: [dev@yunikorn.apache.org](mailto:dev@yunikorn.apache.org)
+ 订阅: dev@ [订阅](mailto:dev-subscribe@yunikorn.apache.org?subject="subscribe%20to%20YuniKorn%20dev%20list") ([退订](mailto:dev-unsubscribe@yunikorn.apache.org?subject="unsubscribe%20from%20YuniKorn%20dev%20list") [归档](https://lists.apache.org/list.html?dev@yunikorn.apache.org))
+ - 对于 JIRA 问题更新订阅: issues@ [订阅](mailto:issues-subscribe@yunikorn.apache.org?subject="subscribe%20to%20YuniKorn%20issues%20list") ([退订](mailto:issues-unsubscribe@yunikorn.apache.org?subject="unsubscribe%20from%20YuniKorn%20issues%20list") [归档](https://lists.apache.org/list.html?issues@yunikorn.apache.org))
+ - 对于 GitHub 拉取请求消息订阅: reviews@ [订阅](mailto:reviews-subscribe@yunikorn.apache.org?subject="subscribe%20to%20YuniKorn%20reviews%20list") ([退订](mailto:reviews-unsubscribe@yunikorn.apache.org?subject="unsubscribe%20from%20YuniKorn%20reviews%20list") [归档](https://lists.apache.org/list.html?reviews@yunikorn.apache.org))
+
+
+- 我们使用 [Slack](https://slack.com/) 作为我们的协作系统， 您可以通过访问 [这个链接](https://join.slack.com/t/yunikornworkspace/shared_invite/enQtNzAzMjY0OTI4MjYzLTBmMDdkYTAwNDMwNTE3NWVjZWE1OTczMWE4NDI2Yzg3MmEyZjUyYTZlMDE5M2U4ZjZhNmYyNGFmYjY4ZGYyMGE) 来加入我们。
+目前，我们在工作区中有以下频道：`#yunikorn-dev` 和 `#yunikorn-user`。
+
+- 我们会定期进行多个时区和语言的社区同步，请查找[社区会议](#community-meetings) 来参加在线会议。
+
+### 社区会议
+
+#### 目标受众：
+- 有兴趣为 YuniKorn 项目做出贡献的开发人员。
+- 正在使用或有兴趣了解该项目的用户。
+
+#### 日程
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+<Tabs
+ defaultValue="scheduleEN"
+ values={[
+ {label: 'America/EU/India', value: 'scheduleEN'},
+ {label: '中文/Mandarin', value: 'scheduleCN'},
+ ]}>
+ <TabItem value="scheduleEN"> 📆 美国太平洋时间每周三上午 9:30 每两周一次。 <a href="https://cloudera.zoom.us/j/721195559">单击此处加入 Zoom 会议。</a> </TabItem>
+ <TabItem value="scheduleCN"> 📆 中国标准时间 (GMT+8) 每周三下午 1:00。 <a href="https://cloudera.zoom.us/j/721195559">单击此处加入 Zoom 会议。</a> </TabItem>
+</Tabs>
+
+#### 资源
+
+- 会议记录: [Google 文档](https://docs.google.com/document/d/165gzC7uhcKc5XDWiMYSRKBiPQBy2tDtXADUPuhGlUa0/edit#heading=h.461goivmz24v)
+
+- 日历: [Google 日历](https://calendar.google.com/calendar/b/3/r/week/2020/3/26?cid=YXBhY2hlLnl1bmlrb3JuQGdtYWlsLmNvbQ) :point_left:
+
+## 成为一个 Committer
+
+Committers 是对项目存储库具有写入权限的社区成员，
+即他们可以自己修改代码并接受其他人对所有 YuniKorn 存储库的贡献。
+PPMC 根据各种考虑对候选人进行投票：
+
+- 代码贡献
+ - 一致的代码贡献
+ - 优化 CI/CD 管道
+ - 帮助进行代码审查
+ - 测试和验证候选版本
+ - 性能调优及相关工具开发
+ - 提出改进建议
+
+- 非代码贡献
+ - 参与社区活动，如会议、聚会等。
+ - 提供反馈、报告问题并参与路线图讨论
+ - 项目发布帮助
+ - 改进项目文档
+ - 帮助项目采用
+ - 与其他项目集成，扩展用例
+
+contributor 或非 contributor 都可以成为 committer，社区非常感谢代码或非代码贡献。
+
+## 成为 PPMC 成员
+
+PPMC 为 Podling Project Management Committee。
+它负责项目管理、治理并确保项目可以在 [Apache Way](https://www.apache.org/theapacheway/) 下运行。
+委员会根据 PPMC 成员的投票做出决定。
+PPMC 成员有权对各种事情进行有约束力的投票，例如项目发布、添加新的提交者或 PPMC 成员等。
+
+在成为 PPMC 成员之前，贡献者必须先成为提交者。
+提交者何时有资格被添加到 PPMC 没有严格的规定。
+管理委员会根据每个提交者的参与和影响做出决定。
+一般来说，对项目做出一致的代码或非代码贡献的提交者应被视为 PPMC 候选人。
Review comment:
> 一般来说，对项目做出一致的代码或非代码贡献的提交者应被视为 PPMC 候选人。
一般来说，对项目做出持续的代码或非代码贡献的贡献者应被视为 PPMC 候选人。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/user_guide/usergroup_resolution.md
##########
@@ -0,0 +1,68 @@
+---
+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.
+-->
+
+## 用户解析
+
+用户信息是调度周期的一个重要方面。它是可用于确定作业应提交到的队列的关键标志之一。Yunikorn 调度器依靠 K8s Shim 来提供用户信息。在 Kubernetes 的世界中，没有定义识别实际用户的对象。这是设计使然，可以在 [此处](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) 找到更多信息。
Review comment:
Yunikorn -> YuniKorn 需要保持一致
请复查其他地方确保用词一致
##########
File path: i18n/zh-cn/docusaurus-plugin-content-pages/release-announce/0.10.0.md
##########
@@ -0,0 +1,54 @@
+---
+id: rn-0.10.0
+title: 发布公告 v0.10.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.
+-->
+# 发布公告 v0.10.0
+我们非常高兴地宣布 Apache YuniKorn (Incubating) 社区已投票发布 0.10.0。Apache YuniKorn (Incubating) 是一个独立的资源调度器，旨在管理和调度容器编排框架上的大数据工作负载，支持本地和云端的用例。
+
+此版本中添加的显著功能是联邦调度，YuniKorn 现在可以在 Kubernetes 上运行应用程序时提供联邦调度功能。除此之外，此版本还包括各种错误修复和改进。
+
+## 概述
+Apache YuniKorn (Incubating) 社区在此版本中修复了 187 个 JIRA 问题：[YuniKorn 在 0.10.0 中解决的 jira 问题](https://issues.apache.org/jira/issues/?filter=12349466)。
+
+发布负责人: Tao Yang
+
+发布时间: 2021-04-09
+
+## 主要更新
+
+### 支持的 Kubernetes 版本
+从此版本开始，支持的 Kubernetes 版本已更新为 1.16.x、1.17.x 和 1.18.x。（早期版本支持 1.13.x、1.14.x 和 1.15.x）YuniKorn 支持矩阵主要支持 3 个主要的 Kubernetes 版本。
+
+### 联邦调度
+在这个版本中，YuniKorn 开始支持联邦调度。用户可以将联邦应用于需要联邦调度语义的应用，如 Spark、Tensorflow、Pytorch 等。YuniKorn 主动为联邦调度应用预留资源，它与 cluster-autoscaler 配合使用更高效。初始的支持已经在 Spark 上进行了很好的测试，它可以与 K8s 上的原生 Spark 或 Spark K8s operator 一起使用。有关如何启用和使用联邦调度的更多信息，请阅读 [此处](/docs/user_guide/gang_scheduling) 的文档。
Review comment:
请将 联邦调度 改名为 gang scheduling
##########
File path: i18n/zh-cn/docusaurus-plugin-content-pages/community/roadmap.md
##########
@@ -0,0 +1,57 @@
+---
+id: roadmap
+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.
+-->
+
+# 未来发展：长期的目标
+
+- 应用程序和任务优先级的支持
+- 抢占资源分配
+- 用户和组配额和限制执行
+- 除了当前的独立模式之外，还会提供另一种部署模式作为默认调度程序的插件
+
+# 下一个发布研发内容
+
+发布详情：
+- 版本：1.0.0
+- 目标发布日期：2022 年 3 月
+- 发布负责人：Wilfred Spiegelenburg
+- 开发状态：[问题跟踪器](https://issues.apache.org/jira/issues/?filter=12348416)
+
+计划的主要功能：
+- [YUNIKORN-971](https://issues.apache.org/jira/browse/YUNIKORN-971) 将 YuniKorn 实现为 Kubernetes 调度插件
+- [YUNIKORN-978](https://issues.apache.org/jira/browse/YUNIKORN-978) 准入控制器部署改进
+- [YUNIKORN-984](https://issues.apache.org/jira/browse/YUNIKORN-984) 实施用户和组限制（阶段 1）
+- [YUNIKORN-954](https://issues.apache.org/jira/browse/YUNIKORN-954) 移除旧的 REST api
+- [YUNIKORN-720](https://issues.apache.org/jira/browse/YUNIKORN-720) 改进了队列指标
Review comment:
对调度器资源队列指标监测系统的改进
##########
File path: i18n/zh-cn/docusaurus-plugin-content-pages/release-announce/0.11.0.md
##########
@@ -0,0 +1,57 @@
+---
+id: rn-0.11.0
+title: 发布公告 v0.11.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.
+-->
+# 发布公告 v0.11.0
+我们非常高兴地宣布 Apache YuniKorn (Incubating) 社区已投票发布 0.11.0。Apache YuniKorn (Incubating) 是一个独立的资源调度器，旨在管理和调度容器编排框架（如 Kubernetes）上的大数据工作负载，支持本地和云端的用例。
+此版本有几个 REST API、UI 可用性和联邦调度的改进。
Review comment:
联邦调度 - gang scheduling
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] yangwwei commented on pull request #108: [YUNIKORN-1031] Add Chinese translation for homepage
Posted by GitBox <gi...@apache.org>.
yangwwei commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1020856697
hi @cdmikechen any updates?
Please split this PR into smaller ones and link them to the sub-tasks under https://issues.apache.org/jira/browse/YUNIKORN-1029. Thanks
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] cdmikechen commented on pull request #108: [YUNIKORN-1031] Add Chinese translation for homepage
Posted by GitBox <gi...@apache.org>.
cdmikechen commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1023266115
@yangwwei
I've changed by your reviews. And I found we have added a new page (people.md) and I also add this to this PR.
The newest preview in <https://cdmikechen.github.io/incubator-yunikorn-site/zh-cn> , you can take a look at the final results.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] yangwwei commented on a change in pull request #108: [YUNIKORN-1031] Add Chinese translation for homepage
Posted by GitBox <gi...@apache.org>.
yangwwei commented on a change in pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#discussion_r793236038
##########
File path: i18n/zh-cn/docusaurus-plugin-content-pages/community/how_to_contribute.md
##########
@@ -0,0 +1,107 @@
+---
+id: how_to_contribute
+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 使用：
+* JIRA 用于问题跟踪。
+* GitHub 用于 Pull Requests(以后简称拉取请求)来管理代码审查和更改本身。
+* MarkDown 用于文档的源代码树。
+
+## 发现问题
+我们使用 JIRA 问题库来跟踪该项目的错误。
+找到您想要处理的问题，或者如果您发现了新问题，请提交新问题。
+有关报告问题的帮助，请查看 [如何报告问题](reporting_issues)。
+
+开始使用代码库的最简单方法是选择一个非常简单的 JIRA 问题并开始工作。
+这将帮助您熟悉代码库、构建系统、审查过程等。
+我们在 [此处](https://issues.apache.org/jira/issues/?jql=project%3DYUNIKORN%20AND%20status%3DOpen%20AND%20labels%3Dnewbie) 标记这些入门错误。
+
+如果没有人在处理现有问题，请您在只想打算尽快处理该问题时将其分配给自己。
+如果您选择现有的 JIRA，请查找链接到 JIRA ticket 的拉取请求。
+有人可能已经在处理它并且没有分配 ticket。
+具有拉取请求链接的 JIRA 将具有标签 `pull-request-available`，并且可以在问题链接下找到拉取请求的链接。
+
+对于任何不只是微不足道的更改，例如拼写错误或一行代码更改，讨论您在该问题上的预期方法是一个好主意。
+如果您在开始编写修复程序之前已经从 YuniKorn 社区获得了支持，那么您更有可能审查并提交您的补丁程序。
+
+如果您无法将 JIRA 分配给自己，请请求社区帮助分配并将您添加到 JIRA 的贡献者列表中。
+
+## 修复问题
+必须在 `master` 分支上创建修复或改进。
+将相关的 YuniKorn 项目 fork 到您自己的项目中并签出 `master` 分支。
+确保在开始之前签出最新的代码修订。
+创建一个分支来处理，一个好名字是你正在处理的 JIRA ID。
+
+现在可以开始编码了！在编写补丁时，请牢记以下几点：
+
+在您的补丁中需要包含测试。
+如果您的补丁添加了功能或修复了错误并且不包括测试，则通常不会被接受。
+如果您不确定如何为特定组件编写测试，请在 JIRA 上寻求指导。
+
+请让您的补丁只修改了 JIRA 描述的问题。
+如果我们对每个补丁的范围保持记录，这对每个人都会更好。
Review comment:
> 请让您的补丁只修改了 JIRA 描述的问题。如果我们对每个补丁的范围保持记录，这对每个人都会更好。
您的补丁应该只包含对 JIRA 描述的问题的修复，超过改范围应该由新的 JIRA 来跟踪。这样的原则有利于代码的维护和审核。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-pages/community/get_involved.md
##########
@@ -0,0 +1,125 @@
+---
+id: get_involved
+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.
+-->
+
+# 进行参与
+
+Apache YuniKorn（Incubating）社区非常多样化，我们有来自阿里巴巴、苹果、Cloudera、Linkedin、微软、Nvidia、腾讯、优步等（按英文字母顺序排序）。
+社区深信这种多样性的重要性和 “The Apache Way” 的价值。
+我们欢迎任何形式的贡献、代码、文档或建议！:smiley: 别等了，现在就加入我们吧！
+
+## 如何加入 YuniKorn 社区
+
+请通过以下渠道之一加入我们：
+
+### 通过 github 贡献
+- 这里解释了贡献项目的基本步骤 - [如何贡献](how_to_contribute)
+
+### 沟通渠道
+
+- Mailing lists:
Review comment:
邮件列表
##########
File path: i18n/zh-cn/docusaurus-plugin-content-pages/community/how_to_contribute.md
##########
@@ -0,0 +1,107 @@
+---
+id: how_to_contribute
+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 使用：
+* JIRA 用于问题跟踪。
+* GitHub 用于 Pull Requests(以后简称拉取请求)来管理代码审查和更改本身。
+* MarkDown 用于文档的源代码树。
+
+## 发现问题
+我们使用 JIRA 问题库来跟踪该项目的错误。
+找到您想要处理的问题，或者如果您发现了新问题，请提交新问题。
+有关报告问题的帮助，请查看 [如何报告问题](reporting_issues)。
+
+开始使用代码库的最简单方法是选择一个非常简单的 JIRA 问题并开始工作。
+这将帮助您熟悉代码库、构建系统、审查过程等。
+我们在 [此处](https://issues.apache.org/jira/issues/?jql=project%3DYUNIKORN%20AND%20status%3DOpen%20AND%20labels%3Dnewbie) 标记这些入门错误。
+
+如果没有人在处理现有问题，请您在只想打算尽快处理该问题时将其分配给自己。
+如果您选择现有的 JIRA，请查找链接到 JIRA ticket 的拉取请求。
+有人可能已经在处理它并且没有分配 ticket。
+具有拉取请求链接的 JIRA 将具有标签 `pull-request-available`，并且可以在问题链接下找到拉取请求的链接。
+
+对于任何不只是微不足道的更改，例如拼写错误或一行代码更改，讨论您在该问题上的预期方法是一个好主意。
Review comment:
> 讨论您在该问题上的预期方法是一个好主意
最好修改为： 在公开的渠道如slack或者邮件列表讨论您将如何解决这个问题将很有帮助。
##########
File path: i18n/zh-cn/docusaurus-plugin-content-pages/index.js
##########
@@ -0,0 +1,169 @@
+/**
+ * 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.
+*/
+
+import React from 'react';
+import clsx from 'clsx';
+import Layout from '@theme/Layout';
+import useDocusaurusContext from '@docusaurus/useDocusaurusContext';
+import styles from './styles.module.css';
+
+const features = [
+ {
+ title: <>调度能力</>,
+ imageUrl: './img/resource-scheduling.png',
+ description: (
+ <>
+ 内置全面的调度功能，包括层次队列、
+ 跨队列的资源公平性、作业排序 (FIFO/FAIR)、
+ 可插拔节点排序策略、抢占等。
+ </>
+ ),
+ },
+ {
+ title: <>K8s 资源调度器</>,
+ imageUrl: './img/support-k8s.png',
+ description: (
+ <>
+ 完全兼容 K8s，是默认 K8s 调度的替代方案，但功能更强大。
+ 对现有的 K8s 应用程序完全透明。
+ </>
+ ),
+ },
+ {
+ title: <>云原生</>,
+ imageUrl: './img/cloud-native.png',
+ description: (
+ <>
+ 支持本地和云端用例。
+ 在云上运行时，它与自动缩放共同协作，以带来最大的资源弹性和更好的吞吐量。
Review comment:
自动缩放 -> 弹性伸缩控制器
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] yangwwei commented on a change in pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
yangwwei commented on a change in pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#discussion_r786444483
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/design/gang_scheduling.md
##########
@@ -0,0 +1,608 @@
+---
+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.
+ -->
+# 帮派调度实现
+一种新的调度应用程序的方法，它考虑了应用程序随着时间的推移预计会产生的资源需求。
+它通过预留资源来保证应用程序的预期需求资源。
+
+这个实现有两个部分：
+* Kubernetes Shim
+* Core（以后成为核心）和 scheduling (调度)
+
+本文档描述了核心端的实现。
+
+## 文档目标
+本文档描述了以下实现设计要点：
+1. 定义 shim 到核心通信所需的调整（调度器接口）
+2. 调度器存储对象变化
+3. 调度器逻辑变化
+
+## 排除的设计点
+目前，本设计文档未涵盖 Kubernetes shim 端实现。
+
+本设计将 _不_ 讨论核心端的广义抢占。
+
+## 通用流程
+该流由提交的 pod 触发，该 pod 触发应用程序创建。
+在 Spark 应用程序中，第一个 Pod 是驱动程序 Pod。
+如果流程是从应用程序 CRD 的创建触发的，则不会有第一个 pod。
+然而，这超出了核心调度逻辑。从核心方面来看，这两种情况应该没有区别。
+更多细节在 [调度器逻辑更改](#scheduler-logic-changes) 章节中。
+
+提交申请的流程。图中的数字对应于图下方的描述。
+
+
+
+应用程序启动期间shim和核心的组合流程：
+* 提交的应用程序定义了任务组。 (1)
+* shim 创建应用程序并将应用程序传递给核心。 (2)
+* shim 为任务组的每个成员创建 placeholder（占位）pod。 (3)
+* 按照正常行为，pod 作为具有正确信息集的应用程序的 AllocationAsk（资源分配请求）被处理并传递给核心。 (4)
+* 占位 AllocationAsk 由核心调度，就好像它们是正常的 AllocationAsk 一样。 (5)
+* 所有分配，即使它们是由调度器分配的占位 AllocationAsks 的结果，也会被传送回 shim。
+* 原始的实际 pod 作为 AllocationAsk 传递给核心。 (6)
+* 在实际 pod 和所有占位 pod 被调度后，shim 启动触发应用程序创建实际 pod。 (7)
+
+在第一个实际 pod 启动后，以下 pod 都应该以相同的方式处理 (8)：
+* 在 k8s 上创建了一个实际 pod。
+* 处理 pod 并创建一个 AllocationAsk。
+* 调度器处理 AllocationAsk（更多细节见下文）并用实际分配替换预留资源。
+
+## 应用提交处理
+### 预留资源总大小
+
+如果请求一个或多个任务组，应用程序应该提供它要请求的所有任务组成员的总大小。
+如果应用程序在限制了资源的队列中被调度，则需要总资源大小。
+
+该值对于三种情况很重要：
+1. 帮派请求大于队列配额
+2. 开始预调度
+3. 预调度时的资源压力
+
+进一步的细节将在下面的 [在设置了配额的队列中进行调度](#scheduling-in-queues-with-a-quota-set) 中给出
+
+从 shim 传递的信息应该是 AddApplicationRequest 中的一部分。
+任务组的建立或成员数量的详细信息不相关。
+所有任务组成员请求的总资源使用以下方法计算：
+
+
+
+placeholderAsk（占位/资源预留请求）的总计信息作为可选字段添加到 AddApplicationRequest 消息中。
+可以由 shim 根据 pod 描述中提供的 CRD 或注释进行计算。
+
+如果占位请求大于队列上设置的队列配额，则必须拒绝申请。
+这种拒绝是基于我们不能以任何方式满足请求的事实。
+对于所有其他情况，会接受申请并进行正常的安排。
+
+### 使用 FAIR（公平）排序策略处理队列
+Queue sorting for the queue that the application runs in must be set to _FIFO_ or _StateAware_.
+如果将应用程序提交到设置了 FAIR 排序策略的队列，则必须拒绝该应用程序。
+应用程序运行所在队列的队列排序必须设置为 _FIFO_ 或 _StateAware_。
+
+其他队列策略不能保证一次只处理一个 _新的_ 应用程序。
+在 _公平_ 策略的情况下，我们可以同时分配多个 _新的_ 应用程序，从而无法强制实施配额管理。
+使用 _公平_ 策略的另一个副作用可能是我们得到多个应用程序但只有部分能保证分配。
+
+由于核心无法将占位情况放置在任何节点上，因此可以触发自动缩放。
+如果队列使用 _公平_ 排序，这可能会导致其他应用程序使用放大的节点而不是预留资源从而再次破坏帮派调度。
+
+## 在设置了配额的队列中进行调度
+上面已经描述的主要情况是处理大于队列上设置的配额的总占位请求大小。
+提交申请时，我们已经可以评估我们无法满足该要求并拒绝该请求。
+
+在总占位请求确实适合队列的情况下，我们不应该开始调度，直到队列中有足够的可用资源来满足总请求。
+然而，这不会停止对队列中其他应用程序的调度。
+已在队列中运行的应用程序可能会请求更多资源。
+从应用程序的角度来看，它可以请求的资源没有限制。
+应用程序上定义的联邦是有保证的资源数量，而不是应用程序可以请求的最大资源数量。
+
+我们拥有的队列层次结构是很复杂的。
+配额可能不是直接在应用程序运行的队列上设置的。
+它可以设置在某一个父队列上面。
+这种情况可能会变得复杂，我们需要保证记住我们可以实时锁定调度。
+
+在第一阶段中，我们应该关注这样一种情况，即请求的联邦资源也是应用程序将请求的最大资源数。
+当我们查看队列时，我们应该关注具有配额的单个队列级别。
+
+这两个假设对于没有使用从命名空间到队列的动态映射进行动态分配的 spark 用例是正确的。
+
+此外，我们假设队列上设置的配额可以完全分配。
+如果集群没有足够的资源，集群将扩展，直到为所有队列提供全部配额所需的大小。
+
+这也可以在某些用例中利用抢占，例如抢占应用程序超过其总的联邦大小的分配。
+在某些用例中，也可以利用抢占，比如在应用程序的总帮派规模上抢占分配。
+
+通过允许指定时间和应用程序来等待占位分配，或开始使用保留资源的时间，可以添加进一步的增强功能。
+
+## 调度器逻辑变化
+调度器逻辑的变化需要考虑周期的两个部分：
+* 占位请求及其分配。
+* 替换占位的分配。
+
+我们的基本假设是所有 pod 都会向核心生成占位 pod 请求。
+如果我们不使用应用程序 CRD，这包括触发应用程序创建的 pod。
+这个假设是必须的，才能确保调度器核心可以在提交应用程序的两种方式中以相同的方式运行。
+占位 Pod 必须在真正的 Pod 之前与核心通信。
+
+更改占位 AllocationAsks 是第一步。
+作为应用程序创建的一部分，AllocationAsks 被添加。
+添加 AllocationsAsk 通常会根据调度周期触发应用程序状态的更改。
+它将应用程序从 _New_ 状态移动到 _Accepted_ 状态。这与当前设置一致，并且不会更改。
+
+但是，在 AllocationAsk 设置了 _placeholder_ 标志的情况下，分配不应触发状态更改，应用程序保持在 _Accepted_ 状态。
+处理分配请求，直到应用程序没有 pending （挂起）的资源。
+作为安全预防措施，应忽略未设置 _placeholder_ 标志的 AllocationAsk。
+占位 Pod 的所有结果分配都按照正常步骤向 shim 确认。
+这个过程一直持续到没有更多的占位 pod 被分配。
+
+此时的 shim 应为已缓冲的真实 pod 创建分配任务。
+核心不能也不需假设每个应用程序只有一个任务组。
+如果 shim 使用了上述选项1，则核心也无法假设它已收到属于任务组的所有分配任务。
+这也是为什么我们假设每个 pod 都会向核心创建一个占位请求。
+
+第二个变化是用真正的 pod 替换了占位 pod。
+填充程序创建了一个设置了 _任务组名称_ 但未设置 _placeholder_ 标志的 AllocationAsk。
+
+这里描述的过程与通用抢占的过程一致。
+分配由核心释放，然后由 shim 确认。
+对于帮派调度，我们有一个简单的一对一释放关系，在抢占的情况下，我们可以使用具有一对多释放关系的相同流程。
+
+调度器按如下方式处理 AllocationAsk：
+1. 检查应用程序是否有未释放的分配给具有相同 _任务组名称_ 的占位分配。如果没有找到占位分配，将使用正常的分配周期来分配请求。
+2. 一个占位分配被选择并标记为释放。释放占位分配的请求被传送到 shim。这必须是一个异步过程，因为 shim 释放过程取决于底层的 K8s 响应，这可能不是即时的。
+ 注意：此时核心中没有释放任何分配。
+3. 核心“暂停”处理真正的 AllocationAsk，直到 shim 响应确认已释放占位分配。
+ 注意：释放锁以允许调度继续
+4. 在收到来自 shim 的释放确认后，“暂停的” AllocationAsk 处理会结束。
+5. AllocationAsk 分配在与使用的占位相同的节点上。
+ 在任何一种情况下，占位分配的删除都将完成。这一切都需要作为对应用程序、队列和节点的一次更新来实现。
+ * 成功时：创建一个新的分配。
+ * 失败时：尝试在不同的节点上分配，如果失败，AllocationAsk 变得不可调度，并触发扩展。
+6. 将分配传达回shim（如果适用，基于步骤 5）
+
+## 应用程序完成
+应用程序完成一直是一个长期存在的问题。
+目前，应用程序在完成时不会转换到 _completed_ 状态。
+应用程序的当前状态是 [参考文档](./scheduler_object_states.md)。
+但是，此时应用程序将不会达到 _completed_ 状态，而是停留在 _waiting_ 状态。
+
+这提供了许多问题，特别是在长时间运行部署中的内存使用和队列清理的情况下。
+
+### 定义
+由于我们不能依赖在 Kubernetes 上作为 Pod 运行的应用程序来表明它已经完成，因此我们需要定义何时考虑一个应用程序的 _完成_ 。
+在这一点上，我们定义了一个应用程序在定义的时间段内处于 _等待_ 状态时，它会变成 _完成_ 。
+当没有活动分配（已分配资源 > 0）和挂起分配请求（挂起资源 > 0）时，应用程序进入等待状态。
+
+向 _waiting_ 状态的转换已经实现。
+_waiting_ 状态的超时是一项新的功能。
+
+资源预留不被视为活动分配。
+占位请求被视为待处理的资源请求。
+这些情况将在下面的 [清理](#Cleanup) 中处理。
+
+### 清理
+当我们查看帮派调度时，还有一个关于未使用的预留资源、占位请求及其清理的问题。
+预留资源可以在有待处理分配请求或活动分配的任何时候转换为实际分配。
+
+在处理实际分配之前，占位请求将全部转换为占位分配。
+
+进入 _waiting_ 状态已被处理。
+如果将新的分配请求添加到应用程序中，它将转换回 _running_ 状态。
+当我们进入了等待状态，将没有待处理的请求或分配的资源。
+只有可以分配的预留资源。
+
+为了进入 _waiting_ 状态，应用程序必须是干净的。
+但是，我们不能保证在应用程序运行期间应用程序将使用所有预留资源。
+从 _waiting_ 状态转换到 _completed_ 状态根本不需要（占位）分配或请求。
+影响转换的第二种情况是并非所有占位请求都被分配，因此应用程序从不请求任何真正的分配。
+这两种情况可能会阻止应用程序转换出 _accepted_ 或 _waiting_ 状态。
+
+因此，核心中的处理需要考虑两种会影响特定状态的转换的情况：
+1. 占位请求挂起（退出 _accepted_ ）
+2. 占位分配（退出 _waiting_ ）
+
+占位请求挂起：
+挂起的占位符是通过超时来处理的。
+应用程序只能花费有限的时间等待分配所有预留资源。
+这个超时是必需的，因为应用程序的部分占位分配可能会占用集群资源而没有真正使用它们。
+
+应用程序可能排队等待未知时间，等待占位分配开始。
+因此，占位请求的超时不能与应用程序或请求的创建相关联。
+超时必须在分配第一个占位请求时开始。
+
+在所有占位请求都被分配之前，应用程序不能请求真正的分配。
+占位请求也由 shim 跟踪，因为它代表一个 pod。
+在核心中释放请求需要消息在核心和 shim 之间流动以释放该请求。
+但是，在这种情况下，分配预留资源的超时会触发应用程序失败。
+当超时被触发并且占位请求挂起时，应用程序将从它所处的状态转换为 _killed_ 。
+
+本案例的应用状态可以概括为：
+* 申请状态为 _accepted_
+* 占位分配的资源大于零，并且小于 _AddApplicationRequest_ 中的 _placeholderAsk_
+* 待处理资源请求大于零
+
+进入 _killed_ 状态必须自动将应用程序移出队列。
+
+状态更改和占位分配释放可以在单个更新响应消息中处理。 该消息将包含以下内容：
+* _UpdatedApplication_ 用于应用程序的状态变化
+* 一个或多个 _AllocationRelease_ 消息，每个占位一个，_TerminationType_ 设置为 TIMEOUT
+* 一条或多条 _TerminationType_ 设置为 TIMEOUT 的 AllocationAskRelease 消息
+
+shim 首先处理 AllocationAskRelease 消息，然后是 _AllocationResponse_ 消息，最后是 _UpdatedApplication_ 消息。应用程序状态在核心端更改为 _killed_ 状态仅取决于移除所有占位 pod，而不取决于对 _UpdatedApplication_ 消息的响应。
+
+
+
+占位超时期间 shim 和核心的组合流程：
+* 核心超时占位分配。 (1)
+* 删除占位分配被传递到 shim。 (2)
+* 所有占位分配都由 shim 释放，并传回核心。
+* 删除占位分配请求被传递给 shim。 (3)
+* 所有占位分配请求都由 shim 释放，并传回核心。
+* 在占位分配和请求被释放后，核心将应用程序移动到终止状态，将其从队列中移除 (4)。
+* 状态更改在核心和 shim 中完成。 (5)
+
+
+已分配的占位：
+剩余的占位需要由核心释放。
+需要通知 shim 将它们移除。这必须在进入 _完成_ 状态时触发。
+在核心请求释放占位之后，应用程序的状态转换可以继续。
+核心将处理从 shim 返回的占位分配的 _AllocationRelease_ 消息，并将 _TerminationType_ 设置为正常*超时*，而不会触发状态更改。
+
+状态更改和占位分配释放可以在单个更新响应消息中处理。
+该消息将包含以下内容：
+* _UpdatedApplication_ 用于应用程序的状态变化
+* 零个或多个 _AllocationRelease_ 消息，每个占位一个，_TerminationType_ 设置为 *超时*
+
+shim 首先处理 _AllocationResponse_ 消息，然后是 _UpdatedApplication_ 消息。
+应用程序状态在核心端更改为 _完成_ 状态仅依赖于所有占位 pod 的移除，而不依赖于对 _UpdatedApplication_ 消息的响应。
+
+进入 _完成_ 状态会自动将应用程序移出队列。
+这也应该处理我们之前讨论的可能延迟处理来自 shim 的请求的情况，因为我们可以在需要时从 _等待_ 移回 _执行中_ 。
+一个 _完成_ 的应用程序也不应该阻止围绕cron讨论的情况，例如每次调用使用相同的应用程序ID提交。
+具有相同申请ID的 _完成_ 申请不得阻止提交具有相同ID的新申请。
+
+
+cation to the completed state removing it from the queue (6).
+* The state change is finalised in the core and shim. (7)
+在清理应用程序期间 shim 和核心的组合流程：
+* 在 Kubernetes 层发布了一个 pod。 (1)
+* shim 将分配释放传递给核心。 (2)
+* 如果没有挂起或活动的分配，核心会将应用程序转换为等待状态。 (3)
+* 等待状态超时并触发清理。 (4)
+* 删除占位符配被传递到 shim。 (5)
+* 所有占位分配都由 shim 释放，并传回核心。
+* 释放所有占位后，核心将应用程序移动到完成状态，将其从队列中删除 (6)。
+* 状态更改在核心和 shim 中完成。 (7)
+
+## 应用恢复
+在应用程序恢复期间，占位 Pod 与节点上的任何其他 Pod 一样被恢复。
+这些 pod 由 shim 作为节点现有分配的一部分传递到核心。
+现有的分配在核心中没有相应的 _分配请求_。 核心根据恢复的信息生成 _分配请求_ 。
+
+对于联邦调度，_分配请求_ 包含 _任务组名称_ 和 _占位_ 标志。
+在恢复期间，相同的信息必须是 _分配_ 消息的一部分。
+这是因为在两个方向上使用相同的消息，从 RM 到调度器，反之亦然，这意味着我们需要更新消息及其处理。
+
+如果 _分配_ 消息中缺少信息，则恢复的分配将不会在核心中被正确标记。
+恢复的分配将被视为常规分配。
+这意味着它作为替换占位的正常分配周期的一部分被跳过。
+
+逻辑变化只需要现有分配的恢复将接口消息中的字段复制到内核中的分配对象中。
+
+## 接口变化
+需要对 shim 和核心之间的通信进行多次更改，以支持所需的帮派信息。
+
+应用程序必须提供占位请求的总大小，以防止接受永远无法运行的应用程序。
+
+从 shim 发送到核心以进行分配请求的当前对象在 AllocationAsk 中定义。
+由于从调度器核心传回的结果消息不会更改，因此分配不会更改。。但是，对于使用相同分配消息从 shim 到核心的恢复，必须包含与帮派相关的字段。
+必须将与帮派相关的字段添加到这两个消息中。
+
+分配释放请求和响应请求需要支持双向通信，并且需要进行重大更改。
+
Review comment:
hi @cdmikechen thank you so much for initiating the effort!! and thanks for @yuchaoran2011 's help to review.
I do not think we need to wait for everything ready before committing patches, we can change YUNIKORN-1029 to an umbrella and do this incrementally. Actually, I am gonna propose in the next community, we should do a split for the reviewers for people who can help to review.
for your questions
> 第一个是我在翻译 gang scheduling 的时候遇到了一些困难
Understood, that's why we need to work together more closely : )
> 第二个是我原来的翻译顺序是按照我自己文档目录树的顺序翻译的，但是考虑到读者的阅读顺序，从website开始按照官网的顺序进行翻译可能更加好。所以我将当时翻译一半的内容先停了下来。
I think we should focus on the user-facing doc first. such as quick start, download, roadmap, community, user guide etc. for developer-facing docs, that can come later, such as design docs.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] cdmikechen commented on a change in pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
cdmikechen commented on a change in pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#discussion_r786705591
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/get_started/core_features.md
##########
@@ -0,0 +1,72 @@
+---
+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 提供了一个集中的视图来监视资源队列的使用情况，它可以帮助您了解不同租户是如何使用资源的。
+此外，通过利用最小/最大队列容量，它可以定义每个租户的弹性资源消耗。
+
+## 作业排序和排队
+
+应用可以在工作队列中正确排队，排序策略决定哪个应用程序可以首先获得资源。
+这个策略可以是多种多样的，例如简单的 `FIFO`、`Fair`、`StateAware`或基于`Priority`的策略。
+队列可以维持应用的顺序，调度器根据不同的策略为作业分配相应的资源。这种行为更容易被理解和控制。
Review comment:
@yangwwei
Queues can maintain the order of applications, and based on different policies, the scheduler allocates resources to jobs accordingly. The behavior is much more predictable.
这个是最后一句的原文，请问下是不是指定错了行？
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] cdmikechen edited a comment on pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
cdmikechen edited a comment on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1015282559
@yangwwei
Thank you for your review~ I will change it later. Let me answer these questions first.
> 1. Are we planning to translate the home page as well?
Yes, `docusaurus-plugin-content-pages` is yunikorn home website pages and the preliminary translation has been completed.
> 2\. I noticed that all the files are under `docusaurus-plugin-content-docs/version-0.12.1/`, is this only done for the v0.12.1 doc? I think we need to get the master doc done first. Note, our source docs are under https://github.com/apache/incubator-yunikorn-site/tree/master/docs, and version docs are all generated. I am not familiar with how docusaurus support different languages, but we need to make sure the CN docs are also generated from the master doc.
I added these files completely according to [docusaurus official 2.0 document](https://docusaurus.io/zh-CN/docs/i18n/introduction).
And I will move these documents to current, which is the master version in the official website.
> 3\. Have you tested this locally and how it looks like? If you haven't done this, you can see how to do this locally in this here: https://github.com/apache/incubator-yunikorn-site#make-changes.
I have deployed and verified locally. In the next time, when the translation is relatively perfect, I can provide a docker image or build a private service to preview the new page.
Here is my sreenshot:
> 1. We need to use consistent terminology in the doc, such as gang scheduling, placement rules, resource quota, leaf queue, and so on. Once all review feedback is received, please don't forget to do a double-check on these terminology words.
In addition to these listed words, I'll try to sort out a proper noun document this week. I will send it to slack `#dev` channel. So that you or other PPMC can review and see which words can be translated and which need to keep the original.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] chenya-zhang commented on a change in pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
chenya-zhang commented on a change in pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#discussion_r787239104
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/design/gang_scheduling.md
##########
@@ -0,0 +1,608 @@
+---
+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.
+ -->
+# 帮派调度实现
+一种新的调度应用程序的方法，它考虑了应用程序随着时间的推移预计会产生的资源需求。
+它通过预留资源来保证应用程序的预期需求资源。
+
+这个实现有两个部分：
+* Kubernetes Shim
+* Core（以后成为核心）和 scheduling (调度)
+
+本文档描述了核心端的实现。
+
+## 文档目标
+本文档描述了以下实现设计要点：
+1. 定义 shim 到核心通信所需的调整（调度器接口）
+2. 调度器存储对象变化
+3. 调度器逻辑变化
+
+## 排除的设计点
+目前，本设计文档未涵盖 Kubernetes shim 端实现。
+
+本设计将 _不_ 讨论核心端的广义抢占。
+
+## 通用流程
+该流由提交的 pod 触发，该 pod 触发应用程序创建。
+在 Spark 应用程序中，第一个 Pod 是驱动程序 Pod。
+如果流程是从应用程序 CRD 的创建触发的，则不会有第一个 pod。
+然而，这超出了核心调度逻辑。从核心方面来看，这两种情况应该没有区别。
+更多细节在 [调度器逻辑更改](#scheduler-logic-changes) 章节中。
+
+提交申请的流程。图中的数字对应于图下方的描述。
+
+
+
+应用程序启动期间shim和核心的组合流程：
+* 提交的应用程序定义了任务组。 (1)
+* shim 创建应用程序并将应用程序传递给核心。 (2)
+* shim 为任务组的每个成员创建 placeholder（占位）pod。 (3)
+* 按照正常行为，pod 作为具有正确信息集的应用程序的 AllocationAsk（资源分配请求）被处理并传递给核心。 (4)
+* 占位 AllocationAsk 由核心调度，就好像它们是正常的 AllocationAsk 一样。 (5)
+* 所有分配，即使它们是由调度器分配的占位 AllocationAsks 的结果，也会被传送回 shim。
+* 原始的实际 pod 作为 AllocationAsk 传递给核心。 (6)
+* 在实际 pod 和所有占位 pod 被调度后，shim 启动触发应用程序创建实际 pod。 (7)
+
+在第一个实际 pod 启动后，以下 pod 都应该以相同的方式处理 (8)：
+* 在 k8s 上创建了一个实际 pod。
+* 处理 pod 并创建一个 AllocationAsk。
+* 调度器处理 AllocationAsk（更多细节见下文）并用实际分配替换预留资源。
+
+## 应用提交处理
+### 预留资源总大小
+
+如果请求一个或多个任务组，应用程序应该提供它要请求的所有任务组成员的总大小。
+如果应用程序在限制了资源的队列中被调度，则需要总资源大小。
+
+该值对于三种情况很重要：
+1. 帮派请求大于队列配额
+2. 开始预调度
+3. 预调度时的资源压力
+
+进一步的细节将在下面的 [在设置了配额的队列中进行调度](#scheduling-in-queues-with-a-quota-set) 中给出
+
+从 shim 传递的信息应该是 AddApplicationRequest 中的一部分。
+任务组的建立或成员数量的详细信息不相关。
+所有任务组成员请求的总资源使用以下方法计算：
+
+
+
+placeholderAsk（占位/资源预留请求）的总计信息作为可选字段添加到 AddApplicationRequest 消息中。
+可以由 shim 根据 pod 描述中提供的 CRD 或注释进行计算。
+
+如果占位请求大于队列上设置的队列配额，则必须拒绝申请。
+这种拒绝是基于我们不能以任何方式满足请求的事实。
+对于所有其他情况，会接受申请并进行正常的安排。
+
+### 使用 FAIR（公平）排序策略处理队列
+Queue sorting for the queue that the application runs in must be set to _FIFO_ or _StateAware_.
+如果将应用程序提交到设置了 FAIR 排序策略的队列，则必须拒绝该应用程序。
+应用程序运行所在队列的队列排序必须设置为 _FIFO_ 或 _StateAware_。
+
+其他队列策略不能保证一次只处理一个 _新的_ 应用程序。
+在 _公平_ 策略的情况下，我们可以同时分配多个 _新的_ 应用程序，从而无法强制实施配额管理。
+使用 _公平_ 策略的另一个副作用可能是我们得到多个应用程序但只有部分能保证分配。
+
+由于核心无法将占位情况放置在任何节点上，因此可以触发自动缩放。
+如果队列使用 _公平_ 排序，这可能会导致其他应用程序使用放大的节点而不是预留资源从而再次破坏帮派调度。
+
+## 在设置了配额的队列中进行调度
+上面已经描述的主要情况是处理大于队列上设置的配额的总占位请求大小。
+提交申请时，我们已经可以评估我们无法满足该要求并拒绝该请求。
+
+在总占位请求确实适合队列的情况下，我们不应该开始调度，直到队列中有足够的可用资源来满足总请求。
+然而，这不会停止对队列中其他应用程序的调度。
+已在队列中运行的应用程序可能会请求更多资源。
+从应用程序的角度来看，它可以请求的资源没有限制。
+应用程序上定义的联邦是有保证的资源数量，而不是应用程序可以请求的最大资源数量。
+
+我们拥有的队列层次结构是很复杂的。
+配额可能不是直接在应用程序运行的队列上设置的。
+它可以设置在某一个父队列上面。
+这种情况可能会变得复杂，我们需要保证记住我们可以实时锁定调度。
+
+在第一阶段中，我们应该关注这样一种情况，即请求的联邦资源也是应用程序将请求的最大资源数。
+当我们查看队列时，我们应该关注具有配额的单个队列级别。
+
+这两个假设对于没有使用从命名空间到队列的动态映射进行动态分配的 spark 用例是正确的。
+
+此外，我们假设队列上设置的配额可以完全分配。
+如果集群没有足够的资源，集群将扩展，直到为所有队列提供全部配额所需的大小。
+
+这也可以在某些用例中利用抢占，例如抢占应用程序超过其总的联邦大小的分配。
+在某些用例中，也可以利用抢占，比如在应用程序的总帮派规模上抢占分配。
+
+通过允许指定时间和应用程序来等待占位分配，或开始使用保留资源的时间，可以添加进一步的增强功能。
+
+## 调度器逻辑变化
+调度器逻辑的变化需要考虑周期的两个部分：
+* 占位请求及其分配。
+* 替换占位的分配。
+
+我们的基本假设是所有 pod 都会向核心生成占位 pod 请求。
+如果我们不使用应用程序 CRD，这包括触发应用程序创建的 pod。
+这个假设是必须的，才能确保调度器核心可以在提交应用程序的两种方式中以相同的方式运行。
+占位 Pod 必须在真正的 Pod 之前与核心通信。
+
+更改占位 AllocationAsks 是第一步。
+作为应用程序创建的一部分，AllocationAsks 被添加。
+添加 AllocationsAsk 通常会根据调度周期触发应用程序状态的更改。
+它将应用程序从 _New_ 状态移动到 _Accepted_ 状态。这与当前设置一致，并且不会更改。
+
+但是，在 AllocationAsk 设置了 _placeholder_ 标志的情况下，分配不应触发状态更改，应用程序保持在 _Accepted_ 状态。
+处理分配请求，直到应用程序没有 pending （挂起）的资源。
+作为安全预防措施，应忽略未设置 _placeholder_ 标志的 AllocationAsk。
+占位 Pod 的所有结果分配都按照正常步骤向 shim 确认。
+这个过程一直持续到没有更多的占位 pod 被分配。
+
+此时的 shim 应为已缓冲的真实 pod 创建分配任务。
+核心不能也不需假设每个应用程序只有一个任务组。
+如果 shim 使用了上述选项1，则核心也无法假设它已收到属于任务组的所有分配任务。
+这也是为什么我们假设每个 pod 都会向核心创建一个占位请求。
+
+第二个变化是用真正的 pod 替换了占位 pod。
+填充程序创建了一个设置了 _任务组名称_ 但未设置 _placeholder_ 标志的 AllocationAsk。
+
+这里描述的过程与通用抢占的过程一致。
+分配由核心释放，然后由 shim 确认。
+对于帮派调度，我们有一个简单的一对一释放关系，在抢占的情况下，我们可以使用具有一对多释放关系的相同流程。
+
+调度器按如下方式处理 AllocationAsk：
+1. 检查应用程序是否有未释放的分配给具有相同 _任务组名称_ 的占位分配。如果没有找到占位分配，将使用正常的分配周期来分配请求。
+2. 一个占位分配被选择并标记为释放。释放占位分配的请求被传送到 shim。这必须是一个异步过程，因为 shim 释放过程取决于底层的 K8s 响应，这可能不是即时的。
+ 注意：此时核心中没有释放任何分配。
+3. 核心“暂停”处理真正的 AllocationAsk，直到 shim 响应确认已释放占位分配。
+ 注意：释放锁以允许调度继续
+4. 在收到来自 shim 的释放确认后，“暂停的” AllocationAsk 处理会结束。
+5. AllocationAsk 分配在与使用的占位相同的节点上。
+ 在任何一种情况下，占位分配的删除都将完成。这一切都需要作为对应用程序、队列和节点的一次更新来实现。
+ * 成功时：创建一个新的分配。
+ * 失败时：尝试在不同的节点上分配，如果失败，AllocationAsk 变得不可调度，并触发扩展。
+6. 将分配传达回shim（如果适用，基于步骤 5）
+
+## 应用程序完成
+应用程序完成一直是一个长期存在的问题。
+目前，应用程序在完成时不会转换到 _completed_ 状态。
+应用程序的当前状态是 [参考文档](./scheduler_object_states.md)。
+但是，此时应用程序将不会达到 _completed_ 状态，而是停留在 _waiting_ 状态。
+
+这提供了许多问题，特别是在长时间运行部署中的内存使用和队列清理的情况下。
+
+### 定义
+由于我们不能依赖在 Kubernetes 上作为 Pod 运行的应用程序来表明它已经完成，因此我们需要定义何时考虑一个应用程序的 _完成_ 。
+在这一点上，我们定义了一个应用程序在定义的时间段内处于 _等待_ 状态时，它会变成 _完成_ 。
+当没有活动分配（已分配资源 > 0）和挂起分配请求（挂起资源 > 0）时，应用程序进入等待状态。
+
+向 _waiting_ 状态的转换已经实现。
+_waiting_ 状态的超时是一项新的功能。
+
+资源预留不被视为活动分配。
+占位请求被视为待处理的资源请求。
+这些情况将在下面的 [清理](#Cleanup) 中处理。
+
+### 清理
+当我们查看帮派调度时，还有一个关于未使用的预留资源、占位请求及其清理的问题。
+预留资源可以在有待处理分配请求或活动分配的任何时候转换为实际分配。
+
+在处理实际分配之前，占位请求将全部转换为占位分配。
+
+进入 _waiting_ 状态已被处理。
+如果将新的分配请求添加到应用程序中，它将转换回 _running_ 状态。
+当我们进入了等待状态，将没有待处理的请求或分配的资源。
+只有可以分配的预留资源。
+
+为了进入 _waiting_ 状态，应用程序必须是干净的。
+但是，我们不能保证在应用程序运行期间应用程序将使用所有预留资源。
+从 _waiting_ 状态转换到 _completed_ 状态根本不需要（占位）分配或请求。
+影响转换的第二种情况是并非所有占位请求都被分配，因此应用程序从不请求任何真正的分配。
+这两种情况可能会阻止应用程序转换出 _accepted_ 或 _waiting_ 状态。
+
+因此，核心中的处理需要考虑两种会影响特定状态的转换的情况：
+1. 占位请求挂起（退出 _accepted_ ）
+2. 占位分配（退出 _waiting_ ）
+
+占位请求挂起：
+挂起的占位符是通过超时来处理的。
+应用程序只能花费有限的时间等待分配所有预留资源。
+这个超时是必需的，因为应用程序的部分占位分配可能会占用集群资源而没有真正使用它们。
+
+应用程序可能排队等待未知时间，等待占位分配开始。
+因此，占位请求的超时不能与应用程序或请求的创建相关联。
+超时必须在分配第一个占位请求时开始。
+
+在所有占位请求都被分配之前，应用程序不能请求真正的分配。
+占位请求也由 shim 跟踪，因为它代表一个 pod。
+在核心中释放请求需要消息在核心和 shim 之间流动以释放该请求。
+但是，在这种情况下，分配预留资源的超时会触发应用程序失败。
+当超时被触发并且占位请求挂起时，应用程序将从它所处的状态转换为 _killed_ 。
+
+本案例的应用状态可以概括为：
+* 申请状态为 _accepted_
+* 占位分配的资源大于零，并且小于 _AddApplicationRequest_ 中的 _placeholderAsk_
+* 待处理资源请求大于零
+
+进入 _killed_ 状态必须自动将应用程序移出队列。
+
+状态更改和占位分配释放可以在单个更新响应消息中处理。 该消息将包含以下内容：
+* _UpdatedApplication_ 用于应用程序的状态变化
+* 一个或多个 _AllocationRelease_ 消息，每个占位一个，_TerminationType_ 设置为 TIMEOUT
+* 一条或多条 _TerminationType_ 设置为 TIMEOUT 的 AllocationAskRelease 消息
+
+shim 首先处理 AllocationAskRelease 消息，然后是 _AllocationResponse_ 消息，最后是 _UpdatedApplication_ 消息。应用程序状态在核心端更改为 _killed_ 状态仅取决于移除所有占位 pod，而不取决于对 _UpdatedApplication_ 消息的响应。
+
+
+
+占位超时期间 shim 和核心的组合流程：
+* 核心超时占位分配。 (1)
+* 删除占位分配被传递到 shim。 (2)
+* 所有占位分配都由 shim 释放，并传回核心。
+* 删除占位分配请求被传递给 shim。 (3)
+* 所有占位分配请求都由 shim 释放，并传回核心。
+* 在占位分配和请求被释放后，核心将应用程序移动到终止状态，将其从队列中移除 (4)。
+* 状态更改在核心和 shim 中完成。 (5)
+
+
+已分配的占位：
+剩余的占位需要由核心释放。
+需要通知 shim 将它们移除。这必须在进入 _完成_ 状态时触发。
+在核心请求释放占位之后，应用程序的状态转换可以继续。
+核心将处理从 shim 返回的占位分配的 _AllocationRelease_ 消息，并将 _TerminationType_ 设置为正常*超时*，而不会触发状态更改。
+
+状态更改和占位分配释放可以在单个更新响应消息中处理。
+该消息将包含以下内容：
+* _UpdatedApplication_ 用于应用程序的状态变化
+* 零个或多个 _AllocationRelease_ 消息，每个占位一个，_TerminationType_ 设置为 *超时*
+
+shim 首先处理 _AllocationResponse_ 消息，然后是 _UpdatedApplication_ 消息。
+应用程序状态在核心端更改为 _完成_ 状态仅依赖于所有占位 pod 的移除，而不依赖于对 _UpdatedApplication_ 消息的响应。
+
+进入 _完成_ 状态会自动将应用程序移出队列。
+这也应该处理我们之前讨论的可能延迟处理来自 shim 的请求的情况，因为我们可以在需要时从 _等待_ 移回 _执行中_ 。
+一个 _完成_ 的应用程序也不应该阻止围绕cron讨论的情况，例如每次调用使用相同的应用程序ID提交。
+具有相同申请ID的 _完成_ 申请不得阻止提交具有相同ID的新申请。
+
+
+cation to the completed state removing it from the queue (6).
+* The state change is finalised in the core and shim. (7)
+在清理应用程序期间 shim 和核心的组合流程：
+* 在 Kubernetes 层发布了一个 pod。 (1)
+* shim 将分配释放传递给核心。 (2)
+* 如果没有挂起或活动的分配，核心会将应用程序转换为等待状态。 (3)
+* 等待状态超时并触发清理。 (4)
+* 删除占位符配被传递到 shim。 (5)
+* 所有占位分配都由 shim 释放，并传回核心。
+* 释放所有占位后，核心将应用程序移动到完成状态，将其从队列中删除 (6)。
+* 状态更改在核心和 shim 中完成。 (7)
+
+## 应用恢复
+在应用程序恢复期间，占位 Pod 与节点上的任何其他 Pod 一样被恢复。
+这些 pod 由 shim 作为节点现有分配的一部分传递到核心。
+现有的分配在核心中没有相应的 _分配请求_。 核心根据恢复的信息生成 _分配请求_ 。
+
+对于联邦调度，_分配请求_ 包含 _任务组名称_ 和 _占位_ 标志。
+在恢复期间，相同的信息必须是 _分配_ 消息的一部分。
+这是因为在两个方向上使用相同的消息，从 RM 到调度器，反之亦然，这意味着我们需要更新消息及其处理。
+
+如果 _分配_ 消息中缺少信息，则恢复的分配将不会在核心中被正确标记。
+恢复的分配将被视为常规分配。
+这意味着它作为替换占位的正常分配周期的一部分被跳过。
+
+逻辑变化只需要现有分配的恢复将接口消息中的字段复制到内核中的分配对象中。
+
+## 接口变化
+需要对 shim 和核心之间的通信进行多次更改，以支持所需的帮派信息。
+
+应用程序必须提供占位请求的总大小，以防止接受永远无法运行的应用程序。
+
+从 shim 发送到核心以进行分配请求的当前对象在 AllocationAsk 中定义。
+由于从调度器核心传回的结果消息不会更改，因此分配不会更改。。但是，对于使用相同分配消息从 shim 到核心的恢复，必须包含与帮派相关的字段。
+必须将与帮派相关的字段添加到这两个消息中。
+
+分配释放请求和响应请求需要支持双向通信，并且需要进行重大更改。
+
Review comment:
Thanks @cdmikechen for this great contribution!
+1 if we could split this PR into smaller ones. It will be much easier for more reviewers to help on the review process. :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] yuchaoran2011 commented on pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
yuchaoran2011 commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1014156530
I'm leaning towards the first option. It will be confusing for users looking for Chinese documentation to run into large paragraphs of English. Let's also hear thoughts from @yangwwei @chenya-zhang @HuangTing-Yao @0yukali0
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] 0yukali0 commented on a change in pull request #108: [YUNIKORN-1031] Add Chinese translation for homepage
Posted by GitBox <gi...@apache.org>.
0yukali0 commented on a change in pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#discussion_r793618019
##########
File path: i18n/zh-cn/docusaurus-plugin-content-pages/community/reporting_issues.md
##########
@@ -0,0 +1,92 @@
+---
+id: reporting_issues
+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 网页](https://yunikorn.apache.org)。
+您也可以向 YuniKorn slack 频道寻求帮助，查看网页了解如何加入的详细信息。
Review comment:
我想可以将此段前后调换一下并加些细节
您也可以向 YuniKorn slack 频道寻求帮助，查看网页了解如何加入的详细信息。 (原先)
您也可以透过查看Yunikorn的进行参与网页，了解如何加入YuniKorn slack的详细讯息并寻求帮助。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] cdmikechen commented on a change in pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
cdmikechen commented on a change in pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#discussion_r786714770
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/get_started/core_features.md
##########
@@ -0,0 +1,72 @@
+---
+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 提供了一个集中的视图来监视资源队列的使用情况，它可以帮助您了解不同租户是如何使用资源的。
+此外，通过利用最小/最大队列容量，它可以定义每个租户的弹性资源消耗。
+
+## 作业排序和排队
+
+应用可以在工作队列中正确排队，排序策略决定哪个应用程序可以首先获得资源。
+这个策略可以是多种多样的，例如简单的 `FIFO`、`Fair`、`StateAware`或基于`Priority`的策略。
+队列可以维持应用的顺序，调度器根据不同的策略为作业分配相应的资源。这种行为更容易被理解和控制。
+
+此外，当配置队列最大容量时，作业和任务可以在资源队列中正确排队。
+如果剩余的容量不够，它们可以排队等待，直到释放一些资源。这简化了客户端操作。
+与默认调度程序不同，资源由命名空间资源配额限制，这是由配额许可控制器强制执行的。
+如果下面的命名空间没有足够的配额，Pod就不能被创建。
+客户端需要复杂的逻辑来处理此类场景，例如按条件重试。
+
+## 资源公平性
+
+在多租户环境中，许多用户共享集群资源。
+为了避免租户争夺资源或者可能的资源不足，需要做到更细粒度的公平性需求，以此来实现跨用户以及跨团队/组织的公平性。
+考虑到权重或优先级，一些更重要的应用可以获得超过其配额的更多的需求资源。
+这往往与资源预算有关，更细粒度的公平模式可以进一步提高资源控制。
+
+## 资源预留
+
+YuniKorn会自动为未完成的请求进行资源预订。
+如果Pod无法分配，YuniKorn将尝试在一个满足条件的节点上保留它，并在这个保留节点上暂时分配pod（在尝试其他节点之前）。
+这种机制可以避免这个Pod被后来提交的更小、更不挑剔的豆荚所挤占。
+此功能在批处理工作负载场景中非常重要，因为当对集群提交大量异构Pod时，很有可能一些Pod会被抛弃，即使它们提交得更早。
Review comment:
@yangwwei
If a pod could not be allocated, YuniKorn will try to reserve it on a qualified node and tentatively allocate the pod on this reserved node (before trying rest of nodes).
这个是第一句，我想请问下这句扩充了很多信息，是否需要回馈到原文进行修改？
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] cdmikechen commented on pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
cdmikechen commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1014153186
> Thanks for initiating this great effort. A lot of work has gone into this PR. I haven't gone through everything but pointed out some typos and nits to be addressed for now
@yuchaoran2011
谢谢您的指导，您提出的一些意见我已经进行了更正，我在这里先以中文方式回复您。
由于我对yunikorn项目也暂时只在了解阶段，所以当前的文档中的确是会有很多的疏漏和不足。有一些词汇和语句我还是很不理解，所以会出现部分机翻的痕迹（一部分是有些部分的章节比较简单，我就直接使用翻译软件进行了翻译，然后简单校对一下；一部分是的确是我自己不理解一些语句，利用翻译软件翻译后再自己稍微润色一下尽量保证文档的连贯性和一定的可读性）。
目前的PR可能更接近粗翻，没有经过太精细的校对。如果您有时间，我想我可以先把一些我的疑问整理一下再请教您。
现在有2个方向：接下来先完成其他部分章节，然后再进行细翻；或者先保证当前文档的质量，再进行接下来的部分。您觉得哪个方向更好一点？
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] cdmikechen edited a comment on pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
cdmikechen edited a comment on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1014153186
> Thanks for initiating this great effort. A lot of work has gone into this PR. I haven't gone through everything but pointed out some typos and nits to be addressed for now
@yuchaoran2011
谢谢您的指导，您提出的一些意见我已经进行了更正，我在这里先以中文方式回复您。
由于我对yunikorn项目也暂时只在了解阶段，所以当前的文档中的确是会有很多的疏漏和不足。有一些词汇和语句我还是很不理解，所以会出现部分机翻的痕迹（一部分是有些部分的章节比较简单，我就直接使用翻译软件进行了翻译，然后简单校对一下；一部分是的确是我自己不理解一些语句，利用翻译软件翻译后再自己稍微润色一下尽量保证文档的连贯性和一定的可读性）。
目前的PR可能更接近粗翻，没有经过太精细的校对。如果您有时间，我想我可以先把一些我的疑问整理一下再请教您。
现在有2个方向：接下来先完成其他部分章节，然后再进行细翻；或者先保证当前文档的质量，再进行接下来的部分。您觉得哪个方向更好一点？
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] yuchaoran2011 commented on a change in pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
yuchaoran2011 commented on a change in pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#discussion_r785616408
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/api/cluster.md
##########
@@ -0,0 +1,128 @@
+---
+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调度程序管理的群集常规信息，信息内容包括应用程序和容器的数量（包括总计、失败、挂起、正在运行和已完成的数量）。
Review comment:
```suggestion
返回由YuniKorn调度程序管理的集群常规信息。信息内容包括应用程序和容器的数量（包括总计、失败、挂起、正在运行和已完成的数量）。
```
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/api/cluster.md
##########
@@ -0,0 +1,128 @@
+---
+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`
+
+**方法** : `GET`
+
+**是否需要认证** : NO
+
+### 成功返回
+
+**返回代码** : `200 OK`
+
+**样例内容**
+
+例如，下面是一个2节点集群的响应，其中包含3个应用程序和4个正在运行的容器。
+
+```json
+[
+ {
+ "partition": "[rm-123]default",
+ "clusterName": "kubernetes",
+ "totalApplications": "3",
+ "failedApplications": "1",
+ "pendingApplications": "",
+ "runningApplications": "3",
+ "completedApplications": "",
+ "totalContainers": "4",
+ "failedContainers": "",
+ "pendingContainers": "",
+ "runningContainers": "4",
+ "activeNodes": "2",
+ "totalNodes": "2",
+ "failedNodes": ""
+ }
+]
+```
+
+### 错误返回
+
+**返回代码** : `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: .."
+}
+```
+
+## 集群利用率
+
+返回与群集资源利用率相关的统计数据
Review comment:
```suggestion
返回与集群资源利用率相关的统计数据
```
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/design/gang_scheduling.md
##########
@@ -0,0 +1,608 @@
+---
+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.
+ -->
+# 帮派调度实现
+一种新的调度应用程序的方法，它考虑了应用程序随着时间的推移预计会产生的资源需求。
+它通过预留资源来保证应用程序的预期需求资源。
+
+这个实现有两个部分：
+* Kubernetes Shim
+* Core（以后成为核心）和 scheduling (调度)
+
+本文档描述了核心端的实现。
+
+## 文档目标
+本文档描述了以下实现设计要点：
+1. 定义 shim 到核心通信所需的调整（调度器接口）
+2. 调度器存储对象变化
+3. 调度器逻辑变化
+
+## 排除的设计点
+目前，本设计文档未涵盖 Kubernetes shim 端实现。
+
+本设计将 _不_ 讨论核心端的广义抢占。
+
+## 通用流程
+该流由提交的 pod 触发，该 pod 触发应用程序创建。
Review comment:
```suggestion
该流程由提交的 pod 触发。第一个 pod 触发应用程序创建。
```
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/design/gang_scheduling.md
##########
@@ -0,0 +1,608 @@
+---
+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.
+ -->
+# 帮派调度实现
+一种新的调度应用程序的方法，它考虑了应用程序随着时间的推移预计会产生的资源需求。
+它通过预留资源来保证应用程序的预期需求资源。
+
+这个实现有两个部分：
+* Kubernetes Shim
+* Core（以后成为核心）和 scheduling (调度)
+
+本文档描述了核心端的实现。
+
+## 文档目标
+本文档描述了以下实现设计要点：
+1. 定义 shim 到核心通信所需的调整（调度器接口）
+2. 调度器存储对象变化
+3. 调度器逻辑变化
+
+## 排除的设计点
+目前，本设计文档未涵盖 Kubernetes shim 端实现。
+
+本设计将 _不_ 讨论核心端的广义抢占。
+
+## 通用流程
+该流由提交的 pod 触发，该 pod 触发应用程序创建。
+在 Spark 应用程序中，第一个 Pod 是驱动程序 Pod。
+如果流程是从应用程序 CRD 的创建触发的，则不会有第一个 pod。
+然而，这超出了核心调度逻辑。从核心方面来看，这两种情况应该没有区别。
+更多细节在 [调度器逻辑更改](#scheduler-logic-changes) 章节中。
+
+提交申请的流程。图中的数字对应于图下方的描述。
+
+
+
+应用程序启动期间shim和核心的组合流程：
+* 提交的应用程序定义了任务组。 (1)
+* shim 创建应用程序并将应用程序传递给核心。 (2)
+* shim 为任务组的每个成员创建 placeholder（占位）pod。 (3)
+* 按照正常行为，pod 作为具有正确信息集的应用程序的 AllocationAsk（资源分配请求）被处理并传递给核心。 (4)
+* 占位 AllocationAsk 由核心调度，就好像它们是正常的 AllocationAsk 一样。 (5)
+* 所有分配，即使它们是由调度器分配的占位 AllocationAsks 的结果，也会被传送回 shim。
+* 原始的实际 pod 作为 AllocationAsk 传递给核心。 (6)
+* 在实际 pod 和所有占位 pod 被调度后，shim 启动触发应用程序创建实际 pod。 (7)
+
+在第一个实际 pod 启动后，以下 pod 都应该以相同的方式处理 (8)：
+* 在 k8s 上创建了一个实际 pod。
+* 处理 pod 并创建一个 AllocationAsk。
+* 调度器处理 AllocationAsk（更多细节见下文）并用实际分配替换预留资源。
+
+## 应用提交处理
+### 预留资源总大小
+
+如果请求一个或多个任务组，应用程序应该提供它要请求的所有任务组成员的总大小。
+如果应用程序在限制了资源的队列中被调度，则需要总资源大小。
+
+该值对于三种情况很重要：
+1. 帮派请求大于队列配额
+2. 开始预调度
+3. 预调度时的资源压力
+
+进一步的细节将在下面的 [在设置了配额的队列中进行调度](#scheduling-in-queues-with-a-quota-set) 中给出
+
+从 shim 传递的信息应该是 AddApplicationRequest 中的一部分。
+任务组的建立或成员数量的详细信息不相关。
+所有任务组成员请求的总资源使用以下方法计算：
+
+
+
+placeholderAsk（占位/资源预留请求）的总计信息作为可选字段添加到 AddApplicationRequest 消息中。
+可以由 shim 根据 pod 描述中提供的 CRD 或注释进行计算。
+
+如果占位请求大于队列上设置的队列配额，则必须拒绝申请。
+这种拒绝是基于我们不能以任何方式满足请求的事实。
+对于所有其他情况，会接受申请并进行正常的安排。
+
+### 使用 FAIR（公平）排序策略处理队列
+Queue sorting for the queue that the application runs in must be set to _FIFO_ or _StateAware_.
+如果将应用程序提交到设置了 FAIR 排序策略的队列，则必须拒绝该应用程序。
+应用程序运行所在队列的队列排序必须设置为 _FIFO_ 或 _StateAware_。
+
+其他队列策略不能保证一次只处理一个 _新的_ 应用程序。
+在 _公平_ 策略的情况下，我们可以同时分配多个 _新的_ 应用程序，从而无法强制实施配额管理。
+使用 _公平_ 策略的另一个副作用可能是我们得到多个应用程序但只有部分能保证分配。
+
+由于核心无法将占位情况放置在任何节点上，因此可以触发自动缩放。
+如果队列使用 _公平_ 排序，这可能会导致其他应用程序使用放大的节点而不是预留资源从而再次破坏帮派调度。
+
+## 在设置了配额的队列中进行调度
+上面已经描述的主要情况是处理大于队列上设置的配额的总占位请求大小。
+提交申请时，我们已经可以评估我们无法满足该要求并拒绝该请求。
+
+在总占位请求确实适合队列的情况下，我们不应该开始调度，直到队列中有足够的可用资源来满足总请求。
+然而，这不会停止对队列中其他应用程序的调度。
+已在队列中运行的应用程序可能会请求更多资源。
+从应用程序的角度来看，它可以请求的资源没有限制。
+应用程序上定义的联邦是有保证的资源数量，而不是应用程序可以请求的最大资源数量。
+
+我们拥有的队列层次结构是很复杂的。
+配额可能不是直接在应用程序运行的队列上设置的。
+它可以设置在某一个父队列上面。
+这种情况可能会变得复杂，我们需要保证记住我们可以实时锁定调度。
+
+在第一阶段中，我们应该关注这样一种情况，即请求的联邦资源也是应用程序将请求的最大资源数。
+当我们查看队列时，我们应该关注具有配额的单个队列级别。
+
+这两个假设对于没有使用从命名空间到队列的动态映射进行动态分配的 spark 用例是正确的。
+
+此外，我们假设队列上设置的配额可以完全分配。
+如果集群没有足够的资源，集群将扩展，直到为所有队列提供全部配额所需的大小。
+
+这也可以在某些用例中利用抢占，例如抢占应用程序超过其总的联邦大小的分配。
+在某些用例中，也可以利用抢占，比如在应用程序的总帮派规模上抢占分配。
+
+通过允许指定时间和应用程序来等待占位分配，或开始使用保留资源的时间，可以添加进一步的增强功能。
+
+## 调度器逻辑变化
+调度器逻辑的变化需要考虑周期的两个部分：
+* 占位请求及其分配。
+* 替换占位的分配。
+
+我们的基本假设是所有 pod 都会向核心生成占位 pod 请求。
+如果我们不使用应用程序 CRD，这包括触发应用程序创建的 pod。
+这个假设是必须的，才能确保调度器核心可以在提交应用程序的两种方式中以相同的方式运行。
+占位 Pod 必须在真正的 Pod 之前与核心通信。
+
+更改占位 AllocationAsks 是第一步。
+作为应用程序创建的一部分，AllocationAsks 被添加。
+添加 AllocationsAsk 通常会根据调度周期触发应用程序状态的更改。
+它将应用程序从 _New_ 状态移动到 _Accepted_ 状态。这与当前设置一致，并且不会更改。
+
+但是，在 AllocationAsk 设置了 _placeholder_ 标志的情况下，分配不应触发状态更改，应用程序保持在 _Accepted_ 状态。
+处理分配请求，直到应用程序没有 pending （挂起）的资源。
+作为安全预防措施，应忽略未设置 _placeholder_ 标志的 AllocationAsk。
+占位 Pod 的所有结果分配都按照正常步骤向 shim 确认。
+这个过程一直持续到没有更多的占位 pod 被分配。
+
+此时的 shim 应为已缓冲的真实 pod 创建分配任务。
+核心不能也不需假设每个应用程序只有一个任务组。
+如果 shim 使用了上述选项1，则核心也无法假设它已收到属于任务组的所有分配任务。
+这也是为什么我们假设每个 pod 都会向核心创建一个占位请求。
+
+第二个变化是用真正的 pod 替换了占位 pod。
+填充程序创建了一个设置了 _任务组名称_ 但未设置 _placeholder_ 标志的 AllocationAsk。
+
+这里描述的过程与通用抢占的过程一致。
+分配由核心释放，然后由 shim 确认。
+对于帮派调度，我们有一个简单的一对一释放关系，在抢占的情况下，我们可以使用具有一对多释放关系的相同流程。
+
+调度器按如下方式处理 AllocationAsk：
+1. 检查应用程序是否有未释放的分配给具有相同 _任务组名称_ 的占位分配。如果没有找到占位分配，将使用正常的分配周期来分配请求。
+2. 一个占位分配被选择并标记为释放。释放占位分配的请求被传送到 shim。这必须是一个异步过程，因为 shim 释放过程取决于底层的 K8s 响应，这可能不是即时的。
+ 注意：此时核心中没有释放任何分配。
+3. 核心“暂停”处理真正的 AllocationAsk，直到 shim 响应确认已释放占位分配。
+ 注意：释放锁以允许调度继续
+4. 在收到来自 shim 的释放确认后，“暂停的” AllocationAsk 处理会结束。
+5. AllocationAsk 分配在与使用的占位相同的节点上。
+ 在任何一种情况下，占位分配的删除都将完成。这一切都需要作为对应用程序、队列和节点的一次更新来实现。
+ * 成功时：创建一个新的分配。
+ * 失败时：尝试在不同的节点上分配，如果失败，AllocationAsk 变得不可调度，并触发扩展。
+6. 将分配传达回shim（如果适用，基于步骤 5）
+
+## 应用程序完成
+应用程序完成一直是一个长期存在的问题。
+目前，应用程序在完成时不会转换到 _completed_ 状态。
+应用程序的当前状态是 [参考文档](./scheduler_object_states.md)。
+但是，此时应用程序将不会达到 _completed_ 状态，而是停留在 _waiting_ 状态。
+
+这提供了许多问题，特别是在长时间运行部署中的内存使用和队列清理的情况下。
+
+### 定义
+由于我们不能依赖在 Kubernetes 上作为 Pod 运行的应用程序来表明它已经完成，因此我们需要定义何时考虑一个应用程序的 _完成_ 。
+在这一点上，我们定义了一个应用程序在定义的时间段内处于 _等待_ 状态时，它会变成 _完成_ 。
+当没有活动分配（已分配资源 > 0）和挂起分配请求（挂起资源 > 0）时，应用程序进入等待状态。
+
+向 _waiting_ 状态的转换已经实现。
+_waiting_ 状态的超时是一项新的功能。
+
+资源预留不被视为活动分配。
+占位请求被视为待处理的资源请求。
+这些情况将在下面的 [清理](#Cleanup) 中处理。
+
+### 清理
+当我们查看帮派调度时，还有一个关于未使用的预留资源、占位请求及其清理的问题。
+预留资源可以在有待处理分配请求或活动分配的任何时候转换为实际分配。
+
+在处理实际分配之前，占位请求将全部转换为占位分配。
+
+进入 _waiting_ 状态已被处理。
+如果将新的分配请求添加到应用程序中，它将转换回 _running_ 状态。
+当我们进入了等待状态，将没有待处理的请求或分配的资源。
+只有可以分配的预留资源。
+
+为了进入 _waiting_ 状态，应用程序必须是干净的。
+但是，我们不能保证在应用程序运行期间应用程序将使用所有预留资源。
+从 _waiting_ 状态转换到 _completed_ 状态根本不需要（占位）分配或请求。
+影响转换的第二种情况是并非所有占位请求都被分配，因此应用程序从不请求任何真正的分配。
+这两种情况可能会阻止应用程序转换出 _accepted_ 或 _waiting_ 状态。
+
+因此，核心中的处理需要考虑两种会影响特定状态的转换的情况：
+1. 占位请求挂起（退出 _accepted_ ）
+2. 占位分配（退出 _waiting_ ）
+
+占位请求挂起：
+挂起的占位符是通过超时来处理的。
+应用程序只能花费有限的时间等待分配所有预留资源。
+这个超时是必需的，因为应用程序的部分占位分配可能会占用集群资源而没有真正使用它们。
+
+应用程序可能排队等待未知时间，等待占位分配开始。
+因此，占位请求的超时不能与应用程序或请求的创建相关联。
+超时必须在分配第一个占位请求时开始。
+
+在所有占位请求都被分配之前，应用程序不能请求真正的分配。
+占位请求也由 shim 跟踪，因为它代表一个 pod。
+在核心中释放请求需要消息在核心和 shim 之间流动以释放该请求。
+但是，在这种情况下，分配预留资源的超时会触发应用程序失败。
+当超时被触发并且占位请求挂起时，应用程序将从它所处的状态转换为 _killed_ 。
+
+本案例的应用状态可以概括为：
+* 申请状态为 _accepted_
+* 占位分配的资源大于零，并且小于 _AddApplicationRequest_ 中的 _placeholderAsk_
+* 待处理资源请求大于零
+
+进入 _killed_ 状态必须自动将应用程序移出队列。
+
+状态更改和占位分配释放可以在单个更新响应消息中处理。 该消息将包含以下内容：
+* _UpdatedApplication_ 用于应用程序的状态变化
+* 一个或多个 _AllocationRelease_ 消息，每个占位一个，_TerminationType_ 设置为 TIMEOUT
+* 一条或多条 _TerminationType_ 设置为 TIMEOUT 的 AllocationAskRelease 消息
+
+shim 首先处理 AllocationAskRelease 消息，然后是 _AllocationResponse_ 消息，最后是 _UpdatedApplication_ 消息。应用程序状态在核心端更改为 _killed_ 状态仅取决于移除所有占位 pod，而不取决于对 _UpdatedApplication_ 消息的响应。
+
+
+
+占位超时期间 shim 和核心的组合流程：
+* 核心超时占位分配。 (1)
+* 删除占位分配被传递到 shim。 (2)
+* 所有占位分配都由 shim 释放，并传回核心。
+* 删除占位分配请求被传递给 shim。 (3)
+* 所有占位分配请求都由 shim 释放，并传回核心。
+* 在占位分配和请求被释放后，核心将应用程序移动到终止状态，将其从队列中移除 (4)。
+* 状态更改在核心和 shim 中完成。 (5)
+
+
+已分配的占位：
+剩余的占位需要由核心释放。
+需要通知 shim 将它们移除。这必须在进入 _完成_ 状态时触发。
+在核心请求释放占位之后，应用程序的状态转换可以继续。
+核心将处理从 shim 返回的占位分配的 _AllocationRelease_ 消息，并将 _TerminationType_ 设置为正常*超时*，而不会触发状态更改。
+
+状态更改和占位分配释放可以在单个更新响应消息中处理。
+该消息将包含以下内容：
+* _UpdatedApplication_ 用于应用程序的状态变化
+* 零个或多个 _AllocationRelease_ 消息，每个占位一个，_TerminationType_ 设置为 *超时*
+
+shim 首先处理 _AllocationResponse_ 消息，然后是 _UpdatedApplication_ 消息。
+应用程序状态在核心端更改为 _完成_ 状态仅依赖于所有占位 pod 的移除，而不依赖于对 _UpdatedApplication_ 消息的响应。
+
+进入 _完成_ 状态会自动将应用程序移出队列。
+这也应该处理我们之前讨论的可能延迟处理来自 shim 的请求的情况，因为我们可以在需要时从 _等待_ 移回 _执行中_ 。
+一个 _完成_ 的应用程序也不应该阻止围绕cron讨论的情况，例如每次调用使用相同的应用程序ID提交。
+具有相同申请ID的 _完成_ 申请不得阻止提交具有相同ID的新申请。
+
+
+cation to the completed state removing it from the queue (6).
+* The state change is finalised in the core and shim. (7)
+在清理应用程序期间 shim 和核心的组合流程：
+* 在 Kubernetes 层发布了一个 pod。 (1)
+* shim 将分配释放传递给核心。 (2)
+* 如果没有挂起或活动的分配，核心会将应用程序转换为等待状态。 (3)
+* 等待状态超时并触发清理。 (4)
+* 删除占位符配被传递到 shim。 (5)
+* 所有占位分配都由 shim 释放，并传回核心。
+* 释放所有占位后，核心将应用程序移动到完成状态，将其从队列中删除 (6)。
+* 状态更改在核心和 shim 中完成。 (7)
+
+## 应用恢复
+在应用程序恢复期间，占位 Pod 与节点上的任何其他 Pod 一样被恢复。
+这些 pod 由 shim 作为节点现有分配的一部分传递到核心。
+现有的分配在核心中没有相应的 _分配请求_。 核心根据恢复的信息生成 _分配请求_ 。
+
+对于联邦调度，_分配请求_ 包含 _任务组名称_ 和 _占位_ 标志。
+在恢复期间，相同的信息必须是 _分配_ 消息的一部分。
+这是因为在两个方向上使用相同的消息，从 RM 到调度器，反之亦然，这意味着我们需要更新消息及其处理。
+
+如果 _分配_ 消息中缺少信息，则恢复的分配将不会在核心中被正确标记。
+恢复的分配将被视为常规分配。
+这意味着它作为替换占位的正常分配周期的一部分被跳过。
+
+逻辑变化只需要现有分配的恢复将接口消息中的字段复制到内核中的分配对象中。
+
+## 接口变化
+需要对 shim 和核心之间的通信进行多次更改，以支持所需的帮派信息。
+
+应用程序必须提供占位请求的总大小，以防止接受永远无法运行的应用程序。
+
+从 shim 发送到核心以进行分配请求的当前对象在 AllocationAsk 中定义。
+由于从调度器核心传回的结果消息不会更改，因此分配不会更改。。但是，对于使用相同分配消息从 shim 到核心的恢复，必须包含与帮派相关的字段。
+必须将与帮派相关的字段添加到这两个消息中。
+
+分配释放请求和响应请求需要支持双向通信，并且需要进行重大更改。
+
Review comment:
I assume the English content below is yet to be translated?
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/api/scheduler.md
##########
@@ -0,0 +1,1318 @@
+---
+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.
+-->
+
+## 分区
+
+显示有关分区的常规信息，如名称、状态、容量、已用容量和节点排序策略。
+
+**URL** : `/ws/v1/partitions`
+
+**方法** : `GET`
+
+**是否需要认证** : NO
+
+### 成功返回
+
+**返回代码** : `200 OK`
+
+**样例内容**
+
+```json
+[
+ {
+ "name": "[mycluster]default",
+ "state": "Active",
+ "lastStateTransitionTime": "2021-05-20 12:25:49.018953 +0530 IST m=+0.005949717",
+ "capacity": {
+ "capacity": "[memory:1000 vcore:1000]",
+ "usedCapacity": "[memory:800 vcore:500]"
+ },
+ "nodeSortingPolicy": {
+ "type": "fair",
+ "resourceWeights": {
+ "memory": 1.5,
+ "vcore": 1.3
+ }
+ },
+ "applications": {
+ "New": 5,
+ "Pending": 5,
+ "total": 10
+ }
+ },
+ {
+ "name": "[mycluster]gpu",
+ "state": "Active",
+ "lastStateTransitionTime": "2021-05-19 12:25:49.018953 +0530 IST m=+0.005949717",
+ "capacity": {
+ "capacity": "[memory:2000 vcore:2000]",
+ "usedCapacity": "[memory:500 vcore:300]"
+ },
+ "nodeSortingPolicy": {
+ "type": "binpacking",
+ "resourceWeights": {
+ "memory": 0,
+ "vcore": 4.11
+ }
+ },
+ "applications": {
+ "New": 5,
+ "Running": 10,
+ "Pending": 5,
+ "total": 20
+ }
+ }
+]
+```
+
+### 错误返回
+
+**返回代码** : `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: .."
+}
+```
+
+## 队列
+
+### 分区队列
+
+获取与给定分区关联的所有队列，并显示有关队列的一般信息，如名称、状态、容量和属性。
+队列的层次结构保存在响应json中。
+
+**URL** : `/ws/v1/partition/{partitionName}/queues`
+
+**方法** : `GET`
+
+**是否需要认证** : NO
+
+### 成功返回
+
+**返回代码** : `200 OK`
+
+**样例内容**
+
+For the default queue hierarchy (only `root.default` leaf queue exists) a similar response to the following is sent back to the client:
Review comment:
You meant to remove this line because it has been translated below?
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/design/cross_queue_preemption.md
##########
@@ -0,0 +1,129 @@
+---
+id: cross_queue_preemption
+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.
+-->
+
+## 问题:
+
+根据我们从 YARN Scheduler 抢占中吸取的教训。
+
+**以下是最糟糕的事情:**
+
+- 抢占是一把“猎枪”，而不是“狙击手”，当抢占决定作出时，没有人知道抢占的资源是否会进入请求队列/应用程序/用户。
+- 抢占逻辑和分配是不同的，我们必须实现（并模仿）我们在调度器分配逻辑中所做的事情。
+
+**以下是最好的事情:**
+
+- 抢占很快（多亏了“猎枪”），回收数千个 contaier 并只需要1秒。
Review comment:
```suggestion
- 抢占很快（多亏了“猎枪”），回收数千个容器只需要1秒。
```
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/design/architecture.md
##########
@@ -0,0 +1,56 @@
+---
+id: architecture
+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.
+-->
+
+Apache YuniKorn (Incubating) 是一个用于容器编排器系统的轻量级通用资源调度器。
+它的创建是为了在大规模、多租户和云本地环境中高效地实现各种工作负载的细粒度资源共享。
Review comment:
```suggestion
它的创建是为了在大规模、多租户和云原生环境中高效地实现各种工作负载的细粒度资源共享。
```
##########
File path: i18n/zh-cn/docusaurus-plugin-content-docs/version-0.12.1/design/cross_queue_preemption.md
##########
@@ -0,0 +1,129 @@
+---
+id: cross_queue_preemption
+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.
+-->
+
+## 问题:
+
+根据我们从 YARN Scheduler 抢占中吸取的教训。
+
+**以下是最糟糕的事情:**
+
+- 抢占是一把“猎枪”，而不是“狙击手”，当抢占决定作出时，没有人知道抢占的资源是否会进入请求队列/应用程序/用户。
+- 抢占逻辑和分配是不同的，我们必须实现（并模仿）我们在调度器分配逻辑中所做的事情。
+
+**以下是最好的事情:**
+
+- 抢占很快（多亏了“猎枪”），回收数千个 contaier 并只需要1秒。
+- 我们已经了解处理DRF、多个抢占策略（队列间/队列内、散弹枪/外科抢占等）是多么痛苦，并且我们已经开发了一些不错的逻辑来确保更好的模块化和插件能力。
+
+## 回答一些有关设计/实现选择的问题
+
+**1\. 我们真的想要抢占延迟吗？（或者我们只是想控制节奏）**
+
+在CS架构中，我们有抢占延迟，即在抢占候选中选择需要杀死的进程，等待一定时间后再杀死它。
+
+抢占延迟的目的是：
+a. 为应用程序留出时间，以便他们可以为坏事情的发生做好准备（不幸的是，至少从我们所知道的情况来看，没有一款应用程序能为这些问题做任何事情）。
+b. 控制抢占速度。
+
+在实践中，我们发现例如集群状态不断变化等情况会引起很多问题，很难保证准确的抢占。
+
+**建议:**
+
+消除抢占延迟，保持控制抢占速度的逻辑（例如 ```yarn.resourcemanager.monitor.capacity.preemption
+.total_preemption_per_round```）。
+我们可以通过抢占来进行资源的分配。
+这并不意味着容器将在发出抢占权后立即停止。
+相反，RM可以控制向容器发送信号和终止容器之间的延迟。
+比如在K8s中终止POD：https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods
Review comment:
```suggestion
比如在K8s中终止Pod：https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] cdmikechen commented on pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
cdmikechen commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1016425473
@yuchaoran2011 @yangwwei @chenya-zhang
good news, I have deploy Chinese website in here <https://cdmikechen.github.io/incubator-yunikorn-site/zh-cn>
We can continue the discussion according to this page to see if there is any subsequent adjustment.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] cdmikechen commented on pull request #108: [YUNIKORN-1031] Add Chinese translation for homepage
Posted by GitBox <gi...@apache.org>.
cdmikechen commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1021176417
@yangwwei
Hi ~ I've merge codes to newest and translate why contents.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] yangwwei commented on pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
yangwwei commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1015712022
Sounds great, thank you for answering my questions.
> I added these files completely according to docusaurus official 2.0 document.
And I will move these documents to current, which is the master version in the official website.
yes, please. Besides that, could you please check our doc here: https://github.com/apache/incubator-yunikorn-site#releasing-a-new-version about how to release a new version of doc. With the translated docs in this PR, what will these steps look like? Could you please elaborate, thanks!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] cdmikechen commented on pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
cdmikechen commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1015954297
@yuchaoran2011 @yangwwei @chenya-zhang
Hi~ I’ve created some sub tasks under YUNIKORN-1029.
And I will focus on [YUNIKORN-1031 Add Chinese translation for homepage](https://issues.apache.org/jira/browse/YUNIKORN-1031) right now. I will follow the update of GitHub at any time and synchronize the new commit to this PR as soon as possible
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] yangwwei merged pull request #108: [YUNIKORN-1031] Add Chinese translation for homepage
Posted by GitBox <gi...@apache.org>.
yangwwei merged pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-yunikorn-site] cdmikechen commented on pull request #108: [YUNIKORN-1029] Add Chinese translation for documents
Posted by GitBox <gi...@apache.org>.
cdmikechen commented on pull request #108:
URL: https://github.com/apache/incubator-yunikorn-site/pull/108#issuecomment-1015282559
@yangwwei
Thank you for your review~ I will change it later. Let me answer these questions first.
> 1. Are we planning to translate the home page as well?
Yes, `docusaurus-plugin-content-pages` is yunikorn home website pages and the preliminary translation has been completed.
> 2\. I noticed that all the files are under `docusaurus-plugin-content-docs/version-0.12.1/`, is this only done for the v0.12.1 doc? I think we need to get the master doc done first. Note, our source docs are under https://github.com/apache/incubator-yunikorn-site/tree/master/docs, and version docs are all generated. I am not familiar with how docusaurus support different languages, but we need to make sure the CN docs are also generated from the master doc.
I added these files completely according to [docusaurus official 2.0 document](https://docusaurus.io/zh-CN/docs/i18n/introduction).
And I will move these documents to current, which is the master version in the official website.
> 3\. Have you tested this locally and how it looks like? If you haven't done this, you can see how to do this locally in this here: https://github.com/apache/incubator-yunikorn-site#make-changes.
I have deployed and verified locally. In the next time, when the translation is relatively perfect, I can provide a docker image or build a private service to preview the new page.
> 1. We need to use consistent terminology in the doc, such as gang scheduling, placement rules, resource quota, leaf queue, and so on. Once all review feedback is received, please don't forget to do a double-check on these terminology words.
In addition to these listed words, I'll try to sort out a proper noun document this week. I will send it to slack `#dev` channel. So that you or other PPMC can review and see which words can be translated and which need to keep the original.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org