Kubernetes设置服务Resource参考

一、为什么要设置Resource

Resource（Requests和Limits）设置不完整/不合理或者没有设置，主要会造成以下问题：

  1. 资源没有得到限制的情况下，同节点上其他Pod的性能、可用性可能会受到影响。并且存在节点OOM的风险，造成更大的影响
  2. 弹性伸缩（HPA、CA等）相关的策略难以实施

设置好Resource，能够将资源造成的风险缩小到工作负载自身，同时，也有利于节点规划，资源评估等。

二、Resource推荐值方案

为工作负载配置Requests和Limits根据服务的类型，需求，场景的不同而不同，没有固定的答案。
VPA中的Recommender组件能够提供工作负载的Requests值的设置建议，但是其设计是用来配合VPA其他组件对Pod的资源进行垂直动态调整的，官方也强调不应该把VPA和HPA一起使用。
因此，我们主要的方向就是通过获取工作负载一段时间内资源使用情况来计算推荐值。

2.1.设置Resource的一般性建议

  • 所有的容器都应该设置Requests值
    首先，Requests影响到Pod的调度，如果不配置Requests，调度器就不知道节点大概已经被分配多少资源出去，就容易造成调度不合理，节点的资源利用率不均
    其次，实施HPA的前提也是需要设置Requests值

  • Requests不应该设置太高或太低
    如果Requests设置得太高，实际的资源利用率远小于Requests值，会导致节点的整体资源利用率低。并且过高的Requests会增大因资源不足导致 无法调度 的概率。工作负载支持水平伸缩的情况下，可以尽量设置小的资源请求和限制，通过Pod数的调整来满足业务量需求，更加灵活可靠。
    如果Requests设置得太低，也会造成调度上的不合理。
    相对合理的结合资源使用量的平均数或者中位数进行分析设置。

  • 所有容器都应该设置内存 Limits值
    为了避免节点OOM带来比较大的影响，正常每个容器都要设置内存Limits值，将影响范围缩小到服务本身。如果因为业务、架构上的原因导致不好设置，进一步讨论解决方案。

  • 尽量设置CPU Limits值
    太小的Limits可能会造成服务的延迟。不设置Limits或者设置的值很大会带来过大的爆炸半径，节点上其他服务也会受到影响。
    内存的Limits比较明确，就是表明程序可用的最大内存，超过Limits就会引发OOM。
    CPU Limits指的是容器再每个CPU使用计量周期内可以使用的CPU时间上限。有时候从监控上看，CPU的usage没有达到Limits，也可能会出现被限流的情况。
    而相比于没有设置Limits，设置了之后，就有更高一点的概率会出现CPU被限流的情况，限流比频繁的情况下，可能业务上就会感知到延迟。
    CPU的Limits设置，最好经过压测验证。并且设置了CPU Limits，应当观察几次业务高峰期内，CPU的限流情况。
    因此，每个服务正常情况下建议设置CPU Limits，可以给得大一些。

2.2.Resource推荐值计算方式

以脚本自动获取的结果作为参考（默认的推荐值），结合人工梳理，整出合理的推荐值。

2.2.1.脚本自动获取推荐值计算方式

以下是一个给出推荐值比较通用的计算方式。对于一些特定的服务，另外考量，例如

  1. CPU密集型的服务
  2. 比较重要的服务
  3. 资源使用情况起伏很大的服务
  4. …
    最终设置的值，还是以人工确定为准。

有些服务的资源利用率非常小，如果最终计算的推荐值小于以下最小值，直接设定为最小值，例如：

  • CPU Requests最小值：10m
  • CPU Limits最小值：100m
  • 内存Requests最小值：32Mi
  • 内存Limits最小值：64Mi

Requests推荐值

  • 基本原则：Requests推荐设置贴近日常平峰期的实际使用率
  • 值计算方式：默认推荐为历史30天资源使用量的中位数/平均数 * 冗余系数（比如1.3），然后取其中较大者
  • 如果中位数/平均数和最大值差距很大的话，要观察历史资源使用趋势进行评估

Limits推荐值

  • 基本原则：Limits推荐值可以给大些
    • 内存的Limits不宜给太大，如果整体内存Limits超过节点内存总量很多，节点OOM的概率就更大
      • 比如节点内存有8G，如果有一个服务的Limits设置为4G并且2个Pod同时调度到该节点，假设这个服务发生异常内存暴涨，那么也可能会造成节点OOM
    • CPU的Limits可以给大一些，即使大部分负载同时CPU利用率都很高，整体超过了节点所能提供的资源，造成的影响没有节点OOM那么大。对于单个工作负载，CPU的Limits给高一点，有利于降低CPU限流的概率。
  • 计算方式：默认推荐为历史30天资源使用量最高值 * 冗余系数。当前先按以下标准计算出推荐值（冗余系数可根据使用量的梯度来设置，使用的越少，冗余系数越大）：
    • CPU冗余系数：4
    • 内存冗余系数：2

按上述方式计算，Requests或Limits推荐值值可能是非整数结果。取整的话便于观察和计算，推荐值按10的倍数向上取整（CPU单位是m，内存单位是Mi的情况下），例如 CPU Limits推荐值 122m，取130m。内存推荐值也可以按2^n来取值。

以【Workload的历史资源使用量 / replicas数】 作为推荐值的计算基数

  • 如果统计周期内replicas数有调整过，要以最高Replicas数量为准
  • 每个Pod的流量不都是均衡的，也要关注一下Pod的资源使用情况

2.2.2.人工确定推荐值

根据上述得到的记过，人工梳理，调整。

Refs