Docker（二十四）服务自动扩缩容算法和服务资源限制

wind-cold

服务自动扩缩容
　　最近更新时间：2018-03-27 13:02:28
　　 查看pdf
在这篇文章中：

• 　　简介
  
• 　　使用方法
  
• 　　伸缩算法
  
• 　　注意事项
  

简介
　　服务自动扩缩容功能（又称 HPA）可以根据实例（pod）CPU 利用率等指标自动扩展，缩减服务的实例数量。
　　需要注意的是，自动扩缩容功能对应后台 HPA 组件的版本是 v2alpha1，并不支持 1.4.6 版本的 Kubernetes 集群。
使用方法
　　有下面三个入口可以设置服务的自动扩缩容：

• 　　创建/更新服务时设置：
  
  
  
  
• 　　更新服务实例数量时设置：
  
  
  
  
• 　　最大实例数，最小实例数：自动扩缩容功能能够调整的 Pod 数目区间。
  
• 　　触发策略指标：自动伸缩功能依赖的策略指标。
  
• 　　CPU利用率：容器 CPU 使用量和 CPU 的 request 值比率。
  
• 　　内存利用率：容器内存使用量和内存的 request 值比率。
  
• 　　入带宽：POD 入带宽（Mb）。
  
• 　　出带宽：POD 出带宽（Mb）。
  

　　其中 CPU 利用率，内存利用率对应 Kubernetes 资源类指标；入带宽，出带宽对应 Kubernetes 自定义 Pod 类指标
　　如果需要使用资源类指标作为自动伸缩策略，需要在创建服务的时候设置容器对应的 request 值，否则不支持
伸缩算法
　　服务自动扩缩容后台组件会定期（30s）向腾讯云云监控拉取容器和 POD 的监控指标，然后根据该指标当前值，当前副本数和该指标目标值计算出目标副本数，然后以该目标副本数作为服务的期望副本数，达到自动伸缩的目的。 比如当前有 2 个实例， 平均 CPU 利用率为 90%，服务自动伸缩设置目标 CPU 为 60%， 则自动调整实例数量为：90% * 2 / 60% = 3 个。
　　如果用户设置了多个弹性伸缩指标，HPA 会依据各个指标，分别计算出目标副本数，然后取最大的一个作为最终目标副本数
注意事项

• 　　为容器设置 CPU Request；
  
• 　　策略指标目标设置合理，如设置 70% 给容器和应用，预留 30% 的余量；
  
• 　　保持 Pod 和 Node 健康（避免 Pod 频繁重建）；
  
• 　　保证用户请求的负载均衡；
  
• 　　HPA 在计算目标副本数时会有一个 10% 的波动因子，如果在波动范围内，HPA 并不会调整副本数目；
  
• 　　如果服务对应的deployment.spec.replicas值为0，弹性伸缩将不起作用；
  

服务资源限制设置
　　最近更新时间：2018-07-05 15:55:16
　　 查看pdf
在这篇文章中：

• 　　请求 ( Request ) 与 限制 ( Limit )
  
• 　　CPU 限制说明
  
• 　　内存限制说明
  
• 　　CPU 使用量 VS CPU 使用率
  
• 　　使用示例
  
• 　　服务资源限制推荐
  

请求 ( Request ) 与 限制 ( Limit )
　　Request：容器使用的最小资源需求，作为容器调度时资源分配的判断依赖。只有当节点上可分配资源量 >= 容器资源请求数时才允许将容器调度到该节点。但 Request 参数不限制容器的最大可使用资源值。
　　Limit： 容器能使用的资源最大值，设置为 0 表示使用资源无上限。

　　注意：
　　更多 Limit 和 Request 参数介绍，单击 查看详情。

CPU 限制说明
　　CPU 资源允许设置 CPU 请求和 CPU 限制的资源量，以核 ( U ) 为单位，允许为小数。

　　注意：

• 　　CPU Request 作为调度时的依据，在创建时为该容器在节点上分配 CPU 使用资源，称为 “已分配 CPU” 资源。
  
• 　　CPU Limit 限制容器 CPU 资源的上限，设置为 0 表示不做限制 ( CPU Limit >= CPU Request )。
  

内存限制说明
　　内存资源只允许限制容器最大可使用内存量。以 MiB 为单位，允许为小数。

　　注意：

• 　　由于内存资源为不可伸缩资源，在容器使用内存量超过内存 Request 时，容器就存在被 Kill 掉的风险。因此为了保证容器的正常运作限制 Request = Limit。
  
• 　　内存 Request ( = Limit ) 作为调度时的依据，在创建时为该容器在节点上分配内存使用资源，称为 “已分配内存” 资源。
  

CPU 使用量 VS CPU 使用率

　　注意：

• 　　CPU 使用量为绝对值，表示实际使用的 CPU 的物理核数，CPU 资源请求和 CPU 资源限制的判断依据都是 CPU 使用量。
  
• 　　CPU 使用率为相对值，表示 CPU 的使用量与 CPU 单核的比值 (或者与节点上总 CPU 核数的比值)。
  

使用示例
　　一个简单的示例说明 Request 和 Limit 的作用，测试集群包括 1 个 4U4G 的节点、已经部署的两个 Pod ( Pod1，Pod2 )，每个 Pod 的资源设置为（ CPU Requst，CPU Limit，Memory Requst，Memory Limit ）= ( 1U，2U，1G，1G )。( 1.0 G = 1000 MiB )
　　节点上 CPU 和内存的资源使用情况如下图所示：

　　已经分配的 CPU 资源为：1U (分配 Pod1 ) + 1U (分配 Pod2 ) = 2U，剩余可以分配的 CPU 资源为 2U。
　　已经分配的内存资源为：1G (分配 Pod1 ) + 1G (分配 Pod2 ) = 2G，剩余可以分配的内存资源为 2G。
　　所以该节点可以再部署一个 ( CPU Requst， Memory Requst ) =( 2U，2G )的 Pod 部署，或者部署 2 个 ( CPU Requst， Memory Requst ) = ( 1U，1G ) 的 Pod 部署。
　　在资源限制方面，每个 Pod1 和 Pod2 使用资源的上限为 ( 2U，1G )，即在资源空闲的情况下，Pod 使用 CPU 的量最大能达到 2U。
服务资源限制推荐
　　CCS会根据您当前容器镜像的历史负载来推荐request与limit值，使用推荐值会保证的您容器更加平稳的运行，大大减小出现异常的概率。
　　推荐算法：
　　我们首先会取出过去7天当前容器镜像分钟级别负载，并辅以百分位统计第95%的值来最终确定推荐的Request,Limit为Request的2倍。

• 　　
  

Request = Percentile(实际负载[7d],0.95)Limit = Request * 2　　如果当前的样本数量（实际负载）不满足推荐计算的数量要求，我们会相应的扩大样本取值范围，尝试重新计算，例如：去掉镜像tag,namespace,serviceName等筛选条件。如经过多次计算后同样未能得到有效值，则推荐值为空。
　　推荐值为空：
　　在使用过程中，会发现有部分值暂无推荐的情况，可能是由于以下几点造成：

• 　　当前数据并不满足计算的需求，我们需要待计算的样本数量（实际负载）大于1440个，即有一天的数据
  
• 　　推荐值小于您当前容器已经配置的Request或者Limit
  

　　注意：

• 　　由于推荐值是根据历史负载来计算的，原则上，容器镜像运行真实业务的时间越长，推荐的值越准确。
  
• 　　使用推荐值创建服务，有可能会因为集群资源不足造成容器无法调度成功，在保存时一定要确认当前集群的剩余资源。
  
• 　　推荐值是建议值，用户可以根据自己业务的实际情况做相应的调整。