From da79c5a1b4b1904ef273f8411b625db04d6f6f32 Mon Sep 17 00:00:00 2001 From: windsonsea Date: Thu, 9 Apr 2026 10:07:32 +0800 Subject: [PATCH] [zh] Sync dynamic-resource-allocation.md --- .../dynamic-resource-allocation.md | 246 +++++++++--------- 1 file changed, 124 insertions(+), 122 deletions(-) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation.md b/content/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation.md index cd6cf749aa742..8c671e88073ed 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation.md @@ -67,7 +67,6 @@ This page describes _dynamic resource allocation (DRA)_ in Kubernetes. {{< glossary_definition prepend="DRA 是" term_id="dra" length="all" >}} - -DRA 为集群中的设备提供了一种灵活的方式来进行分类、请求和使用。 使用 DRA 具有以下好处： +DRA 为集群中的设备提供了一种灵活的方式来进行分类、请求和使用。使用 DRA 具有以下好处： * **灵活地过滤设备**：使用 Common Expression Language (CEL) 对特定设备属性进行细粒度过滤。 -* **设备共享**：通过引用相应的资源声明，可以让多个容器或 Pod 共享同一个资源。 +* **设备共享**：通过引用相应的资源申领，可以让多个容器或 Pod 共享同一个资源。 * **集中化的设备分类**：设备驱动和集群管理员可以使用设备类， 来为应用运维人员提供针对不同使用场景优化的硬件类别。 例如，你可以创建一个面向通用工作负载的成本优化型设备类，以及一个面向关键任务的高性能设备类。 @@ -118,7 +117,6 @@ workflow when compared to which require per-container device requests, don't support device sharing, and don't support expression-based device filtering. --> - 这些好处相较于[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)， 在设备分配的流程中带来了显著的改进。设备插件需要为每个容器单独请求设备，且不支持设备共享， 也无法基于表达式进行对设备进行过滤。 @@ -128,10 +126,9 @@ don't support expression-based device filtering. The workflow of using DRA to allocate devices involves the following types of users: --> - ### DRA 用户的类型 {#dra-user-types} -使用 DRA 进行设备分配的工作流程里通常涉及到以下几类用户： +使用 DRA 进行设备分配的工作流程里通常涉及到以下几类用户： -* **设备所有者**： 为设备负责。设备的所有者可以是商业厂商、集群运营者，或其他实体。 +* **设备所有者**：为设备负责。设备的所有者可以是商业厂商、集群运营者或其他实体。 若要使用 DRA，设备必须具备兼容 DRA 的驱动程序，该驱动需完成以下工作： * 创建 ResourceSlice，向 Kubernetes 提供节点及资源的信息； @@ -178,7 +175,7 @@ The workflow of using DRA to allocate devices involves the following types of us * **工作负载运维人员**：负责在集群中部署和管理工作负载。 若要使用 DRA 为 Pod 分配设备，工作负载运维人员需要执行以下操作： - * 创建 ResourceClaim 或 ResourceClaimTemplate，以便于基于指定的 DeviceClass + * 创建 ResourceClaim 或 ResourceClaimTemplate，以便基于指定的 DeviceClass 请求特定的设备配置； * 部署引用这些 ResourceClaim 或 ResourceClaimTemplate 的工作负载。 @@ -202,7 +199,7 @@ DeviceClass ResourceClaims select specific device attributes. --> DeviceClass -: 定义一类可被申领的设备，以及在声明中如何按设备属性来选择这些设备。 +: 定义一类可被申领的设备，以及在申领中如何按设备属性来选择这些设备。 DeviceClass 中的参数可与 ResourceSlice 中的零个或多个设备匹配。 当申领某个 DeviceClass 的设备时，ResourceClaim 会按照特定的设备属性来过滤。 @@ -214,7 +211,7 @@ ResourceClaim or generated by Kubernetes based on a ResourceClaimTemplate. --> ResourceClaim -: 描述了对集群中已挂接资源（如设备）的分配请求。 +: 描述对集群中已挂接资源（如设备）的分配请求。 ResourceClaim 使 Pod 能够访问某个特定的资源。 ResourceClaim 既可以由工作负载运维人员创建， 也可以由 Kubernetes 根据 ResourceClaimTemplate 自动生成。 @@ -229,9 +226,9 @@ ResourceClaimTemplate --> ResourceClaimTemplate : 定义一个模板，Kubernetes 会根据它为工作负载中的每个 Pod 创建独立的 ResourceClaim。 - ResourceClaimTemplate 使 Pod 能够访问相互独立但相似的资源。 + ResourceClaimTemplate 使 Pod 能够访问相互独立但相似的资源。 Kubernetes 根据模板生成的每个 ResourceClaim 都会与某个特定的 Pod 绑定。 - 当该 Pod 终止时，Kubernetes 将会自动删除对应的 ResourceClaim。 + 当 Pod 终止时，Kubernetes 将会自动删除对应的 ResourceClaim。 - ### ResourceClaim 和 ResourceClaimTemplate {#resourceclaims-templates} ResourceClaim 定义某个工作负载所需的资源。每个 ResourceClaim 都包含一个或多个引用了某个 -DeviceClass 并从其中选择具体的设备的 _request_。 - +DeviceClass 并从其中选择具体设备的 _request_。 ResourceClaim 也可以使用 _selectors_ 来筛选满足特定条件的设备，并通过 _constraints_ 来限制可以满足请求的设备。ResourceClaim 可以被工作负载运维人员创建，也可以由 Kubernetes -根据 ResourceClaimTemplate 生成。ResourceClaimTemplate 定义了一个模版来让 +根据 ResourceClaimTemplate 生成。ResourceClaimTemplate 定义了一个模板来让 Kubernetes 能根据它为 Pod 自动生成 ResourceClaim。 - #### ResourceClaim 和 ResourceClaimTemplate 的使用场景 {#when-to-use-rc-rct} 使用方式取决于你的需求，例如： -* **ResourceClaim**： 你希望多个 Pod 对某个特定设备进行共享访问。你可以创建 ResourceClaim +* **ResourceClaim**：你希望多个 Pod 对某个特定设备进行共享访问。你可以创建 ResourceClaim 并对其生命周期进行手动管理。 * **ResourceClaimTemplate**：你希望 Pod 能够有对独立但有相似配置的设备进行独立访问。 Kubernetes 可以基于 ResourceClaimTemplate 中的定义生成 ResourceClaim，而每个生成的 @@ -322,8 +316,7 @@ When you define a workload, you can use to filter for specific device attributes or capacity. The available parameters for filtering depend on the device and the drivers. --> -当你在定义一个工作负载时，你可以使用 -{{< glossary_tooltip term_id="cel" text="通用表达式语言（CEL）" >}} +当你在定义一个工作负载时，你可以使用{{< glossary_tooltip term_id="cel" text="通用表达式语言（CEL）" >}} 来针对特定设备的属性和容量进行过滤。这些可用于过滤的参数则取决于具体的设备与其驱动程序。 如果你直接将一个特定的 ResourceClaim 关联到一个 Pod，则这个 ResourceClaim 必须已存在于与该 Pod 相同的命名空间中。如果这个 ResourceClaim 在该命名空间不存在， -该 Pod 将不会被调度。 这个行为类似于 PersistentVolumeClaim： +该 Pod 将不会被调度。这个行为类似于 PersistentVolumeClaim： 被 Pod 引用的 PersistentVolumeClaim 必须存在于与该 Pod 相同的命名空间中。 +#### 按优先级排序的列表 {#prioritized-list} {{< feature-state feature_gate_name="DRAPrioritizedList" >}} + -#### 按优先级排序的列表 {#prioritized-list} - -{{< feature-state feature_gate_name="DRAPrioritizedList" >}} - 你可以在 ResourceClaim 中为请求提供按优先级排序的子请求列表。调度器将选择第一个能够分配的子请求。 这使得用户能够在首选设备不可用时指定工作负载可以使用的替代设备。 @@ -429,12 +421,12 @@ Prioritized lists is a *beta feature* and is enabled by default with the `DRAPrioritizedList` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) in the kube-apiserver and kube-scheduler. --> -该决策是针对每个 Pod 独立做出的。 因此如果该 Pod 是 ReplicaSet 或其他类似组中的一员的时候， +该决策是针对每个 Pod 独立做出的。因此如果该 Pod 是 ReplicaSet 或其他类似组中的一员的时候， 你不能假定该组中的所有成员都会选择相同的子请求。你的工作负载必须能够适应这种情况。 -按优先级排序的列表是一个 *Beta 特性*， +按优先级排序的列表是一个 **Beta 特性**， 在 kube-apiserver 和 kube-scheduler 中通过 `DRAPrioritizedList` -[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 默认启用。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)默认启用。 ### ResourceSlice {#resourceslice} @@ -464,7 +456,7 @@ ResourceSlice 为设备使用者和调度器提供了有用的信息，是实现 device driver that manages the pool is responsible for ensuring that this propagation happens. --> -* **资源池**: 一组由驱动程序管理的一个或多个资源。 +* **资源池**：一组由驱动程序管理的一个或多个资源。 一个资源池可以跨越多个 ResourceSlice。当资源池中的资源发生变化时， 必须将这些变更同步到该资源池内的所有 ResourceSlice。 负责管理该资源池的设备驱动程序应确保这一同步过程的正确执行。 @@ -476,7 +468,7 @@ ResourceSlice 为设备使用者和调度器提供了有用的信息，是实现 users can select devices for allocation by filtering for device information in ResourceClaims or in DeviceClasses. --> -* **设备**： 那些在被管理的资源池内的设备。一个 ResourceSlice 可以列出资源池中的所有设备， +* **设备**：那些在被管理的资源池内的设备。一个 ResourceSlice 可以列出资源池中的所有设备， 也可以仅列出其中的一部分。ResourceSlice 定义了设备的一系列信息，例如属性、版本以及容量等。 设备使用者可以在 ResourceClaim 或 DeviceClass 中通过筛选这些设备信息来选择要分配的设备。 @@ -587,7 +579,7 @@ dynamic resource allocation. -### 用户工作流程{#user-workflow} +### 用户工作流程 {#user-workflow} -1. **创建驱动程序**： 设备的所有者或第三方实体会创建那些能够在集群内创建并管理 +1. **创建驱动程序**：设备的所有者或第三方实体会创建那些能够在集群内创建并管理 ResourceSlice 的驱动程序。这些驱动程序还可以创建那些用于定义设备类别和请求方式的 DeviceClass。 -1. **配置集群**： 集群管理员创建集群，将设备挂接到节点上，并安装支持 DRA 的设备驱动程序。 +1. **配置集群**：集群管理员创建集群，将设备挂接到节点上，并安装支持 DRA 的设备驱动程序。 集群管理员可以创建那些用于定义设备类别和请求方式的 DeviceClass。 -1. **资源申领**： 工作负载运维人员创建 ResourceClaimTemplate 或 ResourceClaim， +1. **资源申领**：工作负载运维人员创建 ResourceClaimTemplate 或 ResourceClaim， 以请求指定 DeviceClass 所提供的特定设备配置。同时，应用运维人员通过修改其 Kubernetes 清单以在工作负载中引用这些 ResourceClaimTemplate 或 ResourceClaim。 @@ -693,7 +685,6 @@ following methods: * [ResourceClaim 状态](#resourceclaim-device-status) * [设备健康监控](#device-health-monitoring) - 更多`status.devices`字段的详细信息，请参阅 -{{< api-reference page="workload-resources/resource-claim-v1beta1" anchor="ResourceClaimStatus" text="ResourceClaim" >}} 的 API 参考。 +{{< api-reference page="workload-resources/resource-claim-v1beta1" anchor="ResourceClaimStatus" text="ResourceClaim" >}} +的 API 参考。 +### 设备健康监控 {#device-health-monitoring} {{< feature-state feature_gate_name="ResourceHealthStatus" >}} + +作为一种 Alpha 特性，Kubernetes 提供了一种机制用于监控和上报动态分配的基础设施资源的健康状况。 +对于跑在专用硬件上的有状态的应用而言，了解设备何时发生故障或变得不健康是至关重要的。 +同时，获知设备是否恢复也同样有助于维护应用的稳定性。 + +要开启这个功能，`ResourceHealthStatus` +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/ResourceHealthStatus/)必须启用的同时， +设备驱动程序必须实现了 `DRAResourceHealth` gRPC 服务。 + -### 设备健康监控 {#device-health-monitoring} - -{{< feature-state feature_gate_name="ResourceHealthStatus" >}} - -作为一种 Alpha 特性，Kubernetes 提供了一种机制用于监控和上报动态分配的基础设施资源的健康状况。 -对于跑在专用硬件上的有状态的应用而言，了解设备何时发生故障或变得不健康是至关重要的。 -同时，获知设备是否恢复也同样有助于维护应用的稳定性。 - -要开启这个功能，`ResourceHealthStatus` -[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/ResourceHealthStatus/) -必须启用的同时，设备驱动程序必须实现了 `DRAResourceHealth` gRPC 服务。 - 当一个 DRA 驱动程序发现某个已分配的设备变为不健康，他要将这个状态汇报回 kubelet。 -这些健康状态的信息会直接暴露在 Pod 的状态中。 kubelet 会在每个容器的状态中填充 +这些健康状态的信息会直接暴露在 Pod 的状态中。kubelet 会在每个容器的状态中填充 `allocatedResourcesStatus` 字段，以详细描述分配给该容器的每个设备的健康状况。 这为用户和控制器提供了关键的可观测性，使其能够及时响应硬件故障。 @@ -843,6 +835,25 @@ spec: ... ``` + +## 限制 {#limitations} + +* Kubernetes 调度器当前不支持对 DRA 资源进行[抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)。 + 这意味着，已经在某个节点上运行并使用了 DRA 资源的现有 Pod， + 无法被另一个同样需要 DRA 资源的更高优先级 Pod 抢占。 + 该高优先级 Pod 将保持在 Pending 状态， + 直到设备资源变为可用——通常发生在冲突的 Pod 终止或被手动删除之后。 + +### 可切分设备 {#partitionable-devices} {{< feature-state feature_gate_name="DRAPartitionableDevices" >}} + -### 可切分设备 {#partitionable-devices} - -{{< feature-state feature_gate_name="DRAPartitionableDevices" >}} - DRA 中表示的设备不一定必须是连接到单个机器的单个单元， 也可以是由连接到多个机器的多个设备组成的逻辑设备。 这些设备可能会消耗底层物理设备的重叠资源，这意味着当一个逻辑设备被分配时， @@ -1048,7 +1056,14 @@ device that are used by the logical devices advertised through DRA. Logical devices can specify the ConsumesCounters list. Each entry contains a reference to a CounterSet and a set of named counters with the amounts they will consume. So for a device to be allocatable, the referenced counter sets must have sufficient quantity for the counters referenced by the device. +--> +在 ResourceSlice API 中，这类设备表示为命名 CounterSet 列表，每个 CounterSet 包含一组命名计数器。 +计数器表示物理设备上可供通过 DRA 发布的逻辑设备使用的资源。 + +逻辑设备可以指定 ConsumesCounter 列表。每个条目包含对某个 CounterSet 的引用和一组命名计数器及其消耗量。 +因此，要使设备可被分配，所引用的 CounterSet 必须具有设备引用的计数器所需的足够数量。 + -在 ResourceSlice API 中，这类设备表示为命名 CounterSet 列表，每个 CounterSet 包含一组命名计数器。 -计数器表示物理设备上可供通过 DRA 发布的逻辑设备使用的资源。 - -逻辑设备可以指定 ConsumesCounter 列表。每个条目包含对某个 CounterSet 的引用和一组命名计数器及其消耗量。 -因此，要使设备可被分配，所引用的 CounterSet 必须具有设备引用的计数器所需的足够数量。 - CounterSet 必须在与设备不同的 ResourceSlice 中指定。 -设备可以使用与自身位于同一资源池中的任意 CounterSet 中的计数器。 +设备可以使用与自身位于同一资源池中的任意 CounterSet 中的计数器。 以下是两个设备的示例，每个设备从具有 8Gi 内存的共享计数器中消耗 6Gi 内存。 因此，在任何时间点只能分配其中一个设备。调度器处理这种情况， @@ -1118,11 +1127,9 @@ Partitionable devices is an *alpha feature* and only enabled when the `DRAPartit [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled in the kube-apiserver and kube-scheduler. --> -可切分设备是一个 *Alpha 特性*，它只有当 +可切分设备是一个 **Alpha 特性**，它只有当 kube-apiserver 和 kube-scheduler 中启用了 `DRAPartitionableDevices` -[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) -时，该特性才会被启用。 - +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)时，该特性才会被启用。 可消耗容量特性允许同一台设备被多个独立的 ResourceClaim 同时使用， -由 Kubernetes 调度器负责管理每个声明消耗了多少设备容量。 +由 Kubernetes 调度器负责管理每个申领消耗了多少设备容量。 这一机制类似于多个 Pod 可以共享同一节点上的资源， 多个 ResourceClaim 也可以共享同一设备上的资源。 @@ -1163,7 +1170,7 @@ For example, the driver author can specify that a given capacity is only consume --> 对于允许多次分配的设备，请求的容量将从设备的总容量中提取或消耗， 这一机制被称为**可消耗容量（Consumable Capacity）**。 -随后，调度器会确保所有声明合计消耗的容量总和不会超过设备的整体容量。 +随后，调度器会确保所有申领合计消耗的容量总和不会超过设备的整体容量。 此外，驱动程序的作者还可以通过在单个设备的容量上使用 `requestPolicy` 约束来控制这些容量的消耗方式。 例如，驱动作者可以规定某个资源的容量只能以 1Gi 为单位进行消耗。 @@ -1255,18 +1262,17 @@ To force the use of a only multiply-allocatable devices, you can use the CEL cri +### 设备污点和容忍度 {#device-taints-and-tolerations} {{< feature-state feature_gate_name="DRADeviceTaints" >}} + -### 设备污点和容忍度 {#device-taints-and-tolerations} - -{{< feature-state feature_gate_name="DRADeviceTaints" >}} - 设备污点类似于节点污点：污点具有字符串形式的键、字符串形式的值和效果。 效果应用于使用带污点设备的 ResourceClaim 以及引用该 ResourceClaim 的所有 Pod。 "NoSchedule" 效果会阻止调度这些 Pod。 @@ -1282,7 +1288,15 @@ The "None" effect is ignored by the scheduler and eviction controller. DRA drivers can use it to communicate exceptions to admins or other controllers, like for example degraded health of a device. Admins can also use it to do dry-runs of pod eviction in DeviceTaintRules (more on that below). +--> +"NoExecute" 效果隐含 "NoSchedule" 效果，此外还会导致已调度的所有 Pod 被驱逐。 +这种驱逐是通过 kube-controller-manager 中的设备污点驱逐控制器删除受影响的 Pod 来实现的。 +"None" 效果会被调度器和驱逐控制器忽略。 +DRA 驱动程序可以使用它向管理员或其他控制器传达异常信息，例如设备健康状况下降。 +管理员也可以使用它在 DeviceTaintRules 中执行 Pod 驱逐的预演（详见下文）。 + + -"NoExecute" 效果隐含 "NoSchedule" 效果，此外还会导致已调度的所有 Pod 被驱逐。 -这种驱逐是通过 kube-controller-manager 中的设备污点驱逐控制器删除受影响的 Pod 来实现的。 - -"None" 效果会被调度器和驱逐控制器忽略。 - -DRA 驱动程序可以使用它向管理员或其他控制器传达异常信息，例如设备健康状况下降。 -管理员也可以使用它在 DeviceTaintRules 中执行 Pod 驱逐的预演（详见下文）。 - ResourceClaim 可以容忍污点。如果污点被容忍，其效果将不会生效。 空容忍度匹配所有污点。容忍度可以限制为特定效果和/或匹配特定键/值对。 容忍度可以检查某个键是否存在，无论其值是什么，也可以检查某个键是否具有特定值。 @@ -1328,10 +1334,9 @@ Device taints and tolerations is an *alpha feature* and only enabled when the is enabled in the kube-apiserver, kube-controller-manager and kube-scheduler. To use DeviceTaintRules, the `resource.k8s.io/v1alpha3` API version must be enabled. --> -设备污点和容忍度是一个 *Alpha 特性*，它只有当 +设备污点和容忍度是一个 **Alpha 特性**，它只有当 kube-apiserver、kube-controller-manager 和 kube-scheduler 中启用了 `DRADeviceTaints` -[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) -时，该特性才会被启用。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)时，该特性才会被启用。 要使用 DeviceTaintRules，必须启用 `resource.k8s.io/v1alpha3` API 版本。 +#### 由管理员设置的污点 {#taints-set-by-an-admin} {{< feature-state feature_gate_name="DRADeviceTaintRules" >}} + -#### 由管理员设置的污点 {#taints-set-by-an-admin} - -{{< feature-state feature_gate_name="DRADeviceTaintRules" >}} - 管理员或控制平面组件可以在不告诉 DRA 驱动程序在其 ResourceSlice 中的设备信息中包含污点的情况下为设备添加污点。他们通过创建 DeviceTaintRule 来实现这一点。 每个 DeviceTaintRule 为匹配设备选择算符的设备添加一个污点。 @@ -1452,7 +1456,7 @@ controller adds a condition with some information: --> API 服务器会自动跟踪此污点何时创建，驱逐控制器会添加一个包含一些信息的状况条目： -``` +```shell kubectl describe devicetaintrules ``` @@ -1487,18 +1491,18 @@ longer, the message provides information about the current status: Pod 会被删除以进行驱逐。通常情况下，这个过程很快，除非对污点的容忍度导致驱逐延迟一段时间， 或者需要驱逐的 Pod 数量非常多。如果耗时较长，消息会提供有关当前状态的信息： - ``` - 2 pods need to be evicted in 2 different namespaces. 1 pod evicted since starting the controller. - ``` +``` +2 pods need to be evicted in 2 different namespaces. 1 pod evicted since starting the controller. +``` 该状况可用于检查当前是否存在进行中的驱逐行为： - ```shell - kubectl wait --for=condition=EvictionInProgress=false DeviceTaintRule/example - ``` +```shell +kubectl wait --for=condition=EvictionInProgress=false DeviceTaintRule/example +``` + + 已发布的设备是指 ResourceSlice 中列出的设备。为其设置污点会阻止将其分配给新的 Pod。 + 只有已分配的设备才会导致正在使用它们的 Pod 被驱逐。 + -已发布的设备是指 ResourceSlice 中列出的设备。为其设置污点会阻止将其分配给新的 Pod。 -只有已分配的设备才会导致正在使用它们的 Pod 被驱逐。 - - 编辑 DeviceTaintRule 并将 effect 更改为 `NoExecute`。 -### 设备绑定状况 {#device-binding-conditions} +### 设备绑定状况 {#device-binding-conditions} {{< feature-state feature_gate_name="DRADeviceBindingConditions" >}} @@ -1559,7 +1563,7 @@ Device Binding Conditions allow the Kubernetes scheduler to delay Pod binding un external resources, such as fabric-attached GPUs or reprogrammable FPGAs, are confirmed to be ready. --> -设备绑定状况允许 Kubernetes 调度器在确认外部资源 +设备绑定状况允许 Kubernetes 调度器在确认外部资源 （例如光纤挂接下的 GPU 或可重编程的 FPGA）确认就绪之前延迟对 Pod 的绑定操作。 -这种等待机制是在调度框架的 -[PreBind 阶段](/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework/#pre-bind) -实现的。 +这种等待机制是在调度框架的 +[PreBind 阶段](/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework/#pre-bind)实现的。 在该阶段，调度器会在继续执行绑定之前检查所有所需的设备状况是否已满足。 这种机制通过避免过早绑定以及支持与外部设备控制器进行协调的方式，提高了调度的可靠性。 @@ -1584,7 +1587,12 @@ To use this feature, device drivers (typically managed by driver owners) must pu following fields in the `Device` section of a `ResourceSlice`. Cluster administrators must enable the `DRADeviceBindingConditions` and `DRAResourceClaimDeviceStatus` feature gates for the scheduler to honor these fields. +--> +要使用此特性，设备驱动程序（通常由驱动程序所有者管理）必须在 `ResourceSlice` 的 +`Device` 部分中发布以下字段。此外为了让调度器能够考虑这些字段，集群管理员必须启用 +`DRADeviceBindingConditions` 和 `DRAResourceClaimDeviceStatus` 特性门控。 + -要使用此特性，设备驱动程序（通常由驱动程序所有者管理）必须在 `ResourceSlice` 的 -`Device` 部分中发布以下字段。 此外为了让调度器能够考虑这些字段，集群管理员必须启用 -`DRADeviceBindingConditions` 和 `DRAResourceClaimDeviceStatus` 特性门控。 - - `bindingConditions`：一个状况类型的列表，在 Pod 能被绑定之前， 所关联的 ResourceClaim 的 status.conditions 字段中的这些状况类型必须被设置为 True。 这些状况通常表示设备就绪信号，例如 "DeviceAttached" 或 "DeviceInitialized"。 - -- `bindingFailureConditions`：一个状况类型的列表，如果在其所关联的 +- `bindingFailureConditions`：一个状况类型的列表，如果在其所关联的 ResourceClaim 的 status.conditions 字段中对应的状况类型被设置为 True， 则代表了一种失败的状态。如果其中的任何一个状况被设置为 True， 调度器将中止绑定，并重新调度该 Pod。 - - `bindsToNode`：若设置为 `true`，调度器会将所选节点的名称记录到 ResourceClaim 的 `status.allocation.nodeSelector` 字段中。 这不会影响 Pod 的 `spec.nodeSelector`，而是在 ResourceClaim 内部设置一个节点选择器，