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

[flpanbin]

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]

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

[flpanbin]

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

[flpanbin]

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

[caohe]

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]

另外，还有个疑问： 节点的 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]

此外，还有个疑问： 创建 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]

此外，还有个疑问： 创建 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]

另外，还有个疑问： 节点的 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]

此外，还有个疑问： 创建 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]

另外，还有个疑问： 节点的 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]

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

[flpanbin]

另外，还有个疑问： 节点的 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]

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

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

[pendoragon]

另外，还有个疑问： 节点的 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]

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

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

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

[flpanbin]

@pendoragon 了解了，感谢！还想再请教下：

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

[caohe]

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

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

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

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

[caohe]

@pendoragon 了解了，感谢！还想再请教下：

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

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