如何为容器配置 Request 与 Limit? 这是一个即常见又辣手的问题，这个依据服务类型，需要与场景的不同而不同，没有固定的答案，这里联合生产经验总结了一些最佳实际，能够作为参考。
所有容器都应该设置 request
request 的值并不是指给容器理论调配的资源大小，它仅仅是给调度器看的，调度器会 “ 察看 ” 每个节点能够用于调配的资源有多少，也晓得每个节点曾经被调配了多少资源。被分配资源的大小就是节点上所有 Pod 中定义的容器 request 之和，它能够计算出节点残余多少资源能够被调配 (可分配资源减去已调配的 request 之和)。如果发现节点残余可分配资源大小比以后要被调度的 Pod 的 reuqest 还小，那么就不会思考调度到这个节点，反之，才可能调度。所以，如果不配置 request，那么调度器就不能晓得节点大略被调配了多少资源进来，调度器得不到精确信息，也就无奈做出正当的调度决策，很容易造成调度不合理，有些节点可能很闲，而有些节点可能很忙，甚至 NotReady。
所以，倡议是给所有容器都设置 request，让调度器感知节点有多少资源被调配了，以便做出正当的调度决策，让集群节点的资源可能被正当的调配应用，防止陷入资源分配不均导致一些意外产生。
老是遗记设置怎么办
有时候咱们会遗记给局部容器设置 request 与 limit，其实咱们能够应用 LimitRange 来设置 namespace 的默认 request 与 limit 值，同时它也能够用来限度最小和最大的 request 与 limit。
示例:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
namespace: test
spec:
limits:
- default:
memory: 512Mi
cpu: 500m
defaultRequest:
memory: 256Mi
cpu: 100m
type: Container重要的线上利用改如何设置
节点资源有余时，会触发主动驱赶，将一些低优先级的 Pod 删除掉以开释资源让节点自愈。没有设置 request，limit 的 Pod 优先级最低，容易被驱赶；request 不等于 limit 的其次；request 等于 limit 的 Pod 优先级较高，不容易被驱赶。所以如果是重要的线上利用，不心愿在节点故障时被驱赶导致线上业务受影响，就倡议将 request 和 limit 设成统一。
怎么设置能力进步资源利用率
如果给给你的利用设置较高的 request 值，而理论占用资源长期远小于它的 request 值，导致节点整体的资源利用率较低。当然这对时延十分敏感的业务除外，因为敏感的业务自身不冀望节点利用率过高，影响网络包收发速度。所以对一些非核心，并且资源不长期占用的利用，能够适当缩小 request 以进步资源利用率。
如果你的服务反对程度扩容，单正本的 request 值个别能够设置到不大于 1 核，CPU 密集型利用除外。比方 coredns，设置到 0.1 核就能够，即 100m。
尽量避免应用过大的 request 与 limit
如果你的服务应用单正本或者大量正本，给很大的 request 与 limit，让它调配到足够多的资源来撑持业务，那么某个正本故障对业务带来的影响可能就比拟大，并且因为 request 较大，当集群内资源分配比拟碎片化，如果这个 Pod 所在节点挂了，其它节点又没有一个有足够的残余可分配资源可能满足这个 Pod 的 request 时，这个 Pod 就无奈实现漂移，也就不能自愈，减轻对业务的影响。
相同，倡议尽量减小 request 与 limit，通过减少正本的形式来对你的服务撑持能力进行程度扩容，让你的零碎更加灵便牢靠。
防止测试 namespace 耗费过多资源影响生产业务
若生产集群有用于测试的 namespace，如果不加以限度，可能导致集群负载过高，从而影响生产业务。能够应用 ResourceQuota 来限度测试 namespace 的 request 与 limit 的总大小。
示例:
apiVersion: v1
kind: ResourceQuota
metadata:
name: quota-test
namespace: test
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！