有奖征文:轻量对象存储LighthouseCOS用户实践> HOT
TKE Serverless 集群支持 通过 Annotation 指定通过 Request、Limit 自动计算 两种方式,指定为 Pod 分配的资源上限。您可选择其中一种方式进行配置。

通过 Annotation 指定

TKE Serverless 集群支持在工作负载 yaml 中以添加 template annotation 的方式,显式的指定 Pod 资源规格。详情请参见 Annotation 说明

通过 Request、Limit 自动计算

TKE Serverless 集群支持对工作负载设置的 Request 及 Limit 进行计算,自动判断 Pod 运行所需的资源量。根据 Pod 资源类型的不同,其计算方法也略有差异。请参考 CPU Pod 规格计算方法GPU Pod 规格计算方法,进一步了解如何通过 Request、Limit 自动计算指定资源规格。
注意
如指定了工作负载 template annotation,则以 Annotation 配置为准,不进行 Request 及 Limit 核算。
Request 及 Limit 的分配请参考 资源规格 中的 CPU、GPU 支持规格,若设定值与支持规格差别过大可能会导致某项资源分配超预期,造成资源浪费。
无论如何设置 Request 及 Limit,其最终计算结果都会与 资源规格 进行匹配,且最终 Pod 分配的实际资源一定不会超出其中允许的规格。
如 Pod 内所有容器都未设置 Request 及 Limit,则默认使用 Pod 规格为1核2GiB。
如 Pod 内有容器设置了 Request 及 Limit,则分别按下述方式计算 Initcontainer 和业务 Container 值,最终取较大者来匹配 Pod 规格:
Initcontainer 大小计算方式:按照单个 init 容器的 request/limit 判断各自对应的 CPU 内存值,取较大者,若存在单个 initcontainer 未填写 request/limit 值,取默认值1C2GiB。
业务 Container 大小计算方式:业务容器 request 的和值与业务容器 limit 的最大值中的较大值,若业务容器为空,则为1C2GiB。

CPU Pod 规格计算方法

步骤1:分别计算 Pod 的 CPU、Memory 的合计数值

合计数值分别为 Pod 内所有容器的 Request 之和Pod 内所有容器的 Limit 中的最大值中的较大者。

步骤2:按以下情况匹配 Pod 资源规格

CPU 及 Memory 合计数值
Pod 资源选择规则
合计数值均为0
选择规格为1核2GiB。
任一合计数值为0
按非0项的合计数值进行最小匹配。例如,CPU 合计数值为0核,Memory 合计数值为8GiB,则在 Memory 为8GiB的允许规格中进行 CPU 最小匹配,最终选择规格为1核8GiB。
合计数值均不为0
资源规格 进行匹配。首先选择与 CPU 合计数值一致或相近的较大规格(A 规格),然后再选择与 Memory 的相近较大规格:
如 Memory 合计数值 < A 规格的 Memory 区间最小值,则选择 A 规格的 Memory 区间的最小值。
如 Memory 合计数值 > A 规格的 Memory 区间最大值,则选择与 Memory 相近的较大规格(B 规格),并将 CPU 合计数改为 B 规格 CPU。
如 Memory 合计数值在 A 规格 Memory 区间之内,则选择最相近较大双数值。
任一合计数值超过允许的最大规格
出现错误,无法进行匹配。

示例

请结合以下示例,进一步了解 CPU Pod 规格计算方法:
示例1
示例2
resources:
limits:
cpu: "1"
memory: 2Gi
requests:
cpu: "1"
memory: 2Gi
结果:选择 Pod 规格为1核2GiB。
## container1
resources:
limits:
cpu: "4"
memory: 4Gi
requests:
cpu: "2"
memory: 4Gi
## container2
resources:
limits:
cpu: "1"
memory: 2Gi
requests:
cpu: "1"
memory: 2Gi
说明: CPU 合计数值为:max((2+1),max(4,1)) = 4核 Memory 合计数值为:max((4+2),max(4,2)) = 6GiB
结果:
TKE Serverless 集群暂不支持4核6GiB的 Pod 规格,且6GiB小于 CPU 4核对应规格中 Memory 区间的最小值,则调整 Memory 为4核对应规格中 Memory 区间的最小值。最终选择 Pod 规格为4核8GiB。

GPU Pod 规格计算方法

说明
GPU 和 vGPU 的 Request 及 Limit 参数 “nvidia.com/gpu” 通常相等且仅支持整数。
vGPU 可以看作是一种独立的 GPU 类型。例如 1/4*V100,是将一张 V100 GPU 卡 1/4 的算力虚拟为一张完整的卡进行分配,故在请求资源分配时依然应该是申请1卡 GPU,即 “nvidia.com/GPU”=1

步骤1:计算 Pod 的 GPU 的合计数值

GPU 合计数值为 Pod 内所有容器的 Request 之和

步骤2:根据以下情况匹配 Pod 资源规格

CPU、Memory 及 GPU 合计数值
Pod 资源匹配规则
符合规格要求(例如1、2、4、8等)
首先选择与 GPU 合计数值一致或最相近的较大规格(A 规格),再按照 CPU Pod 规格计算方法 对 CPU 及 Memory 进行计算,得出 CPU 规格(B 规格):
如 A 规格的 CPU 及 Memory ≥ B 规格,则选择 A 规格 GPU。
如 A 规格的 CPU 及 Memory < B 规格,则选择与 B 规格的 CPU 及 Memory 最相近且较大的 GPU 规格(C 规格)。此时实际分配的 GPU 卡数会比实际所需更多,为了防止浪费,尽量避免出现此情况,请尽量调小 CPU 及 Memory 的请求数值。
任一合计数值如果超过允许的最大规格
出现错误,无法进行匹配。

示例

请结合以下示例,进一步了解 GPU Pod 规格计算方法:
示例1
示例2
## eks.tke.cloud.tencent.com/gpu-type:V100
resources:
limits:
cpu: "8"
memory: 32Gi
nvidia.com/gpu: "1"
requests:
cpu: "4"
memory: 16Gi
nvidia.com/gpu: "1"
说明: GPU 合计数值为:1 CPU 合计数值为:max(4,8) = 8核 Memory 合计数值为:max(16,32) = 32GiB
结果
8核32GiB小于 资源规格 中 V100 GPU 规格(1卡)对应的 CPU 及 Memory 规格(8核40GiB)。最终选择 Pod 规格为8核40GiB 1*V100。
## eks.tke.cloud.tencent.com/gpu-type:V100
## container1
resources:
limits:
cpu: "8"
memory: 32Gi
nvidia.com/gpu: "1"
requests:
cpu: "4"
memory: 16Gi
nvidia.com/gpu: "1"
## container2
resources:
limits:
cpu: "32"
memory: 128Gi
nvidia.com/gpu: "1"
requests:
cpu: "16"
memory: 64Gi
nvidia.com/gpu: "1"
说明: GPU 合计数值为:1+1 = 2 CPU 合计数值为:max((4+16),max(8,32)) = 32核 Memory 合计数值为:max((16+64),max(32,128)) = 128GiB
结果
32核128GiB大于 V100 GPU 规格(2卡)对应的 CPU 及 Memory 规格(18核80GiB),但小于 V100 GPU 规格(4卡)对应的 CPU 及 Memory 规格(36核160GiB)。 最终选择 Pod 规格为36核160GiB 4*V100,造成了2张 GPU 卡的资源浪费,请尽量避免出现这种情况。