假设我们为私有化用户的 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 之类的概念给用户..
1
snipking 87 天前
1. 不能都提供吗
2. 当然是交给 k8s 调度,物理内存不足不会将 pod 分配到 node 上去的,你的 pod 的 limit 和 request 不是一致吗,不会出现被操作系统 OOM kill 3. 就算 request 小于 limit ,导致 pod 被 OOM kill ,也会被重新调度的,对于无状态负载,要保证负载本身高可用,你应该考虑多副本而不是尽量让一个 pod 不失败 |
2
povsister 87 天前
只要你不是无良云厂商,就
不要碰 overcommit ,不要碰 overcommit ,不要碰 overcommit 重要的事情说三遍。 正规做法是接入 VPA ,根据汇总的监控数据建议合适的 request/limit ,督促设置不合理的应用负责人调整资源配置。 通常来说 request 比 limit 小 0.01 就行了。 乱用 request/limit 后果就是你的成本预算和资源核算压根没法做。更不要说做保障了。 k8s 之所以有 request/limit 概念是因为它底层使用的 linux cgroup 有这套东西,所以单纯就搬了上来,实际上这个东西大多数人玩不好,而且 BestEffort 策略本质上是算是舍弃 QoS 的,这又和很多服务场景需求矛盾。 结论:别给你的 user 灌输这堆垃圾概念,直接告诉他实用实报,可以随时通过 VPA 调整就完事了。 |
3
povsister 87 天前
另外,你才刚碰到资源规格的问题。
如果你的资源池有好几代机器,具备不同的 cpu/内存/网络甚至磁盘速度。 你还得考虑基准核/node taint 之类的指标。 平台得定义一个基准性能指标,或者避免同一组工作负载分布在不同规格的节点上。 |
4
Frankcox 87 天前
我觉得你弄好应用 helm 包装部署,然后弄个 Prometheus 将应用和集群信息好好展示,然后剩下的就让 k8s 自己调度吧,调度不了就让客户手动调资源数据。
|