k8s 的节点资源应该怎么设计 “资源库存管理” ？

假设我们为私有化用户的 n 个机器上部署了一个 k8s 集群，并做了一个管理后台，需求是：

1. 用户在后台可以创建我们制作好的应用（底层实际是 pod)，并填写要申请的资源(cpu/ 内存)
2. 用户可以在后台查看节点资源 (cpu/ 内存) 消耗，要提供节点资源的 usage、total 给用户看

问题是：

1. 这个 usage、total 要提供宿主机的物理消耗量、物理总量给用户看，还是提供该节点 pod requests 总和 / node allocatable 给用户看？

2. 假设用户创建一个应用申请了 4 核 4G 内存(request 4cpu,4Gi memory, 且 request 等于 limit)。此时要基于物理剩余量去手动计算挑选出符合条件的节点(api 层面强行指定 node)？还是基于节点的剩余 allocatable 量去让 k8s 自行调度？如果选择前者，那么可能会出现物理剩余量充足但节点剩余可 requests 量不足而无法启动 pod 的错误。如果选择后者，那么可能会出现调度成功，但是这个应用由于物理资源不足导致进程被 oom kill 的情况。

3. 在第 2 点的基础上，我们还实现了 overcommit 功能，也就是说用户创建应用申请了 4 核 4G 内存，底层 pod request 2 核 2G limit 4 核 4G 的情况。这让这个库存设计变得更复杂。

我目前的想法是使用 pod requests 总和 /node allocatable. 并灌输 requests, limits, overcommit 之类的概念给用户..