Kubernetes 服务部署最佳实践(一) ——如何更好地设置 Request 与 Limit

如何为容器配置 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

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！