自动扩容之Horizontal Pod Autoscaling(HPA)

我们通过手动执行kubectl scale命令,可以实现Pod扩容。但是,分布式系统要能够根据当前负载的变化情况自动触发水平扩展或缩容的行为,因为这一过程可能是频繁发生的、不可预料的,所以手动控制的方式是不现实的。

-

因此,在Kubernetes1.1版本中首次发布了这一重量级新特性-----Horizontal Pod Autoscaler。

-

Horizontal Pod Autoscaler简称HAP,意思是Pod横向自动扩容,与之前的RC、Deployment一样,也属于一种Kubernetes资源对象。通过追踪分析RC控制的所有目标Pod的负载来自动水平扩容,如果系统负载超过预定值,就开始增加Pod的个数,如果低于某个值,就自动减少Pod的个数。
目前,可以有以下两种方式作为Pod负载的度量指标:
1、CPU utilization percentageb,
2、应用程序自定义的度量指标,比如服务在每秒内的相应的请求数(TPS或QPS)。

-

CPU utilization percentage是一个算术平均值,即目标pod所有副本自身的CPU利用率的平均值。一个Pod自身的CPU利用率是该Pod当前CPU使用量除以它的Pod request的值。比如当我们定义一个Pod的pod request为0.4,而当前pod的cpu使用量为0.2,则使用率为50%。如此可以得出一个平均值,如果某一个时刻CPU utilization percentage超过80%,则意味着当前Pod副本不足以支撑接下来更多的请求,需要进行动态扩容。而当请求高峰时段过去后,Pod CPU利用率又会降下来,此时对应的Pod副本数应该自动减少到一个合理的水平。

-

CPU utilization percentage计算过程使用到的Pod的CPU使用量通常是1分钟的平均值。

条件

HPA通过定期(定期轮询的时间通过–horizontal-pod-autoscaler-sync-period选项来设置,默认的时间为30秒)通过Status.PodSelector来查询pods的状态,获得pod的CPU使用率。然后,通过现有pods的CPU使用率的平均值(计算方式是最近的pod使用量(最近一分钟的平均值,从heapster中获得)除以设定的每个Pod的CPU使用率限额)跟目标使用率进行比较,并且在扩容时,还要遵循预先设定的副本数限制:MinReplicas <= Replicas <= MaxReplicas。

-

计算扩容后Pod的个数:sum(最近一分钟内某个Pod的CPU使用率的平均值)/CPU使用上限的整数+1

流程

1、创建HPA资源,设定目标CPU使用率限额,以及最大、最小实例数
2、收集一组中(PodSelector)每个Pod最近一分钟内的CPU使用率,并计算平均值
3、读取HPA中设定的CPU使用限额
4、计算:平均值之和/限额,求出目标调整的实例个数
5、目标调整的实例数不能超过1中设定的最大、最小实例数,如果没有超过,则扩容;超过,则扩容至最大的实例个数

例外

考虑到自动扩展的决策可能需要一段时间才会生效,甚至在短时间内会引入一些噪声。例如当pod所需要的CPU负荷过大,从而运行一个新的pod进行分流,在创建过程中,系统的CPU使用量可能会有一个攀升的过程。所以,在每一次作出决策后的一段时间内,将不再进行扩展决策。对于ScaleUp而言,这个时间段为3分钟,Scaledown为5分钟。

-

HPA允许一定范围内的CPU使用量的不稳定,只有avg(CurrentPodsConsumption) / Target小于90%或者大于110%时才会触发扩容或缩容,避免频繁扩容、缩容造成颠簸。

为什么选择相对比率

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

下面是HPA定义的一个具体例子:

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: java-apache
  namespace: default
spec:
  minReplicas: 1
  maxReplicas: 10
  scaleTargetRef:
    kind: Deployment
    name: java-apache
  targetCPUUtilizationPercentage: 90

根据上面的定义,我们可以知道,这个HPA控制的目标对象为一个名叫java-apache的Deployment里的Pod副本,当这些Pod副本的CPUUtilizationPercentage的值超过90%时会触发自动动态扩容行为,扩容或缩容时必须满足的一个约束条件是Pod的副本数要介于1与10之间。

kubectl autoscale deployment java-apache --cpu-percent=90 --min=1 --max=10

原文地址:http://blog.51cto.com/2032872/2320651

时间: 2024-10-30 03:15:54

自动扩容之Horizontal Pod Autoscaling(HPA)的相关文章

Kubernetes Horizontal Pod Autoscaling

