resourceAllocatable 和 resourceCapacity 中的 cpu, memory的数值始终是相等的
flpanbin opened this issue · comments
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: 42kshared-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: node1What 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我看文档中的示例，也是这个效果，请问这个是什么机制呢？
另外，还有个疑问：
节点的 CPU 是 48 core, 节点上已运行的进程占用了部分 cpu，但是 kcnr 中统计的 reclaimed 资源还是 48 core, reclaimed的总量和节点的总量保持一致， 也就是说没有排除节点上已使用的CPU，请问这里 reclaimed资源的统计方式什么呢？
此外，还有个疑问：
创建 shared-normal-pod pod后，reclaimed_millicpu 从 48 core减少到 42 core, 一共少了6 core, 看文档解析说： 4 core 是预留资源，请问这样设计的目的是什么呢？这个 4core 可以通过配置修改吗？
这个pod实际只使用了 1 core cpu, request 和 limit 也是 1core, 为什么计算时减少了2core呢？
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 相等的。
另外，还有个疑问： 节点的 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。
此外，还有个疑问： 创建 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，对在线业务造成干扰)。
此外，还有个疑问： 创建 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 这个数值可以配置吗？
另外，还有个疑问： 节点的 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-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 这个参数配置哈。
另外，还有个疑问： 节点的 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 的负载来计算，非容器直接起的进程不会纳入计算哈。
@caohe 非常感谢您的耐心解答。我还有一个疑问，我对一个 shared_cores pod(stress) 持续施压，发现最后Reclaimed资源一直稳定在 4core，不会再继续降低，请问这又是什么机制呢？
另外，还有个疑问： 节点的 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 ?
我试了一下场景：
- 创建 reclaim 型的 pod, reclaim 资源量不变；
- 创建 dedicated型的 pod, reclaim 资源量减少；
- 创建的 pod 未设置 qos_level, 但是设置了 requst和limit，reclaim 资源量减少；
- 创建的pod未设置 qos_level, 也设置了requst 和limit；reclaim 资源量不变；
所以看着像是BestEffort类型的 pod 不会影响 reclaim 资源量计算？
@caohe 非常感谢您的耐心解答。我还有一个疑问，我对一个 shared_cores pod(stress) 持续施压，发现最后Reclaimed资源一直稳定在 4core，不会再继续降低，请问这又是什么机制呢？
@flpanbin 我理解这里其实在另一个 issue 里提到了 #594 (comment) ？
另外，还有个疑问： 节点的 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 ? 我试了一下场景：
- 创建 reclaim 型的 pod, reclaim 资源量不变；
- 创建 dedicated型的 pod, reclaim 资源量减少；
- 创建的 pod 未设置 qos_level, 但是设置了 requst和limit，reclaim 资源量减少；
- 创建的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 资源。
@caohe 非常感谢您的耐心解答。我还有一个疑问，我对一个 shared_cores pod(stress) 持续施压，发现最后Reclaimed资源一直稳定在 4core，不会再继续降低，请问这又是什么机制呢？
@flpanbin 我理解这里其实在另一个 issue 里提到了 #594 (comment) ？
@pendoragon
不好意思，这里没有描述清楚，其实是想了解下 minReclaimedResourceForReport 设计的目的是什么，因为实际的 reclaimed 资源可能是小于这个阈值的，但是从上报结果上看两者是不一致的。令人比较疑惑。
@pendoragon 了解了，感谢！还想再请教下：
- system_cores 会影响 reclaim 资源的计算吗？
- system_cores 的 pod是会分配除独占外所有的core吗？比如节点是16 core， shared_cores 使用1-4，system_cores 是分配1-16吗？（我验证结果是这样，想再确认下）。
@caohe 非常感谢您的耐心解答。我还有一个疑问，我对一个 shared_cores pod(stress) 持续施压，发现最后Reclaimed资源一直稳定在 4core，不会再继续降低，请问这又是什么机制呢？
@flpanbin 我理解这里其实在另一个 issue 里提到了 #594 (comment) ？
@pendoragon 不好意思，这里没有描述清楚，其实是想了解下
minReclaimedResourceForReport设计的目的是什么，因为实际的 reclaimed 资源可能是小于这个阈值的，但是从上报结果上看两者是不一致的。令人比较疑惑。
Hi，minReclaimedResourceForReport 最初的设计目的是在我们内部的调度和 Quota 层面对离线可用的资源进行一定程度的超卖，可以让更多的离线 Pod 调度上去。长期可能会将这个配置下掉，在 SysAdvisor 策略的层面来控制。
@pendoragon 了解了，感谢！还想再请教下：
- system_cores 会影响 reclaim 资源的计算吗？
- system_cores 的 pod是会分配除独占外所有的core吗？比如节点是16 core， shared_cores 使用1-4，system_cores 是分配1-16吗？（我验证结果是这样，想再确认下）。
system_cores 这种 QoS 级别当前还没有实现，可能会是预留一个单独的池子给系统组件使用，如果有兴趣的话欢迎一起共建哈。