targetoee commented on code in PR #355: URL: https://github.com/apache/yunikorn-site/pull/355#discussion_r1401664097
########## i18n/zh-cn/docusaurus-plugin-content-docs/current/design/preemption.md: ########## @@ -0,0 +1,455 @@ +--- +id: 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. +--> + +# 抢佔式设计 + +## 简介 + +在过去很长一段时间以来，YuniKorn 的部份代码中都包含了抢佔代码，这个设计是为了去替换掉这些内容。 + +原始代码并没有经过充分测试。 +在 [YUNIKORN-317](https://issues.apache.org/jira/browse/YUNIKORN-317) 移除核心的快取后，抢佔代码已从调度路径中移除。 +唯一的改动是抢佔代码有经过编译修正。 +在新版本抢佔设计的准备过程中，旧代码已经在 [YUNIKORN-1269](https://issues.apache.org/jira/browse/YUNIKORN-1269) 被删除。 + +为了帮助关键的工作负载顺利运行，抢占几乎是所有调度程序都会使用的功能。 +抢佔的重要性来自系统没有这个功能就无法顺利运行的事实，例如 k8s 上的 DaemonSets，以及其他像 SLA 或优先级等因素。 +DaemonSet pod 的抢占已作为 [yunikorn-1085](https://issues.apache.org/jira/browse/YUNIKORN-1085) 的一部份实现，因此，本设计着重在其他工作负载的抢占。 + +## 目标 + +* 重用现有的 Kubernetes 对象 +* 实现队列间抢占 +* 使用核心调度器中的优先级资讯支援抢佔功能 + +## 非目标 + +* 队列内抢占 +* 跨节点抢占 +* 支援所有的优先级 + +## 抢佔与优先级 + +### Kubernetes + +整个集群中，所有命名空间内的所有 Pod 都会根据优先级进行排序。 +相较于优先级低的 Pod，优先级高的 Pod 会先被进行调度。 +Kubernetes 调度程序中的抢占也仅基于这种优先级。 +完整的文档可以在[这里](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/) 找到。 + +关于调度顺序和抢占行为的基本原理是：具有较高优先级的 Pod 比具有较低优先级的 Pod 更重要。 +这个是跨命名空间的，且没有任何限制。 +具有较高优先级的 Pod 会更早地被调度，并可能触发另一个命名空间的 Pod 的抢占。 + +Pod 的规范中定义了优先级。 +优先级是一个数字，在规范中通过 PriorityClass 对象被引用。 +该对象定义了一个优先级，并将其映射到一个值。 +在较新的版本（Kubernetes 1.24 或更高版本）中，PriorityClass 还包含调度阶段的抢占策略。 +此 preemptionPolicy 仅允许 Pod 在调度阶段可以选择不抢占其他优先级较低的 Pod。 +它无法在 Pod 运行时改变抢占行为，也不是为此而设计的。 + +当节点上的 kubelet 驱逐 Pod 时，也会使用 Pod 优先级。 +例如，如果节点超载，或者内存或 CPU 耗尽，节点就会开始驱逐 Pod。 +这些驱逐有助于保持节点稳定，考虑驱逐的 Pod 对象则会根据优先级和其他一些因素进行排序。 + +### YuniKorn + +Kubernetes 中的行为集中在调度周期上。 +如果从批次处理，或资料处理工作负载的角度来检视抢占，我们需要考虑到在运行过程中退出的可能性，不过目前工作负载的配置中没有这一选项。 + +简单的抢占方法符合 Kubernetes 设计用于服务类工作负载的要求。 +服务可以处理底下的 Pod 被抢佔之后所触发的扩容或缩容。 + +但 Spark 的情况并非如此。 +驱动器(driver)的 Pod 会管理这个工作底下其他的 Pod。 +当驱动器被抢占时，整个工作都会受到影响。 +抢占驱动器会产生后续影响，导致多个 Pod 从群集中被删除，对于大型工作而言，这可能意味着数百个 Pod。 +由于这种情况的影响远大于抢佔其他单个 Pod，因此需要尽可能避免抢占驱动器或初始化启动器的 Pod 。 + +我们需要考虑的另一种情况是：在集群上运行的互动式会话。 +这种互动式会话（例如 python notebook）是一次性实例，重新启动会产生重大影响。 +因此，抢占这样的实例也不是个理想的结果。 + +要知道去避免抢佔哪个 Pod 的系统是很困难的，甚至是不可能的。 +在这种情况下，Pod 上设置需要设定「禁止抢占」的标记。 +设计方案将在 Pod 规范中讨论此选项。 + +### 优先级限制 + +在 Kubernetes 集群中，PriorityClass 对象定义了优先级，它是集群层级的物件。 +集群管理员会定义对象，因此也定义了支援的优先级。 + +Pod 上可设置的优先级没有限制。 +提交 Pod 时，唯一的检查是：是否定义了 Pod 规范中的 PriorityClass。 +任何恶意用户都可以创建具有最高优先级的 Pod。 + +限制优先级是可能的，但需要 API 服务器标记，而这很难在公共云环境中被支援。 +在 YuniKorn 调度的集群中，我们无法依赖该选项。 + +## 抢占法则 + +在 Apache YARN 调度器中实施抢占的先验知识被用于创建本设计。 +它构成了「抢占法则」的基础。 +这些法则描述了整体抢占行为。 + +YuniKorn 的抢占基于分层队列模型，以及和分配给队列的资源保证。 + +抢占被用来使队列的使用率至少达到其保证的资源容量，但它不能保证每个队列都能获得这个目标，某些情况下会无法达到这种状态。 +因此，抢占并不能保证会到达最终的最佳状态。 +通常队列的最终状态会接近保证的资源容量。 + +无法达到最佳状态的一个例子是：一组队列的保证资源总和大于群集中当前可用的资源。 +这就不可能让所有队列都获得其保证资源量。 +类似情况还有很多，例如在分层结构中，最大配额设置在层级结构中的某一点，从而无法达到最佳状态。 + +下面提供了规则概述，之后会对每条规则进行详细解释： + +1. 抢佔政策只是强列建议，没有任何保证 +2. 抢占不会使队列的容量低于其保证容量 +3. 一个任务不能抢占同一应用中的其他任务 +4. 除非一个任务的队列低于其保证容量，否则任务不会触发抢占 +5. 除非任务队列超过其保证容量，否则底下的任务不能被抢占 +6. 任务只能抢占优先级较低或相同的任务 +7. 任务不能抢占其抢占范围外的任务（单向限制） + +围绕任务和队列给出的大多数规则都是为了防止抢占风暴或循环抢佔。 +可能引发后续抢占的行为应该被避免，上述规则应保证不会出现这种情况。 +违反规则可能会在调度或应用程序运行期间导致不可预测的行为。 + +### 抢占策略只是强烈建议，没有任何保证 + +Pod 可以请求不被抢占，但这并没有受到保证。 +在某些情况下，调度程序仍有可能抢占 Pod。 +如果没有其他解决方案，这会是最后的手段。 +这意味着抢占策略只是一种强烈的提议，而不是保证。 + +DaemonSet 就可能打破规则，并抢占选择退出抢占规则的 Pod 。 +DaemonSet Pod 必须在指定节点上运行。 +如果该节点上运行的所有 Pod 都是其他 DaemonSet Pod，或选择退出抢占的 Pod 时，在没有其他选择的情况下，即使是退出的 Pod 也会被抢占。 Review Comment: Fix it. Thanks for the suggestion! -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
