Kubernetes创建Pod时CPU与内存request、limit默认值及相关配置问题

1. Pod 资源 request、limit 默认值及内存超限规则 #

• Kubernetes 本身没有全局默认的 CPU/内存 request、limit 值，如果未给 Pod 显式配置，且 Pod 所在命名空间也没有配置 LimitRange 的话，这两个值默认是空。
• 内存的调度规则和 CPU 不一样：未设置内存 limit 的 Pod 理论上可以申请使用节点的全部可用内存，但和 CPU 是可压缩资源的特性不同，内存是不可压缩资源，一旦 Pod 占用内存超过节点可用阈值，kubelet 的 OOM Killer 会优先杀掉 QoS 等级更低的 Pod 来释放内存，并不是无限制占用也不会被回收。

2. 单节点2GB内存部署8个256Mi request/limit的Pod合理性分析 #

• 首先这个分配方案不合理，不建议这么配置。节点的2GB内存不是全部留给业务Pod使用的，还要预留kubelet、系统进程、内核运行所需的内存，一般预留比例至少是节点总内存的10%_{20%，2GB节点至少要预留200}400MB内存，剩下可分配给业务Pod的内存大概只有1.6~1.8GB左右，8个256Mi的Pod总limit已经到2GB，会挤占系统预留内存空间，很容易触发节点OOM导致业务进程被误杀。
• 不推荐所有Pod都设置相同的limit，不同业务的资源消耗特征差异很大：比如无状态Web服务可能内存占用长期稳定，离线计算任务运行时内存可能会短时间暴涨，需要根据业务实际压测水位、长期运行的监控数据来分别设置request和limit，既能避免资源浪费，也能减少业务被OOM杀掉的概率。

3. 新增同配置Pod是否会一直处于Pending状态 #

• 不一定会一直Pending，核心要看调度时的集群资源情况：
  • 如果集群只有这一台2GB的工作节点，且已经部署的8个Pod的request总和已经超过了节点的可分配内存上限，kube-scheduler找不到符合资源要求的节点，新Pod就会处于Pending状态，直到有旧Pod释放资源、节点扩容或者调整Pod的资源配置。
  • 如果集群还有其他带空闲资源的工作节点，或者之前部署的8个Pod实际request总和没有达到节点可分配内存上限，新Pod可以正常调度运行，不会Pending。

内容的提问来源于stack exchange，提问作者Vinay Sorout