合理设置容器资源请求与限制，关键在于根据业务特性设定合理的requests和limits比例，并确保集群节点资源不超分，从而避免容器间互相争抢。
容器资源请求和限制怎么设置才合理
requests和limits是Kubernetes资源管理的核心参数,requests是容器运行所需的最低资源保证，limits是容器能使用的资源上限，设置不合理时，会出现资源争抢甚至节点OOM。
requests和limits的本质区别
- requests：用于调度决策，Kubernetes根据requests之和决定将Pod调度到哪个节点，如果节点空闲资源少于Pod的requests，则不会调度到该节点。
- limits：用于运行时限制，cgroups会根据limits限制容器资源使用，防止单个容器占用过多。
错误设置场景
- requests设置过高：导致节点资源利用率低，Pod无法调度，浪费资源。
- requests设置过低：节点超卖严重，当负载上升时，容器争抢资源，影响性能。
- limits设置过大：容器可能被允许使用过多资源，影响其他容器。
- limits设置过小：容器可能被限制导致性能不足或OOM。
合理设置原则
- CPU资源：requests和limits可以设置不同比例，通常requests设置为期望的基线，limits设置为突发峰值，但比例不宜过大，避免超卖过多导致争抢，行业共识认为，CPU limits与requests的比例一般不超过2:1。
- 内存资源：内存是非压缩资源，一旦分配不能回收，因此建议将内存的requests和limits设置为相同值，避免超卖，如果内存超卖，当节点内存不足时，内核会触发OOM Killer，可能导致容器被驱逐。
实操步骤示例
以Kubernetes Deployment为例：
resources:
requests:
memory: "512Mi"
cpu: "500m"
limits:
memory: "512Mi"
cpu: "1000m"
- 此配置表示容器最低保证512MB内存和0.5核CPU，最多使用1核CPU和512MB内存，内存相等，CPU可突发两倍。
Kubernetes资源争抢如何避免
在Kubernetes集群中,资源争抢往往发生在节点资源不足时，Kubernetes通过QoS类来区分Pod优先级，确保高优先级Pod的资源。
使用QoS类保障关键应用
Kubernetes根据requests和limits的配置将Pod分为三类QoS：
- Guaranteed：当容器内所有容器requests和limits都相等（CPU和内存），且requests和limits都设置时，Pod属于Guaranteed类，这类Pod有最高优先级，不会被驱逐。
- Burstable：当requests和limits不相等，或者至少有一个容器设置了requests但未设置limits时，属于Burstable，这类Pod在资源紧张时可能被驱逐。
- BestEffort：任何容器都没有设置requests和limits时，属于BestEffort，这类Pod在资源争抢时最先被驱逐。
最佳实践：对关键业务使用Guaranteed类，即设置requests==limits，对可弹性伸缩的业务使用Burstable类，但需控制limits与requests的比例。
节点资源预留与超卖控制
- 设置kubelet的
--system-reserved和--kube-reserved参数，为系统进程和Kubernetes组件预留资源，避免被Pod争抢。 - 通过资源配额（ResourceQuota）限制命名空间的总资源使用，避免某个团队过度使用。
- 使用LimitRange设置默认的requests和limits,避免用户忘记设置导致资源争抢。
监控与动态调整
- 定期监控节点资源使用率,使用
kubectl top nodes和kubectl top pods查看实时资源。 - 利用Prometheus等工具设置告警,当节点资源接近阈值时及时扩容或调整资源配置。
- 根据历史数据调整requests和limits,使其更接近实际使用。
生产环境容器资源分配最佳实践
生产环境对稳定性要求高,资源分配需要更加严谨。
区分业务类型
- 在线业务：对延迟敏感，建议使用Guaranteed QoS，requests和limits设置相等，并预留20%左右的余量。
- 离线业务：对延迟不敏感，可以使用Burstable，适当超卖，提高资源利用率。
容器内存限制设置多少合适
容器内存限制设置多少合适,取决于应用的内存使用模式。内存限制应等于或略大于应用正常使用峰值的1.2倍，对于Java应用，需考虑堆内存和非堆内存，设置时留足余量，建议在生产前进行压测，确定内存基线。
Docker容器CPU限制设置
如果使用Docker直接运行容器,可以通过--cpus参数设置CPU限制，例如docker run --cpus=1.5 myapp表示容器最多使用1.5个核心，Docker还支持--cpu-shares设置CPU份额权重，但此参数不是硬限制，仅在CPU争抢时生效，在生产环境中，建议使用--cpus进行硬限制，避免超卖。
利用资源配额防止争抢
在Kubernetes中,可以为每个命名空间设置ResourceQuota：
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-quota
namespace: prod
spec:
hard:
requests.cpu: "10"
requests.memory: "20Gi"
limits.cpu: "20"
limits.memory: "40Gi"
这样,命名空间内所有Pod的requests总和不能超过10核，limits总和不能超过20核，从根源上防止资源争抢。
避免资源争抢的高级技巧
使用PodDisruptionBudget保底
对于有状态应用,使用PodDisruptionBudget确保在自愿干扰（如节点维护）时，有一定数量的Pod保持运行，避免全部被驱逐导致服务不可用。
节点亲和性与反亲和性
将关键应用调度到独立的节点池,避免与资源消耗大的应用混部，减少争抢可能。
垂直与水平自动伸缩
- 垂直自动伸缩（VPA）：根据历史使用自动调整requests和limits，但需注意VPA调整会重启Pod，对在线业务有影响。
- 水平自动伸缩（HPA）：根据CPU或内存使用率自动增加副本数，分散负载，减少单个Pod的压力。
Q&A：容器资源请求和限制常见问题
容器资源请求和限制怎么设置才不导致争抢？
核心是设置合理的requests和limits比例,CPU可以设置requests小于limits，但比例不超过2:1，内存必须设置requests==limits，避免超卖，为关键业务使用Guaranteed QoS，并通过ResourceQuota限制命名空间资源总量。
内存超卖会导致容器争抢吗？
是的,内存超卖是容器争抢和OOM的主要原因，当节点内存使用超过总内存时，内核会触发OOM Killer，根据Pod的QoS和内存使用排序，优先杀死BestEffort和Burstable Pod，生产环境建议内存不超卖，即内存requests之和不超过节点内存。
如何避免节点资源碎片化？
节点资源碎片化是指节点上剩余资源无法满足单个Pod的requests,导致调度失败，避免方法包括设置合理的requests避免过大，使用descheduler工具定期重平衡Pod，以及调整节点大小或使用自动扩缩容节点组。