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 点的基础上，我们还实现了 ofercommit 功能，也就是说用户创建应用申请了 4 核 4G 内存，底层 pod request 2 核 2G limit 4 核 4G 的情况。这让这个库存设计变得更复杂。


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

1. 不能都提供吗
2. 当然是交给 k8s 调度，物理内存不足不会将 pod 分配到 node 上去的，你的 pod 的 limit 和 request 不是一致吗，不会出现被操作系统 OOM kill
3. 就算 request 小于 limit ，导致 pod 被 OOM kill ，也会被重新调度的，对于无状态负载，要保证负载本身高可用，你应该考虑多副本而不是尽量让一个 pod 不失败

只要你不是无良云厂商，就
不要碰 ofercommit ，不要碰 ofercommit ，不要碰 ofercommit
重要的事情说三遍。

正规做法是接入 VPA ，根据汇总的监控数据建议合适的 request/limit ，督促设置不合理的应用负责人调整资源配置。
通常来说 request 比 limit 小 0.01 就行了。

乱用 request/limit 后果就是你的成本预算和资源核算压根没法做。更不要说做保障了。
k8s 之所以有 request/limit 概念是因为它底层使用的 linux cgroup 有这套东西，所以单纯就搬了上来，实际上这个东西大多数人玩不好，而且 BestEffort 策略本质上是算是舍弃 QoS 的，这又和很多服务场景需求矛盾。

结论：别给你的 user 灌输这堆垃圾概念，直接告诉他实用实报，可以随时通过 VPA 调整就完事了。

我觉得你弄好应用 helm 包装部署，然后弄个 Prometheus 将应用和集群信息好好展示，然后剩下的就让 k8s 自己调度吧，调度不了就让客户手动调资源数据。