spec:
steps:
- name: <step_name>
computeResources:
requests:
memory: 2Gi
cpu: 600m
limits:
memory: 4Gi
cpu: 900m
如果您在多租户环境中使用集群,则必须控制每个项目和 Kubernetes 对象的 CPU、内存和存储资源的消耗。这有助于防止任何一个应用程序消耗过多资源并影响其他应用程序。
为了定义最终设置在生成的 Pod 上的资源限制,Red Hat OpenShift Pipelines 使用执行它们的项目的资源配额限制和限制范围。
要限制项目中的资源消耗,您可以
设置和管理资源配额 以限制总资源消耗。
使用 限制范围来限制资源消耗,用于特定对象,例如 Pod、镜像、镜像流和持久卷声明。
每个任务都包含许多必需步骤,这些步骤需要按照 `Task` 资源的 `steps` 字段中定义的特定顺序执行。每个任务都作为 Pod 运行,每个步骤都在该 Pod 内作为容器运行。
`steps`规范中的`Resources`字段指定了资源消耗的限制。默认情况下,CPU、内存和临时存储的资源请求设置为`BestEffort`(零)值或通过该项目中的限制范围设置的最小值。
spec:
steps:
- name: <step_name>
computeResources:
requests:
memory: 2Gi
cpu: 600m
limits:
memory: 4Gi
cpu: 900m
当在执行管道和任务运行的项目中指定了`LimitRange`参数和容器资源请求的最小值时,Red Hat OpenShift Pipelines 将查看项目中的所有`LimitRange`值,并使用最小值而不是零。
apiVersion: v1
kind: LimitRange
metadata:
name: <limit_container_resource>
spec:
limits:
- max:
cpu: "600m"
memory: "2Gi"
min:
cpu: "200m"
memory: "100Mi"
default:
cpu: "500m"
memory: "800Mi"
defaultRequest:
cpu: "100m"
memory: "100Mi"
type: Container
...
当您在 Pod 中的容器上设置资源限制时,OpenShift Container Platform 会将请求的资源限制相加,因为所有容器同时运行。
为了在调用的任务中每次仅执行一步时消耗最少的资源,Red Hat OpenShift Pipelines 会请求步骤中指定的最大 CPU、内存和临时存储,这些步骤需要最多的资源。这确保满足所有步骤的资源需求。除最大值以外的其他请求都设置为零。
但是,这种行为可能会导致资源使用量高于所需。如果您使用资源配额,这也可能导致 Pod 无法调度。
例如,考虑一个使用脚本的任务,该任务包含两个步骤,并且未定义任何资源限制和请求。生成的 Pod 包含两个 init 容器(一个用于入口点复制,另一个用于编写脚本)和两个容器,每个步骤一个。
OpenShift Container Platform 使用为项目设置的限制范围来计算所需的资源请求和限制。对于此示例,请在项目中设置以下限制范围:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-min-max-demo-lr
spec:
limits:
- max:
memory: 1Gi
min:
memory: 500Mi
type: Container
在这种情况下,每个 init 容器使用 1Gi 的请求内存(限制范围的最大限制),每个容器使用 500Mi 的请求内存。因此,Pod 的总内存请求为 2Gi。
如果将相同的限制范围用于包含十个步骤的任务,则最终内存请求为 5Gi,这高于每个步骤实际需要的 500Mi(因为每个步骤都在另一个步骤之后运行)。
因此,为了减少资源消耗,您可以:
通过将不同的步骤组合成一个更大的步骤(使用脚本功能和相同的镜像),减少给定任务中的步骤数量。这减少了最小的请求资源。
将相对独立且可以自行运行的步骤分配到多个任务,而不是单个任务。这降低了每个任务中的步骤数量,使每个任务的请求更小,调度程序可以在资源可用时运行它们。