release: 1.4 doc

Signed-off-by: wangjianyu <[email protected]>
koordinator-sh · Jan 17, 2024 · 955a96e · 955a96e
1 parent cf87d8b
commit 955a96e
Show file tree

Hide file tree

Showing 109 changed files with 21,011 additions and 19 deletions.
diff --git a/README-zh.md b/README-zh.md
@@ -14,7 +14,9 @@
 - 如果你添加的是当前稳定版本包含的功能文档（例如 v1.0），请添加：
   - 英文文档到 `docs/` 和 `versioned_docs/version-v1.0` 两个地方
   - 中文文档到 `i18n/zh-Hans/docusaurus-plugin-content-docs/current` 和 `i18n/zh-Hans/docusaurus-plugin-content-docs/version-v1.0` 两个地方
-
+- 如果你要发布博客，请添加：
+   - 英文文档到 `blog/`
+   - 中文文档到 `i18n/zh-Hans/docusaurus-plugin-content-blog/`
 您可以使用以下命令在本地调试文档：
 
 ```

diff --git a/README.md b/README.md
@@ -20,6 +20,9 @@ This is **IMPORTANT** to know:
 - If you are adding docs for features that have already supported in stable release (e.g., v1.0), please add:
   - EN docs into both `docs/` and `versioned_docs/version-v1.0`
   - ZH docs into both `i18n/zh-Hans/docusaurus-plugin-content-docs/current` and `i18n/zh-Hans/docusaurus-plugin-content-docs/version-v1.0`
+- If you are publishing blog, please add:
+  - EN docs into `blog/`
+  - ZH docs into `i18n/zh-Hans/docusaurus-plugin-content-blog/`
 
 You can debug the docs locally with the following command:
 

diff --git a/blog/2022-05-31-release/index.md b/blog/2022-05-31-release/index.md
@@ -161,7 +161,7 @@ To enable this feature, you need to update the kernel and configuration file, th
 
 There are two components involved, koord-runtime-proxy and RuntimePlugins.
 
-![image](../../static/img/koord-runtime-proxy-architecture.svg)
+![image](/img/koord-runtime-proxy-architecture.svg)
 
 ### koord-runtime-proxy
 koord-runtime-proxy is in charge of intercepting request during pod's lifecycle, such as RunPodSandbox, CreateContainer etc., and then calling RuntimePlugins to do resource isolation policies before transferring request to backend containerd(dockerd) and after transferring response to kubelet. koord-runtime-proxy provides an isolation-policy-execution framework which allows customized plugins registered to do specified isolation policies, these plugins are called RuntimePlugins. koord-runtime-proxy itself does NOT do any isolation policies.

diff --git a/blog/2022-09-23-release/index.md b/blog/2022-09-23-release/index.md
@@ -21,7 +21,7 @@ Gang scheduling是在并发系统中将多个相关联的进程调度到不同
 
 #### 改进 PodGroup 调度失败的处理机制，实现更高效的重试调度
 
-举个例子，PodGroup A 关联了5个Pod，其中前3个Pod通过Filter/Score，进入Wait阶段，第4个Pod调度失败，当调度第5个Pod时，发现第4个Pod已经失败，则拒绝调度。在社区 Coscheduling 实现中，调度失败的PodGroup 会加入到基于cache机制的 lastDeniedPG  对象中，当 cache 没有过期，则会拒绝调度；如果过期就允许继续调度。可以看到 cache 的过期时间很关键，过期时间设置的过长会导致Pod迟迟得不到调度机会，设置的过短会出现频繁的无效调度。<br />而在Enhanced Coscheduling 中，实现了一种基于 ScheduleCycle 的重试机制。以上场景为例，5个Pod的 ScheduleCycle 初始值为 0，PodGroup 对应的 ScheduleCycle 初始值为1；当每一次尝试调度 Pod 时，都会更新 Pod ScheduleCycle 为 PodGroup ScheduleCycle。如果其中一个 Pod 调度失败，会标记当前的 PodGroup ScheduleCycle 无效，之后所有小于 PodGroup ScheduleCycle 的 Pod 都会被拒绝调度。当同一个 PodGroup 下的所有 Pod 都尝试调度一轮后，Pod ScheduleCycle 都更新为当前 PodGroup ScheduleCycle，并递进 PodGroup ScheduleCycle，并标记允许调度。这种方式可以有效规避基于过期时间的缺陷，完全取决于调度队列的配置重试调度。<br />![image.png](../../static/img/gang-schedulue-cycle.png "基于 ScheduleCycle 的重试机制")
+举个例子，PodGroup A 关联了5个Pod，其中前3个Pod通过Filter/Score，进入Wait阶段，第4个Pod调度失败，当调度第5个Pod时，发现第4个Pod已经失败，则拒绝调度。在社区 Coscheduling 实现中，调度失败的PodGroup 会加入到基于cache机制的 lastDeniedPG  对象中，当 cache 没有过期，则会拒绝调度；如果过期就允许继续调度。可以看到 cache 的过期时间很关键，过期时间设置的过长会导致Pod迟迟得不到调度机会，设置的过短会出现频繁的无效调度。<br />而在Enhanced Coscheduling 中，实现了一种基于 ScheduleCycle 的重试机制。以上场景为例，5个Pod的 ScheduleCycle 初始值为 0，PodGroup 对应的 ScheduleCycle 初始值为1；当每一次尝试调度 Pod 时，都会更新 Pod ScheduleCycle 为 PodGroup ScheduleCycle。如果其中一个 Pod 调度失败，会标记当前的 PodGroup ScheduleCycle 无效，之后所有小于 PodGroup ScheduleCycle 的 Pod 都会被拒绝调度。当同一个 PodGroup 下的所有 Pod 都尝试调度一轮后，Pod ScheduleCycle 都更新为当前 PodGroup ScheduleCycle，并递进 PodGroup ScheduleCycle，并标记允许调度。这种方式可以有效规避基于过期时间的缺陷，完全取决于调度队列的配置重试调度。<br />![image.png](/img/gang-schedulue-cycle.png "基于 ScheduleCycle 的重试机制")
 
 #### 支持多个 PodGroup 为一组完成 Gang Scheduling
 
@@ -98,7 +98,7 @@ spec:
 ```
 #### 树形结构管理机制和使用方法
 
