Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

resourceAllocatable 和 resourceCapacity 中的 cpu, memory的数值始终是相等的 #609

Open
flpanbin opened this issue Jun 5, 2024 · 18 comments

Comments

@flpanbin
Copy link
Contributor

flpanbin commented Jun 5, 2024

What happened?

在创建应用前,查看节点的 kcnr,resourceAllocatable 和 resourceCapacity 中的 cpu和memory 相等,部署应用后,resourceAllocatable 和 resourceCapacity中的数值都减少了,但是Allocatable和 Capacity 还是相等。个人理解 Capacity 应该是保持不变的,减少的应该是 Allocatable?
创建应用前, 节点的 kcnr 信息:

Status:
  Resources:
    Allocatable:
      resource.katalyst.kubewharf.io/reclaimed_memory:    60696174Ki
      resource.katalyst.kubewharf.io/reclaimed_millicpu:  48k
    Capacity:
      resource.katalyst.kubewharf.io/reclaimed_memory:    60696174Ki
      resource.katalyst.kubewharf.io/reclaimed_millicpu:  48k

创建 share应用后, 节点的 kcnr 信息:

Status:
  Resources:
    Allocatable:
      resource.katalyst.kubewharf.io/reclaimed_memory:    52308024Ki
      resource.katalyst.kubewharf.io/reclaimed_millicpu:  42k
    Capacity:
      resource.katalyst.kubewharf.io/reclaimed_memory:    52308024Ki
      resource.katalyst.kubewharf.io/reclaimed_millicpu:  42k

shared-normal-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  annotations:
    "katalyst.kubewharf.io/qos_level": shared_cores
  name: shared-normal-pod
  namespace: default
spec:
  containers:
    - name: stress
      image: joedval/stress:latest
      command:
        - stress
        - -c
        - "1"
      imagePullPolicy: IfNotPresent
      resources:
        requests:
          cpu: "1"
          memory: 1Gi
        limits:
          cpu: "1"
          memory: 1Gi
  schedulerName: katalyst-scheduler
  nodeName: node1

What did you expect to happen?

resourceAllocatable 资源减少,resourceCapacity资源保持不变

How can we reproduce it (as minimally and precisely as possible)?

创建一个 shared_cores pod,观察节点 kcnr 的数值变化情况

Software version

$ <software> version
# paste output here
@flpanbin
Copy link
Contributor Author

flpanbin commented Jun 5, 2024

我看文档中的示例,也是这个效果,请问这个是什么机制呢?

@flpanbin
Copy link
Contributor Author

flpanbin commented Jun 5, 2024

另外,还有个疑问:
节点的 CPU 是 48 core, 节点上已运行的进程占用了部分 cpu,但是 kcnr 中统计的 reclaimed 资源还是 48 core, reclaimed的总量和节点的总量保持一致, 也就是说没有排除节点上已使用的CPU,请问这里 reclaimed资源的统计方式什么呢?

@flpanbin
Copy link
Contributor Author

flpanbin commented Jun 5, 2024

此外,还有个疑问:
创建 shared-normal-pod pod后,reclaimed_millicpu 从 48 core减少到 42 core, 一共少了6 core, 看文档解析说: 4 core 是预留资源,请问这样设计的目的是什么呢?这个 4core 可以通过配置修改吗?
这个pod实际只使用了 1 core cpu, request 和 limit 也是 1core, 为什么计算时减少了2core呢?

@caohe
Copy link
Member

caohe commented Jun 5, 2024

What happened?

在创建应用前,查看节点的 kcnr,resourceAllocatable 和 resourceCapacity 中的 cpu和memory 相等,部署应用后,resourceAllocatable 和 resourceCapacity中的数值都减少了,但是Allocatable和 Capacity 还是相等。个人理解 Capacity 应该是保持不变的,减少的应该是 Allocatable?

What did you expect to happen?

resourceAllocatable 资源减少,resourceCapacity资源保持不变

Hi,在 K8s 的语义中,因为节点的资源量的恒定的,所以 Node 的 Capacity 和 Allocatable 都是不变的。类比到 KCNR 中,Reclaimed 资源的 Allocatable 和 Capacity 是根据 shared_cores 的负载计算的,所以是会变化的。在混部场景下,因为 Reclaimed Resources 的 Capacity 没有特殊的含义,所以是和 Allocatable 相等的。

@caohe
Copy link
Member

