发表于 2024年9月6日1年前 假设我们为私有化用户的 n 个机器上部署了一个 k8s 集群，并做了一个管理后台，需求是： 用户在后台可以创建我们制作好的应用（底层实际是 pod)，并填写要申请的资源(cpu/内存) 用户可以在后台查看节点资源(cpu/内存)消耗，要提供节点资源的 usage 、total 给用户看 问题是： 这个 usage 、total 要提供宿主机的物理消耗量、物理总量给用户看，还是提供该节点 pod requests 总和/ node allocatable 给用户看？ 假设用户创建一个应用申请了 4 核 4G 内存(request 4cpu,4Gi memory, 且 request 等于 limit) 。 此时要基于物理剩余量去手动计算挑选出符合条件的节点(api 层面强行指定 node)？ 还是基于节点的剩余 allocatable 量去让 k8s 自行调度？ 如果选择前者，那么可能会出现物理剩余量充足但节点剩余可 requests 量不足而无法启动 pod 的错误。 如果选择后者，那么可能会出现调度成功，但是这个应用由于物理资源不足导致进程被 oom kill 的情况。 在第 2 点的基础上，我们还实现了 overcommit 功能，也就是说用户创建应用申请了 4 核 4G 内存，底层 pod request 2 核 2G limit 4 核 4G 的情况。这让这个库存设计变得更复杂。 我目前的想法是使用 pod requests 总和/node allocatable. 并灌输 requests, limits, overcommit 之类的概念给用户..
假设我们为私有化用户的 n 个机器上部署了一个 k8s 集群，并做了一个管理后台，需求是：
问题是：
这个 usage 、total 要提供宿主机的物理消耗量、物理总量给用户看，还是提供该节点 pod requests 总和/ node allocatable 给用户看？
假设用户创建一个应用申请了 4 核 4G 内存(request 4cpu,4Gi memory, 且 request 等于 limit) 。 此时要基于物理剩余量去手动计算挑选出符合条件的节点(api 层面强行指定 node)？ 还是基于节点的剩余 allocatable 量去让 k8s 自行调度？ 如果选择前者，那么可能会出现物理剩余量充足但节点剩余可 requests 量不足而无法启动 pod 的错误。 如果选择后者，那么可能会出现调度成功，但是这个应用由于物理资源不足导致进程被 oom kill 的情况。
在第 2 点的基础上，我们还实现了 overcommit 功能，也就是说用户创建应用申请了 4 核 4G 内存，底层 pod request 2 核 2G limit 4 核 4G 的情况。这让这个库存设计变得更复杂。
我目前的想法是使用 pod requests 总和/node allocatable. 并灌输 requests, limits, overcommit 之类的概念给用户..