-需要使用树形结构管理 Quota 时，需要在 ElasticQuota 中追加 Label  `quota.scheduling.koordinator.sh/is-parent`表示当前 ElasticQuota 是否是父节点，`quota.scheduling.koordinator.sh/parent`表示当前 ElasticQuota 的父节点 ElasticQuota 的名字。举个例子：<br />![image.png](../../static/img/quota-tree.png)<br />我们创建一个 ElasticQuota Root 作为根节点，资源总量为CPU 100C，内存200Gi，以及子节点 quota-a
+需要使用树形结构管理 Quota 时，需要在 ElasticQuota 中追加 Label  `quota.scheduling.koordinator.sh/is-parent`表示当前 ElasticQuota 是否是父节点，`quota.scheduling.koordinator.sh/parent`表示当前 ElasticQuota 的父节点 ElasticQuota 的名字。举个例子：<br />![image.png](/img/quota-tree.png)<br />我们创建一个 ElasticQuota Root 作为根节点，资源总量为CPU 100C，内存200Gi，以及子节点 quota-a
 ```yaml
 apiVersion: scheduling.sigs.k8s.io/v1alpha1
 kind: ElasticQuota
@@ -152,13 +152,13 @@ spec:
 - runtime 表示 ElasticQuota 当前可以使用的实际资源量。如果 request 小于 min，runtime 等于 request。这也意味着，需要遵循 min 语义，应无条件满足 request。如果 request 大于 min，且 min 小于 max，公平性保障机制会分配 runtime 在min 与 max 之前，即 max >= runtime >= min。
 - shared-weight 表示一个 ElasticQuota 的竞争力，默认等于 ElasticQuota Max。
 
-通过几个例子为大家介绍公平性保障机制的运行过程，假设当前集群的 CPU 总量为100C，并且有4个ElasticQuota，如下图所示，绿色部分为 Request 量：A 当前的request 为5，B当前的request为20，C当前的Request为30，D当前的Request为70。<br />![image.png](../../static/img/quota-init-example.png)<br />并且我们注意到， A, B, C, D 的 min 之和是60，剩下 40 个空闲额度， 同时 A 还可以借给 B, C, D 5个额度，所以一共有45个额度被B，C，D共享，根据各个ElasticQuota的 shared-weight，B，C，D分别对应60，50和80，计算出各自可以共享的量：
+通过几个例子为大家介绍公平性保障机制的运行过程，假设当前集群的 CPU 总量为100C，并且有4个ElasticQuota，如下图所示，绿色部分为 Request 量：A 当前的request 为5，B当前的request为20，C当前的Request为30，D当前的Request为70。<br />![image.png](/img/quota-init-example.png)<br />并且我们注意到， A, B, C, D 的 min 之和是60，剩下 40 个空闲额度， 同时 A 还可以借给 B, C, D 5个额度，所以一共有45个额度被B，C，D共享，根据各个ElasticQuota的 shared-weight，B，C，D分别对应60，50和80，计算出各自可以共享的量：
 
 - B 可以获取 14个额度， 45 * 60 / (60 + 50 + 80) = 14
 - C 可以获取 12个额度， 45 * 50 / (60 + 50 + 80) = 12
 - D 可以获取 19个额度， 45 * 80 / (60 + 50 + 80) = 19
 
-![image.png](../../static/img/quota-init-runtime-example.png)<br />但我们也要注意的是，C和D需要更多额度，而 B只需要5个额度就能满足 Request，并且 B 的min是15，也就意味着我们只需要给 B 5个额度，剩余的9个额度继续分给C和D。
+![image.png](/img/quota-init-runtime-example.png)<br />但我们也要注意的是，C和D需要更多额度，而 B只需要5个额度就能满足 Request，并且 B 的min是15，也就意味着我们只需要给 B 5个额度，剩余的9个额度继续分给C和D。
 
 - C 可以获取 3个额度， 9 * 50 / (50 + 80) = 3
 - D 可以获取 6个额度，  9 * 80 / (50 + 80) = 6
@@ -187,7 +187,7 @@ Koordinator ElasticQuota 机制在调度阶段如果发现 Quota 不足，会进
 
 ### Device Share Scheduling
 
-机器学习领域里依靠大量强大算力性能的 GPU 设备完成模型训练，但是 GPU 自身价格十分昂贵。如何更好地利用GPU设备，发挥GPU的价值，降低成本，是一个亟待解决的问题。  Kubernetes 社区现有的 GPU 分配机制中，GPU 是由 kubelet 分配的，并只支持分配一个或多个完整的 GPU 实例。 这种方法简单可靠，但类似于 CPU 和 Memory，GPU 并不是一直处于高利用率水位，同样存在资源浪费的问题。 因此，Koordinator 希望支持多工作负载共享使用 GPU 设备以节省成本。 此外，GPU 有其特殊性。 比如下面的 NVIDIA GPU 支持的 NVLink 和超卖场景，都需要通过调度器进行中央决策，以获得全局最优的分配结果。<br />![image.png](../../static/img/nvlink.png)
+机器学习领域里依靠大量强大算力性能的 GPU 设备完成模型训练，但是 GPU 自身价格十分昂贵。如何更好地利用GPU设备，发挥GPU的价值，降低成本，是一个亟待解决的问题。  Kubernetes 社区现有的 GPU 分配机制中，GPU 是由 kubelet 分配的，并只支持分配一个或多个完整的 GPU 实例。 这种方法简单可靠，但类似于 CPU 和 Memory，GPU 并不是一直处于高利用率水位，同样存在资源浪费的问题。 因此，Koordinator 希望支持多工作负载共享使用 GPU 设备以节省成本。 此外，GPU 有其特殊性。 比如下面的 NVIDIA GPU 支持的 NVLink 和超卖场景，都需要通过调度器进行中央决策，以获得全局最优的分配结果。<br />![image.png](/img/nvlink.png)
 
 从图中我们可以发现，虽然该节点有8个 GPU 实例，型号为A100/V100，但 GPU 实例之间的数据传输速度是不同的。 当一个 Pod 需要多个 GPU 实例时，我们可以为 Pod 分配具有最大数据传输速度组合关系的 GPU 实例。 此外，当我们希望一组 Pod 中的 GPU 实例具有最大数据传输速度组合关系时，调度器应该将最佳 GPU 实例批量分配给这些 Pod，并将它们分配到同一个节点。
 
@@ -261,7 +261,7 @@ Kuberetes 社区原生提供的设备调度机制中，调度器只负责校验
 
 #### 单机侧精准绑定设备信息
 
-Kubernetes 社区在 kubelet 中提供了 DevicePlugin 机制，支持设备厂商在 kubelet 分配好设备后有机会获得设备信息，并填充到环境变量或者更新挂载路径。但是不能支持 中心化的 GPU 精细化调度场景。<br />针对这个问题， Koordinator 扩展了 koord-runtime-proxy ，支持在 kubelet 创建容器时更新环境变量，注入调度器分配的 GPU 设备信息。<br />![](../../static/img/koordlet-inject-env.jpeg)
+Kubernetes 社区在 kubelet 中提供了 DevicePlugin 机制，支持设备厂商在 kubelet 分配好设备后有机会获得设备信息，并填充到环境变量或者更新挂载路径。但是不能支持 中心化的 GPU 精细化调度场景。<br />针对这个问题， Koordinator 扩展了 koord-runtime-proxy ，支持在 kubelet 创建容器时更新环境变量，注入调度器分配的 GPU 设备信息。<br />![](/img/koordlet-inject-env.jpeg)
 
 ## 3. 调度器诊断分析