HPA介绍 Horizo??ntal Pod Autoscaler基于观察到的CPU利用率(或借助自定义指标 支持,基于其他一些应用程序提供的指标)自动缩放复制控制器,部署或副本集中的Pod数量 .请注意,自动伸缩不适用于无法缩放的对象,例如DaemonSets. Horizo??ntal Pod Autoscaler被实现为Kubernetes API资源和控制器.该资源确定控制器的行为.控制器会定期调整复制控制器或部署中副本的数量,以使观察到的平均CPU利用率与用户指定的目标相匹配. 简单的

Horizontal Pod Autoscaler(Pod水平自动伸缩)

Horizontal Pod Autoscaler 根据观察到的CPU利用率(或在支持自定义指标的情况下,根据其他一些应用程序提供的指标)自动伸缩 replication controller, deployment, replica set, stateful set 中的pod数量.注意,Horizontal Pod Autoscaling不适用于无法伸缩的对象,例如DaemonSets. Horizontal Pod Autoscaler 被实现作为Kubernetes API资源和控制器

Kubernetes -- Horizontal Pod Autoscaler

前言 在kubernetes中,我们使用pod对外提供服务.这时候,我们需要以下两种情形需要关注: pod因为不明原因挂掉,导致服务不可用 Pod在高负荷的情况下,不能支撑我们的服务 如果我们人工监控pods,人工进行调整副本那么这个工作量无疑是巨大的,但kubernetes已经有了相应的机制来应对了. 那么今天就来介绍一下在k8s 1.6中的弹性伸缩的实施 k8s是kubernetes的官方简称HPA全称Horizontal Pod Autoscaler HPA的原理 Kubernetes有一

Kubernetes高级进阶之pod的自动扩容/缩容

目录:实践1:基于autoscaling cpu指标的扩容与缩容实践2:基于prometheus自定义指标QPS的扩容与缩容 Pod自动扩容/缩容(HPA) Horizontal Pod Autoscaler(HPA,Pod水平自动伸缩),根据资源利用率或者自定义指标自动调整replication controller, deployment 或 replica set,实现部署的自动扩展和缩减,让部署的规模接近于实际服务的负载.HPA不适于无法缩放的对象,例如DaemonSet. HPA主要是

Kubernetes基本概念和术语之Deployment、Horizontal Pod Autoscaler和StatefulSet

1.Deployment Deployment是为了更好的解决Pod的编排问题才引入的,可以把它看作是RC的一次升级,最大的升级是我么可以看到Pod部署的进度. Deployment典型的使用场景如下: 创建一个Deployment对象来生成对应的Replica Set(相当于RC的进化版,kubernetes v1.2引入)并完成Pod副本的创建过程 检查Deployment的状态来看部署动作是否完成(Pod副本的数量是否达到预期值) 更新Deployment以创建新的Pod(如镜像升级) 若

ArrayList源码解析(二)自动扩容机制与add操作

目录 1.ArrayList的自动扩容机制 2.add操作 正文 本篇主要分析ArrayList的自动扩容机制,add和remove的相关方法. 作为一个list,add和remove操作自然是必须的. 前面说过,ArrayList底层是使用Object数组实现的.数组的特性是大小固定,这个特性导致的后果之一就是,当ArrayList中成员个数超过capacity后,就需要重新分配一个大的数组,并将原来的成员拷贝到新的数组之中. add操作前都需要保证capacity足够,因此扩容机制和add放

【LVM】LVM自动扩容脚本

当新增物理磁盘时,自动扩容到:/dev/vg0/data 例如,如下是原始的: [[email protected] ~]# pvs PV VG Fmt Attr PSize PFree /dev/sdb vg0 lvm2 a-- 10.00g 0 /dev/sdc vg0 lvm2 a-- 10.00g 0 [[email protected] ~]# vgs VG #PV #LV #SN Attr VSize VFree vg0 2 1 0 wz--n- 19.98g 0 [[email p

CentOS6、7 LVM逻辑卷分区自动扩容Shell脚本编程思路与实例

应用场景和已知存在的问题: 适用于CentOS6或CentOS7(可能适用于CentOS4或5等早些版本) 根文件系统(被扩展的文件系统)采用LVM进行管理,例如mount命令输出"/dev/mapper/vg_$hostname-lv_root on / type ext4 (rw)"中含有"mapper"关键词 自动扩容根文件系统,如果想扩展其他文件系统,例如有的业务应用数据目录不在根分区中,则需要修改Shell脚本代码中的VG_PATH_TO_EXTEND变量

C#深入研究ArrayList动态数组自动扩容原理

1 void Test1() 2 { 3 ArrayList arrayList = new ArrayList(); 4 int length = 3; 5 for (int i = 0; i < length; i++) 6 { 7 arrayList.Add("TestData"); 8 } 9 Console.WriteLine("count = " + arrayList.Count); 10 Console.WriteLine("capa