caohe commented Jun 5, 2024

另外,还有个疑问: 节点的 CPU 是 48 core, 节点上已运行的进程占用了部分 cpu,但是 kcnr 中统计的 reclaimed 资源还是 48 core, reclaimed的总量和节点的总量保持一致, 也就是说没有排除节点上已使用的CPU,请问这里 reclaimed资源的统计方式什么呢?

官网文档所述:

reclaim cpu = allocatable - round(ceil(reserve + max(usage,load.1min,load.5min))

reserve 的含义是会为 Shared Pool 预留 4 core 的资源,此时这个节点上应该没有 shared_cores 的 Pod,所以没有扣除,还是 48 core。

@caohe
Copy link
Member

caohe commented Jun 5, 2024

此外,还有个疑问: 创建 shared-normal-pod pod后,reclaimed_millicpu 从 48 core减少到 42 core, 一共少了6 core, 看文档解析说: 4 core 是预留资源,请问这样设计的目的是什么呢?这个 4core 可以通过配置修改吗? 这个pod实际只使用了 1 core cpu, request 和 limit 也是 1core, 为什么计算时减少了2core呢?

当创建了一个 shared_cores 的 Pod 后,会减掉 4 + 2 = 6 core。4 是 reserve,2 是 shared_cores 的负载 (1 向上取偶数,即上述公式中的 round + ceil,避免在离线容器共享一个物理核的两个 HT,对在线业务造成干扰)。

@flpanbin
Copy link
Contributor Author

flpanbin commented Jun 5, 2024

此外,还有个疑问: 创建 shared-normal-pod pod后,reclaimed_millicpu 从 48 core减少到 42 core, 一共少了6 core, 看文档解析说: 4 core 是预留资源,请问这样设计的目的是什么呢?这个 4core 可以通过配置修改吗? 这个pod实际只使用了 1 core cpu, request 和 limit 也是 1core, 为什么计算时减少了2core呢?

当创建了一个 shared_cores 的 Pod 后,会减掉 4 + 2 = 6 core。4 是 reserve,2 是 shared_cores 的负载 (1 向上取偶数,即上述公式中的 round + ceil,避免在离线容器共享一个物理核的两个 HT,对在线业务造成干扰)。

另外,还有个疑问: 节点的 CPU 是 48 core, 节点上已运行的进程占用了部分 cpu,但是 kcnr 中统计的 reclaimed 资源还是 48 core, reclaimed的总量和节点的总量保持一致, 也就是说没有排除节点上已使用的CPU,请问这里 reclaimed资源的统计方式什么呢?

官网文档所述:

reclaim cpu = allocatable - round(ceil(reserve + max(usage,load.1min,load.5min))

reserve 的含义是会为 Shared Pool 预留 4 core 的资源,此时这个节点上应该没有 shared_cores 的 Pod,所以没有扣除,还是 48 core。

感谢您的回复。请问为什么是预留 4core呢? 4core 这个数值可以配置吗?

@flpanbin
Copy link
Contributor Author

flpanbin commented Jun 5, 2024

另外,还有个疑问: 节点的 CPU 是 48 core, 节点上已运行的进程占用了部分 cpu,但是 kcnr 中统计的 reclaimed 资源还是 48 core, reclaimed的总量和节点的总量保持一致, 也就是说没有排除节点上已使用的CPU,请问这里 reclaimed资源的统计方式什么呢?

官网文档所述:

reclaim cpu = allocatable - round(ceil(reserve + max(usage,load.1min,load.5min))

reserve 的含义是会为 Shared Pool 预留 4 core 的资源,此时这个节点上应该没有 shared_cores 的 Pod,所以没有扣除,还是 48 core。

请问节点上已有进程占用的这部分cpu 是不会纳入计算的吗?比如节点48core,我直接在节点运行了一个stress, 占用了 10core, 但是 Reclaimed资源还是 48core

@caohe
Copy link
Member

caohe commented Jun 5, 2024

此外,还有个疑问: 创建 shared-normal-pod pod后,reclaimed_millicpu 从 48 core减少到 42 core, 一共少了6 core, 看文档解析说: 4 core 是预留资源,请问这样设计的目的是什么呢?这个 4core 可以通过配置修改吗? 这个pod实际只使用了 1 core cpu, request 和 limit 也是 1core, 为什么计算时减少了2core呢?

当创建了一个 shared_cores 的 Pod 后,会减掉 4 + 2 = 6 core。4 是 reserve,2 是 shared_cores 的负载 (1 向上取偶数,即上述公式中的 round + ceil,避免在离线容器共享一个物理核的两个 HT,对在线业务造成干扰)。

另外,还有个疑问: 节点的 CPU 是 48 core, 节点上已运行的进程占用了部分 cpu,但是 kcnr 中统计的 reclaimed 资源还是 48 core, reclaimed的总量和节点的总量保持一致, 也就是说没有排除节点上已使用的CPU,请问这里 reclaimed资源的统计方式什么呢?

官网文档所述:

reclaim cpu = allocatable - round(ceil(reserve + max(usage,load.1min,load.5min))

reserve 的含义是会为 Shared Pool 预留 4 core 的资源,此时这个节点上应该没有 shared_cores 的 Pod,所以没有扣除,还是 48 core。

感谢您的回复。请问为什么是预留 4core呢? 4core 这个数值可以配置吗?

4 core 是根据我们内部实践的一个经验数值,可以根据情况调整,通过 reserved-resource-for-allocate 这个参数配置哈。

@caohe
Copy link
Member

caohe commented Jun 5, 2024

另外,还有个疑问: 节点的 CPU 是 48 core, 节点上已运行的进程占用了部分 cpu,但是 kcnr 中统计的 reclaimed 资源还是 48 core, reclaimed的总量和节点的总量保持一致, 也就是说没有排除节点上已使用的CPU,请问这里 reclaimed资源的统计方式什么呢?

官网文档所述:

reclaim cpu = allocatable - round(ceil(reserve + max(usage,load.1min,load.5min))

reserve 的含义是会为 Shared Pool 预留 4 core 的资源,此时这个节点上应该没有 shared_cores 的 Pod,所以没有扣除,还是 48 core。

请问节点上已有进程占用的这部分cpu 是不会纳入计算的吗?比如节点48core,我直接在节点运行了一个stress, 占用了 10core, 但是 Reclaimed资源还是 48core

根据 shared_cores pool 的负载来计算,非容器直接起的进程不会纳入计算哈。

@flpanbin
Copy link
Contributor Author

flpanbin commented Jun 5, 2024

@caohe 非常感谢您的耐心解答。我还有一个疑问,我对一个 shared_cores pod(stress) 持续施压,发现最后Reclaimed资源一直稳定在 4core,不会再继续降低,请问这又是什么机制呢?

@flpanbin
Copy link
Contributor Author

flpanbin commented Jun 6, 2024

另外,还有个疑问: 节点的 CPU 是 48 core, 节点上已运行的进程占用了部分 cpu,但是 kcnr 中统计的 reclaimed 资源还是 48 core, reclaimed的总量和节点的总量保持一致, 也就是说没有排除节点上已使用的CPU,请问这里 reclaimed资源的统计方式什么呢?

官网文档所述:

reclaim cpu = allocatable - round(ceil(reserve + max(usage,load.1min,load.5min))

reserve 的含义是会为 Shared Pool 预留 4 core 的资源,此时这个节点上应该没有 shared_cores 的 Pod,所以没有扣除,还是 48 core。

@caohe 您好,对于这个 reclaim资源量的计算还有个疑问,请问公式中的 usage 是统计了哪种类型的 pod ?
我试了一下场景:

  1. 创建 reclaim 型的 pod, reclaim 资源量不变;
  2. 创建 dedicated型的 pod, reclaim 资源量减少;
  3. 创建的 pod 未设置 qos_level, 但是设置了 requst和limit,reclaim 资源量减少;
  4. 创建的pod未设置 qos_level, 也设置了requst 和limit;reclaim 资源量不变;

所以看着像是BestEffort类型的 pod 不会影响 reclaim 资源量计算?

@pendoragon
Copy link
Member

@caohe 非常感谢您的耐心解答。我还有一个疑问,我对一个 shared_cores pod(stress) 持续施压,发现最后Reclaimed资源一直稳定在 4core,不会再继续降低,请问这又是什么机制呢?

@flpanbin 我理解这里其实在另一个 issue 里提到了 #594 (comment)

@pendoragon
Copy link
Member

pendoragon commented Jun 7, 2024

另外,还有个疑问: 节点的 CPU 是 48 core, 节点上已运行的进程占用了部分 cpu,但是 kcnr 中统计的 reclaimed 资源还是 48 core, reclaimed的总量和节点的总量保持一致, 也就是说没有排除节点上已使用的CPU,请问这里 reclaimed资源的统计方式什么呢?

官网文档所述:

reclaim cpu = allocatable - round(ceil(reserve + max(usage,load.1min,load.5min))

reserve 的含义是会为 Shared Pool 预留 4 core 的资源,此时这个节点上应该没有 shared_cores 的 Pod,所以没有扣除,还是 48 core。

@caohe 您好,对于这个 reclaim资源量的计算还有个疑问,请问公式中的 usage 是统计了哪种类型的 pod ? 我试了一下场景:

  1. 创建 reclaim 型的 pod, reclaim 资源量不变;
  2. 创建 dedicated型的 pod, reclaim 资源量减少;
  3. 创建的 pod 未设置 qos_level, 但是设置了 requst和limit,reclaim 资源量减少;
  4. 创建的pod未设置 qos_level, 也设置了requst 和limit;reclaim 资源量不变;

所以看着像是BestEffort类型的 pod 不会影响 reclaim 资源量计算?

@flpanbin
这里其实可以这样来理解:我们是要算出要给在线业务保留多少资源,剩下的资源都可以作为 reclaimed 资源给离线业务使用。

在线业务包括 dedicated_cores 和 shared_cores pods。从 qos 语义上讲,dedicated_cores 是独占 cpu core 的,即使他申请了资源不用,其他 pod 也用不了;shared_cores 是可以被调整 cpuset pool 大小的。

所以其实 reclaimed 资源在算的时候要先扣除掉 dedicated cores 的 request 量,再减去根据 usage 等信息通过算法预估出给 shared_cores 预留的量,再扣除掉 reserve,最后就是可以出让的 reclaim 资源。

@flpanbin
Copy link
Contributor Author

flpanbin commented Jun 7, 2024

@caohe 非常感谢您的耐心解答。我还有一个疑问,我对一个 shared_cores pod(stress) 持续施压,发现最后Reclaimed资源一直稳定在 4core,不会再继续降低,请问这又是什么机制呢?

@flpanbin 我理解这里其实在另一个 issue 里提到了 #594 (comment)

@pendoragon
不好意思,这里没有描述清楚,其实是想了解下 minReclaimedResourceForReport 设计的目的是什么,因为实际的 reclaimed 资源可能是小于这个阈值的,但是从上报结果上看两者是不一致的。令人比较疑惑。

@flpanbin
Copy link
Contributor Author

flpanbin commented Jun 7, 2024

@pendoragon 了解了,感谢!还想再请教下:

  1. system_cores 会影响 reclaim 资源的计算吗?
  2. system_cores 的 pod是会分配除独占外所有的core吗?比如节点是16 core, shared_cores 使用1-4,system_cores 是分配1-16吗?(我验证结果是这样,想再确认下)。

@caohe
Copy link
Member

caohe commented Jun 17, 2024

@caohe 非常感谢您的耐心解答。我还有一个疑问,我对一个 shared_cores pod(stress) 持续施压,发现最后Reclaimed资源一直稳定在 4core,不会再继续降低,请问这又是什么机制呢?

@flpanbin 我理解这里其实在另一个 issue 里提到了 #594 (comment)

@pendoragon 不好意思,这里没有描述清楚,其实是想了解下 minReclaimedResourceForReport 设计的目的是什么,因为实际的 reclaimed 资源可能是小于这个阈值的,但是从上报结果上看两者是不一致的。令人比较疑惑。

Hi,minReclaimedResourceForReport 最初的设计目的是在我们内部的调度和 Quota 层面对离线可用的资源进行一定程度的超卖,可以让更多的离线 Pod 调度上去。长期可能会将这个配置下掉,在 SysAdvisor 策略的层面来控制。

@caohe
Copy link
Member

caohe commented Jun 17, 2024

@pendoragon 了解了,感谢!还想再请教下:

  1. system_cores 会影响 reclaim 资源的计算吗?
  2. system_cores 的 pod是会分配除独占外所有的core吗?比如节点是16 core, shared_cores 使用1-4,system_cores 是分配1-16吗?(我验证结果是这样,想再确认下)。

system_cores 这种 QoS 级别当前还没有实现,可能会是预留一个单独的池子给系统组件使用,如果有兴趣的话欢迎一起共建哈。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants