Kubernetes 1.2 新功能介绍:自动扩容算法

自动扩容算法

20160721144800

算法描述


autoscaler(自动扩容器)的实现方式是一个循环,它通过定期通过Status.PodSelector来查询Pods的状态,获得他们的CPU使用率。然后,它通过现有Pods的CPU使用率的算数平均值跟目标使用率进行比较,并且在扩容的时候,还要遵循预先设定的副本数限制:MinReplicas <= Replicas <= MaxReplicas(MinReplicas是用户预先设置的最小副本数,MaxReplicas是用户预先设置的最大副本数)

定期轮询的时间通过–horizontal-pod-autoscaler-sync-period选项来设置,默认的时间为30秒。

CPU利用率是指最近的Pod使用量(最近一分钟的平均值,从heapster中获得)除以设定的每个Pod的CPU使用率限额,在kubernetes1.1版本中,CPU的使用率直接从Heapster中获得,将来,我们将从Master提供的API中获得。

计算扩容后Pod的个数计算公式:

TargetNumOfPods = ceil(sum(CurrentPodsCPUUtilization) / Target)

ceil()为取整操作,表示取大于或等于某数的最近一个整数;

sum为算术求和操作;

CurrentPodsCPUUtilization为最近一分钟内某个Pod的CPU使用率/量的平均值;

Target为CPU使用上限。

算法说明


整个自动扩容的流程是:

1、创建HPA资源,设定目标CPU使用率限额,以及最大、最小实例数

2、收集一组中(PodSelector)每个Pod最近一分钟内的CUP使用率,并计算平均值

3、读取HPA中设定的CPU使用限额

4、计算:平均值之和/限额,求出目标调整的实例个数

5、目标调整的实例数不能超过1中设定的最大、最小实例数,如果没有超过,则扩容;超过,则扩容至最大的实例个数

5、默认情况每隔30秒做一次自动扩容判断

举例说明:

假设我们一组Pod中有三个实例,CPU限额为50%,当前的CPU使用率/量分别为:60%, 80%, 80%时,要扩容成多少实例呢?

(60%+80%+80%)/50% =4.4,4.4取整后为4,即应该扩容到4个实例。

附加说明


启动、停止Pod可能会引入噪声度量(例如,启动过程会暂时增加cpu的使用),所以,在每次起/停操作后,自动扩容器会等待一段时间(冷却时间),以获得更可靠的数据。扩容每次要冷却3分钟之后才能再次扩容,缩容要冷却5分钟。在实际的生产环境,缩容是的需求不是紧迫的,所以扩容要比缩容敏感,缩容还涉及资源可抢占的问题,我们将在以后的文章中讨论。

只有avg(CurrentPodsConsumption) / Target小于90%或者d大于110%时才会触发扩容或缩容,避免频繁扩容、缩容造成颠簸。

为什么选择相对度量(比率)


为了简便,我们选用了相对度量(90%的CPU资源)而不是0.6个CPU core来描述扩容、缩容条件。如果我们选择使用绝对度量,用户需要保证目标(限额)要比请求使用的低,否则,过载的Pod未必能够消耗那么多,从而自动扩容永远不会被触发:假设我们设置CPU为1个核,那么这个pod只能使用1个核,可能Pod在过载的情况下也不能完全利用这个核,所以扩容不会发生。在我们修改申请资源的时候,还有同时调整扩容的条件,比如将1个core变为1.2core,那么扩容条件应该同步改为1.2core,真是太麻烦了,与我们的自动扩容的目标相悖。

推荐阅读:

Kubernetes 1.2 新功能介绍:Ingress 原理及实例

Kubernetes 1.2 新功能介绍:Deployment

Kubernetes 1.2 新功能介绍:Limit Range和Resource Quota

Kubernetes 1.2 新功能介绍:ConfigMap

Kubernetes 1.2 新功能介绍:自动扩容算法

K8S中文社区微信公众号
分享到:更多 ()