精华内容
下载资源
问答
  • 弹性伸缩是 Kubernetes

    2019-07-19 10:07:00
    传统弹性伸缩的困境 弹性伸缩是 Kubernetes 中被大家关注的一大亮点,在讨论相关的组件和实现方案之前。首先想先给大家扩充下弹性伸缩的边界与定义,传统意义上来讲,弹性伸缩主要解决的问题是容量规划与实际负载的...

      传统弹性伸缩的困境
      
      弹性伸缩是 Kubernetes 中被大家关注的一大亮点,在讨论相关的组件和实现方案之前。首先想先给大家扩充下弹性伸缩的边界与定义,传统意义上来讲,弹性伸缩主要解决的问题是容量规划与实际负载的矛盾。
      
      如上图所示,蓝色的水位线表示集群的容量随着负载的提高不断的增长,红色的曲线表示集群的实际的负载真实的变化。而弹性伸缩要解决的就是当实际负载出现激增,而容量规划没有来得及反应的场景。
      
      常规的弹性伸缩是基于阈值的,通过设置一个资源缓冲水位来保障资源的充盈,通常 15%-30% 左右的资源预留是比较常见的选择。换言之就是通过一个具备缓冲能力的资源池用资源的冗余换取集群的可用。
      
      这种方式表面上看是没有什么问题的,确实在很多的解决方案或者开源组件中也是按照这种方式进行实现的,但是当我们深入的思考这种实现方案的时候会发现,这种方式存在如下三个经典问题。
      
      1. 百分比碎片难题
      
      在一个 Kubernetes 集群中,通常不只包含一种规格的机器,针对不同的场景、不同的需求,机器的配置、容量可能会有非常大的差异,那么集群伸缩时的百分比就具备非常大的迷惑性。假设我们的集群中存在 4C8G 的机器与 16C32G 的机器两种不同规格,对于 10% 的资源预留,这两种规格是所代表的意义是完全不同的。
      
      特别是在缩容的场景下,通常为了保证缩容后的集群不处在震荡状态,我们会一个节点一个节点或者二分法来缩容节点,那么如何根据百分比来判断当前节点是处在缩容状态就尤为重要,此时如果大规格机器有较低的利用率被判断缩容,那么很有可能会造成节点缩容后,容器重新调度后的争抢饥饿。如果添加判断条件,优先缩容小配置的节点,则有可能造成缩容后资源的大量冗余,最终集群中可能会只剩下所有的巨石节点。
      
      2. 容量的规划炸弹
      
      还记得在没有使用容器前,是如何做容量规划的吗?一般会按照应用来进行机器的分配,例如,应用 A 需要 2 台 4C8G 的机器,应用 B 需要 4 台 8C16G 的机器,应用 A 的机器与应用 B 的机器是独立的,相互不干扰。到了容器的场景中,大部分的开发者无需关心底层的资源了,那么这个时候容量规划哪里去了呢?
      
      在 Kubernetes 中是通过 Request 和 Limit 的方式进行设置,Request 表示资源的申请值,Limit 表示资源的限制值。既然 Request 和 Limit 才是容量规划的对等概念,那么这就代表着资源的实际计算规则要根据 Request 和 Limit 才更加准确。而对于每个节点预留资源阈值而言,很有可能会造成小节点的预留无法满足调度,大节点的预留又调度不完的场景。
      
      3. 资源利用率困境
      
      集群的资源利用率是否可以真的代表当前的集群状态呢?当一个 Pod 的资源利用率很低的时候,不代表就可以侵占它所申请的资源。在大部分的生产集群中,资源利用率都不会保持在一个非常高的水位,但从调度来讲,资源的调度水位应该保持在一个比较高的水位。这样才能既保证集群的稳定可用,又不过于浪费资源。
      
      如果没有设置 Request 与 Limit,而集群的整体资源利用率很高这意味着什么?这表示所有的 Pod 都在被以真实负载为单元进行调度,相互之间存在非常严重的争抢,而且简单的加入节点也丝毫无法解决问题,因为对于一个已调度的 Pod 而言,除了手动调度与驱逐之外没有任何方式可以将这个 Pod 从高负载的节点中移走。那如果我们设置了 Request 与 Limit 而节点的资源利用率又非常高的时候说明了什么呢?很可惜这在大部分的场景下都是不可能的,因为不同的应用不同的负载在不同的时刻资源的利用率也会有所差异,大概率的情况是集群还没有触发设置的阈值就已经无法调度 Pod 了。
      
      弹性伸缩概念的延伸import lombok.RequiredArgsConstructor;
    import lombok.extern.slf4j.Slf4j www.feishenbo.cn;
    import org.springframework.beans.BeanUtils;
    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.cloud.client.ServiceInstance;
    import org.springframework.cloud.client.discovery.DiscoveryClient;
    import org.springframework.http.ResponseEntity;
    import org.springframework.stereotype.Service;
    import org.springframework.web.client.RestTemplate;

    import java.util.List;
    import java.util.concurrent.ThreadLocalRandom;
    import java.util.stream.Collectors;

    @Slf4j
    @Service
    @RequiredArgsConstructor(www.jmaguojiyL.com onConstructor = @www.chuangyyuLe.com__(@Autowired))
    public class ShareService {
    private www.chuangyyuLe.com final ShareMapper shareMapper;
    private final RestTemplate restTemplate;

    public ShareDTO findById(Integer id) {
    // 获取分享详情
    Share share = this.shareMapper.selectByPrimaryKey(id);
    // 发布人id
    Integer userId = share.getUserId();

    UserDTO userDTO = this.restTemplate.getForObject(
    "http://user-center/users/{userId}",
    UserDTO.class, userId
    );

    ShareDTO shareDTO = new ShareDTO(www.dongfangyuld.com);
    // 消息的装配
    BeanUtils.www.tdcqpt.cn copyProperties(share, shareDTO);
    // shareDTO.setWxNickname(userDTO.getWxNickname());
      
      既然基于资源利用率的弹性伸缩有上述已知的三个问题,有什么办法可以来解决呢?随着应用类型的多样性发展,不同类型的应用的资源要求也存在越来越大的差异。弹性伸缩的概念和意义也在变化,传统理解上弹性伸缩是为了解决容量规划和在线负载的矛盾,而现在是资源成本与可用性之间的博弈。如果将常见的应用进行规约分类,可以分为如下四种不同类型:
      
      1. 在线任务类型
      
      比较常见的是网站、API 服务、微服务等常见的互联网业务型应用,这种应用的特点是对常规资源消耗较高,比如 CPU、内存、网络 IO、磁盘 IO 等,对于业务中断容忍性差。
      
      2. 离线任务类型
      
      例如大数据离线计算、边缘计算等,这种应用的特点是对可靠性的要求较低,也没有明确的时效性要求,更多的关注点是成本如何降低。
      
      3. 定时任务类型
      
      定时运行一些批量计算任务是这种应用的比较常见形态,成本节约与调度能力是重点关注的部分。
      
      4. 特殊任务类型
      
      例如闲时计算的场景、IOT 类业务、网格计算、超算等,这类场景对于资源利用率都有比较高的要求。
      
      单纯的基于资源利用率的弹性伸缩大部分是用来解决第一种类型的应用而产生的,对于其他三种类型的应用并不是很合适,那么 Kubernetes 是如何解决这个问题的呢?
      
      Kubernetes 的弹性伸缩布局
      
      Kubernetes 将弹性伸缩的本质进行了抽象,如果抛开实现的方式,对于不同应用的弹性伸缩而言,该如何统一模型呢? Kubernetes 的设计思路是将弹性伸缩划分为保障应用负载处在容量规划之内与保障资源池大小满足整体容量规划两个层面。简单理解,当需要弹性伸缩时,优先变化的应该是负载的容量规划,当集群的资源池无法满足负载的容量规划时,再调整资源池的水位保证可用性。而两者相结合的方式是无法调度的 Pod 来实现的,这样开发者就可以在集群资源水位较低的时候使用 HPA、VPA 等处理容量规划的组件实现实时极致的弹性,资源不足的时候通过 Cluster-Autoscaler 进行集群资源水位的调整,重新调度,实现伸缩的补偿。两者相互解耦又相互结合,实现极致的弹性。
      
      在 Kubernetes 的生态中,在多个维度、多个层次提供了不同的组件来满足不同的伸缩场景。如果我们从伸缩对象与伸缩方向两个方面来解读 Kubernetes 的弹性伸缩的话,可以得到如下的弹性伸缩矩阵。
      
      cluster-autoscaler: kubernetes 社区中负责节点水平伸缩的组件,目前处在 GA 阶段 (General Availability, 即正式发布的版本)。
      
      HPA: kubernetes 社区中负责 Pod 水平伸缩的组件,是所有伸缩组件中历史最悠久的,目前支持 autoscaling/v1、 autoscaling/v2beta1 与 autoscaling/v2beta2, 其中 autoscaling/v1 只支持 CPU 一种伸缩指标,在 autoscaling/v2beta1 中增加支持 custom metrics,在 autoscaling/v2beta2 中增加支持 external metrics。
      
      cluster-proportional-autoscaler: 根据集群的节点数目,水平调整 Pod 数目的组件,目前处在 GA 阶段。
      
      vetical-pod-autoscaler: 根据 Pod 的资源利用率、历史数据、异常事件,来动态调整负载的 Request 值的组件,主要关注在有状态服务、单体应用的资源伸缩场景,目前处在 beta 阶段。
      
      addon-resizer: 根据集群中节点的数目,纵向调整负载的 Request 的组件,目前处在 beta 阶段。
      
      在这五个组件中, cluster-autoscaler、 HPA、 cluster-proportional-autoscaler 是目前比较稳定的组件,建议有相关需求的开发者进行选用。
      
      对于百分之八十以上的场景,我们建议客户通过 HPA 结合 cluster-autoscaler 的方式进行集群的弹性伸缩管理, HPA 负责负载的容量规划管理而 cluster-autoscaler 负责资源池的扩容与缩容。
      
      最后
      
      在本文中,和大家主要讨论的是在云原生时代下弹性伸缩概念的延伸,以及 Kubernetes 社区是如何通过解耦的方式通过多个转职的组件实现了两个维度的弹性伸缩,在本系列后面的文章中会为一一解析每个弹性伸缩组件的相关原理与用法。

    转载于:https://www.cnblogs.com/qwangxiao/p/11211568.html

    展开全文
  • 弹性伸缩AS

    2021-04-25 15:03:38
    了解弹性伸缩服务的概念,应用场景 掌握弹性伸缩(Auto Scaling)的功能,组成 掌握弹性伸缩(Auto Scaling)的基本操作 目录 AS的概念 弹性伸缩AS的概念 AS适合的场景 AS使用的功能限制 AS的配置 AS使用流程 ...

    1.弹性伸缩AS的概念

    为什么需要AS

    当一台服务器不能满足业务需求的时候,我们可以用多台服务器搭配SLB负载均衡来实现共同访问,对外提供服务。当服务器太多的时候,我们可以减少服务器数量来节省成本。可是呢,这样就带来几个问题:

    • 增减/减少后端服务器需要手动管理完成
    • 还需要实时关注业务状态或者预测业务需求量来决定什么时候增加/减少服务器,这都是增加了很多工作负担,而且这个预测业务需求访问量不一定准确

    为了解决这个问题,就有了AS弹性伸缩(Auto Scaling)

    弹性伸缩AS(Auto Scaling)的概念

    AS可以根据业务需求和策略来设置伸缩规则,自动调整后端服务器ECS的数量,在业务需求增长时自动增加ECS实例以保证计算能力,在业务需求下降时自动减少ECS实例以节约成本。不用用户手动管理后端服务器的数量,不用用户预判业务需求访问量来管理(增减/减少)后端服务器数量。AS调整后端服务器数量的依据规则有多种。

    1. 云监控服务器的状态:监控主机CPU使用情况等,如果伸缩组内ECS实例vCPU使用率平均值>80%,尝试添加ECS实例;如果伸缩组内ECS实例vCPU使用率平均值<30%,尝试移除ECS实例
    2. 定时:几点调整。后面会详细介绍

    弹性伸缩AS效果示例

    使用弹性伸缩需要提前设置触发弹性伸缩的条件。下图中,监控项为伸缩组内ECS实例的vCPU使用率平均值,并假设触发弹性扩展的阈值是80%,触发弹性收缩的阈值为30%。

    AS适合的场景

    AS对业务量不断波动的应用程序和业务量稳定的应用程序都适用,使用场景主要分为:弹性扩展,弹性收缩和弹性自愈

    1. 弹性扩张:当业务升级时,弹性伸缩会自动完成底层资源(ECS)升级,避免访问延迟和资源超负荷运行
    2. 弹性收缩:当业务需求下降时,弹性伸缩会自动完成底层资源(ECS)释放,避免造成资源浪费
    3. 弹性自愈:对业务量稳定的应用程序,可以用到弹性自愈:弹性伸缩提供健康检查功能,自动监控伸缩组内的ECS实例的健康状态,避免伸缩组内健康ECS实例低于设置的最小值

    AS的伸缩模式--AS如何实现伸缩

    弹性伸缩模式是指当我们使用弹性伸缩时,应该如何弹性伸缩。弹性伸缩模式包括以下几种:

    1. 定时模式:自定义自动伸缩发生的时间和频率,如每天13:00 增加ECS实例
    2. 动态模式:基于云监控性能指标如CPU利用率,自动增加或减少ECS实例
    3. 固定数量模式:通过设置最小实例数MinSize,即健康运行的ECS实例最小数量,以保证可用性
    4. 自定义模式:通过API调用自有监控系统,可以执行手动伸缩。
      1. 手工执行伸缩规则
      2. 手工添加或移除既有的ECS实例
      3. 自定义MinSize,MaxSize,弹性伸缩会自动创建或释放ECS实例,将当前ECS实例数量维持在MinSize与MaxSize之间
    5. 健康模式:如ECS实例为非Running状态,弹性伸缩将自动移除或释放不健康的ECS实例
    6. 多模式并行:以上所有模式都可以组合配置。

    每种模式分别适用于哪些场景?

    弹性伸缩AS的优势

    • 随需应变:根据需求恰到好处地分配资源
    • 自动化:无需人工干预,自动创建和释放ECS实例
    • 智能:智能调度云计算资源
    • 伸缩模式丰富:多模式兼容,可以同时配置多种模式

    2.弹性伸缩AS的组件

    AS的组件

    • 伸缩组:伸缩组是具有相同应用场景的ECS实例的集合。伸缩组定义了组内ECS实例数的最大值,最小值及其相关联的负载均衡实例和RDS实例等属性。伸缩组内最少最多可以有多少台ECS实例。
    • 伸缩配置:伸缩配置定义了用于弹性伸缩的ECS实例的配置信息,是伸缩组自动创建ECS实例时的模板,确定付费模式,实例,镜像(自定义镜像/共享镜像),公网IP,安全组,登陆凭证,伸缩配置名称等。
    • 伸缩规则:定义了具体的扩展或收缩操作,例如加入或移除N个ECS实例,增加还是减少。可以手动执行或者自动触发(按任务执行)
    • 伸缩活动:伸缩规则成功触发后,就会产生一条伸缩活动。伸缩活动主要用来描述伸缩组内ECS实例的变化情况
    • 伸缩触发任务:用于触发伸缩规则的任务,如定时任务,云监控的报警任务。
    • 冷却时间:在同一伸缩组内,一个伸缩活动执行完后的一段锁定时间。在这段锁定时间内,该伸缩组不执行其他的伸缩活动

    伸缩组包括伸缩配置,伸缩规则,伸缩互动。伸缩配置,伸缩规则,伸缩活动依赖伸缩组的生命周期管理,删除伸缩组的同时会删除与伸缩组相关联的伸缩配置,伸缩规则和伸缩活动。

    伸缩触发任务有定时任务,云监控报警任务等类型。伸缩触发任务不依赖于伸缩组

    1. 定时任务独立于伸缩组存在,不依赖于伸缩组的生命周期管理,删除伸缩组不会删除定时任务。
    2. 云监控报警任务独立于伸缩组存在,不依赖伸缩组的生命周期管理,删除伸缩组不会删除报警任务。

    生命周期挂钩

    生命周期挂钩是指:在伸缩组进行伸缩活动时,正在加入或正在移出伸缩组的实例将被挂钩挂起并置于等待状态。生命周期挂钩近在自动创建或移出ECS实例时生效手动添加或移出ECS实例时不受影响

    ECS被挂钩就是说ECS的生命周期来伸缩组的生命周期保持一致。在实例保持等待状态的时间内,当前伸缩组将具有以下特性:

    • 伸缩组不再运行其他的伸缩互动
    • 保留指定时长的操作时间,即挂钩的超时时间,可以在挂起期间执行自定义操作,例如,初始ECS实例配置或者获取ECS实例数据
    • 可以删除生命周期挂钩来恢复执行伸缩活动
    • 可以调用相关API来结束生命周期活动或者删除生命周期挂钩

    3.弹性伸缩AS的配置流程

    AS的配置步骤

    使用弹性伸缩AS,首先需要开通AS服务,然后按照以下步骤来使用弹性伸缩AS:创建伸缩组,创建伸缩配置,启用伸缩组,创建伸缩规则,创建定时任务,创建报警任务

    1.创建伸缩组

    创建伸缩组和伸缩配置是实现自动伸缩的第一步,伸缩组是具有相同应用场景的ECS实例的集合伸缩配置是伸缩组自动创建ECS实例时的模板,启动伸缩组必须给伸缩组添加伸缩配置,因为伸缩组需要根据伸缩配置(自定义镜像)来创建ECS。伸缩组的配置项如下

    • 伸缩组内实例模板的来源
      • 如果从0开始创建伸缩组,伸缩组创建完成后没有可用的伸缩配置来源,必须继续创建伸缩配置
      • 通过已有的ECS实例创建
      • 通过启动模板创建
    • 伸缩组基本信息
      • 伸缩组名称
      • 组内最大实例数
      • 最内最小实例数
    • 组内实例扩缩容配置的网络类型:创建伸缩配置时选择的实例规格的网络类型

    2.创建伸缩配置

    伸缩配置是伸缩组自动创建ECS实例时的模板,确定付费模式,实例,镜像(自定义镜像/共享镜像),公网IP,安全组,登陆凭证,伸缩配置名称等。

    • 付费模式:只能按量付费和抢占式实例,没有包年包月。弹性伸缩服务免费,但是加速伸缩组的ECS实例需要按云服务器ECS的定价支付费用
    • ECS实例规格
    • 镜像:自定义镜像或者共享镜像,实例启动后,系统盘将完整复制镜像的操作系统和应用数据
    • 公网IPv4,可选
    • 伸缩配置名称

    3.启用伸缩组

    启动伸缩组必须给伸缩组添加伸缩配置,因为伸缩组需要根据伸缩配置(包括自定义镜像的配置)来创建ECS

    4.创建伸缩规则

    伸缩规则是指增加还是减少ECS,可以手动执行或者自动触发(按任务执行)

    5.自动触发任务---定时任务

    自动触发任务可以自动执行伸缩规则

     6.自动触发任务---报警任务

    报警任务是按照监控的条件比如CPU使用率等 触发执行伸缩规则

    弹性伸缩AS的工作流程

    弹性伸缩AS的工作流程反应了AS怎么来增加或减少ECS实例的过程。创建好伸缩组,伸缩配置,伸缩规则,伸缩触发任务后,异常系统会自动化自行以下流程

    1. 伸缩触发任务会按照各自触发生效的条件来触发伸缩活动:伸缩触发任务包括 定时任务,自定义任务,健康检查任务和云监控任务
    2. 找到这个触发任务绑定的伸缩规则:系统自动通过ExecuteScalingRule接口触发伸缩活动,并在该接口中指定需要执行的伸缩规则的阿里云资源唯一标识符(Ari)
    3. 根据伸缩规则创建伸缩活动:根据步骤2传入的伸缩规则Ari(Rule Ari)获取伸缩规则,伸缩组,伸缩配置的相关信息,并创建伸缩活动
    4. 创建/移除ECS:在伸缩活动中,自动创建ECS实例并配置负载均衡和RDS
    5. 冷却:伸缩活动完成后,启动伸缩组的冷却功能。待冷却时间完成后,该伸缩组才能接收新的执行伸缩规则的请求。
      1. 频繁的触发伸缩活动会导致业务不稳定
      2. 冷却就是,当一个伸缩活动完成后,在冷却期内,不再自动触发下一次伸缩活动。
      3. 冷却期不限制手动触发

    弹性伸缩的报警任务

    弹性伸缩AS报警任务是弹性伸缩与云监控CMS深度合作,提供的一种动态管理伸缩组的方式,类似于弹性伸缩定时任务,弹性伸缩报警任务通过触发您指定的伸缩规则来执行伸缩活动,达到调整伸缩组内实例个数的目的。

    • 定时任务:在指定的时间执行指定的伸缩规则,当业务场景在时间上可预料时,能够提前做出响应,但是,在面对突发后者时间上不可预料的业务场景时,定时任务就显得捉襟见肘。
    • 报警任务:报警任务通过监控特定的监控指标,对数据指标进行实时的统计,当统计值满足您指定的报警条件时,触发报警任务,执行指定的伸缩规则。

    报警任务的创建流程

    报警任务包括系统监控项报警任务和自定义监控项报警任务。创建报警任务的流程如下:登录弹性伸缩控制台,单击自动触发任务管理->报警任务,单击创建报警任务,配置各项信息,完成

    4.弹性伸缩AS的计费和使用限制

    弹性伸缩AS的计费

    可以免费开通弹性伸缩服务。但是,如果弹性伸缩服务根据伸缩配置自动创建了ECS实例,或者手动添加了已有ECS实例,就需要为ECS实例支付费用。自动创建的ECS实例付费方式包括按量付费和抢占式实例:

    • 按量付费:按量付费是一种先使用后付费方式。使用这种方式,用户可以按需取用资源,随时开启和释放资源,无需提前购买大量资源
    • 抢占式实例:需要指定出价模式,当指定的实例规格当前市场价格低于出价时,就能成功创建抢占式实例,并按当前市场价格计费。抢占式实例创建成功后,操作与按量付费实例相同。
    • 弹性伸缩中没有包年包月!!!

    弹性伸缩AS的使用限制

    1. 部署在伸缩组内的ECS实例上应用必须是无状态并且可横向扩展的应用
      • 无状态:一次性的,数据发送完了就完事了。有10个窗口,找任意一个窗口都可以
      • 有状态:频繁交换一些数据,比如我在一个窗口办了一个业务,办了一半,想回去接着办。
    2. 伸缩组内ECS实例可能会被释放,因此不适合保存应用状态信息和相关数据等,比如会话记录,应用数据,日志等信息
    3. 弹性伸缩不支持自动将ECS实例添加到Memcache实例的访问白名单,需要自行添加。如果AS+SLB/RDS,那么新加的ECS实例会自动加入SLB/RDS,但是Memcache不行
    4. AS只能调整服务器的数量:无法纵向扩展,纵向扩展是指自动提升或降低ECS实例服务器的vCPU,内存,带宽等配置;弹性伸缩只能支持横向扩展,比如增加ECS服务器的数量。
    5. 能创建的伸缩组,伸缩配置,伸缩规则等有一定限制
    6. AS本身没有负载均衡的能力,AS只能调整ECS的数量。AS+SLB才能实现自动调整ECS服务器数量和负载均衡
    7. AS创建的ECS服务器需要使用自定义镜像,默认创建的ECS是空白的,不能提供用户需要的业务需求;用户在某台ECS上配置好业务服务,根据这台ECS创建自定义镜像,把这个镜像提供给AS创建ECS使用

    总结

    目标-ACA

    1. 了解弹性伸缩AS的概念
    2. 理解AS的使用场景

    目标-ACP

    1. 了解弹性伸缩服务的概念,应用场景
    2. 掌握弹性伸缩(Auto Scaling)的功能,组成
    3. 掌握弹性伸缩(Auto Scaling)的基本操作

    总结-ACP

    1. 弹性伸缩的概念
    2. AS中的组件概念
    3. 弹性伸缩的配置流程
    4. 弹性伸缩的使用限制

    思考题-ACP

    1. 弹性伸缩中生命周期挂钩有什么作用?适用于何种场合?生命周期挂钩在实例保持等待的时间内,当前生命周期不再执行任何其他的收缩活动,可以保留指定时长的操作时间,可以手动删除生命周期挂钩等
    2. 如果ECS无法满足众多数量用户访问,弹性伸缩AS能否解决用户访问体验差的问题?会存在什么问题?答:弹性伸缩比较适合用户访问量有波动的情况,并且需要结合SLB才能解决这种情况下用户访问体验差的问题。如果用户访问量一直都很大,还是要用SLB才能解决问题。
    展开全文
  • 在上一篇文章Kubernetes 弹性伸缩全场景解析 (一):概念延伸与组件布局中,我们介绍了在 Kubernetes 在处理弹性伸缩时的设计理念以及相关组件的布局,在今天这篇文章中,会为大家介绍在 Kubernetes 中弹性伸缩最...

    前言

    在上一篇文章 Kubernetes 弹性伸缩全场景解析 (一):概念延伸与组件布局中,我们介绍了在 Kubernetes 在处理弹性伸缩时的设计理念以及相关组件的布局,在今天这篇文章中,会为大家介绍在 Kubernetes 中弹性伸缩最常用的组件 HPA(Horizontal Pod Autoscaler)。HPA 是通过计算 Pod 的实际工作负载进行重新容量规划的组件,在资源池符合满足条件的前提下,HPA 可以很好的实现弹性伸缩的模型。HPA 到目前为止,已经演进了三个大版本,本文将会为大家详细解析 HPA 底层的原理以及在 Kubernetes 中弹性伸缩概念的演变历程。

    HPA 基本原理

    HPA 是根据实际工作负载水平伸缩容器数目的组件,从中可以提炼出两个非常重要的关键字:负载数目。我们可以用一个非常简单的数学公式进行归纳:


    下面举一个实际例子进行上述公式的阐述。
    假设存在一个叫 A 的 Deployment,包含3个 Pod,每个副本的 Request 值是 1 核,当前 3 个 Pod 的 CPU 利用率分别是 60%、70% 与 80%,此时我们设置 HPA 阈值为 50%,最小副本为 3,最大副本为 10。接下来我们将上述的数据带入公式中:

    • 总的 Pod 的利用率是 60%+70%+80% = 210%;
    • 当前的 Target 是 3;
    • 算式的结果是 70%,大于50%阈值,因此当前的 Target 数目过小,需要进行扩容;
    • 重新设置 Target 值为 5,此时算式的结果为 42% 低于 50%,判断还需要扩容两个容器;
    • 此时 HPA 设置 Replicas 为 5,进行 Pod 的水平扩容。

    经过上面的推演,可以协助开发者快速理解 HPA 最核心的原理,不过上面的推演结果和实际情况下是有所出入的,如果开发者进行试验的话,会发现 Replicas 最终的结果是 6 而不是 5。这是由于 HPA 中一些细节的处理导致的,主要包含如下三个主要的方面:

    1. 噪声处理

    通过上面的公式可以发现,Target 的数目很大程度上会影响最终的结果,而在 Kubernetes 中,无论是变更或者升级,都更倾向于使用 Recreate 而不是 Restart 的方式进行处理。这就导致了在 Deployment 的生命周期中,可能会出现某一个时间,Target 会由于计算了 Starting 或者 Stopping 的 Pod 而变得很大。这就会给 HPA 的计算带来非常大的噪声,在 HPA Controller 的计算中,如果发现当前的对象存在 Starting 或者 Stopping 的 Pod 会直接跳过当前的计算周期,等待状态都变为 Running 再进行计算。

    1. 冷却周期

    在弹性伸缩中,冷却周期是不能逃避的一个话题,很多时候我们期望快速弹出与快速回收,而另一方面,我们又不希望集群震荡,所以一个弹性伸缩活动冷却周期的具体数值是多少,一直被开发者所挑战。在 HPA 中,默认的扩容冷却周期是 3 分钟,缩容冷却周期是 5 分钟。

    1. 边界值计算

    我们回到刚才的计算公式,第一次我们算出需要弹出的容器数目是 5,此时扩容后整体的负载是 42%,但是我们似乎忽略了一个问题:一个全新的 Pod 启动会不会自己就占用了部分资源?此外,8% 的缓冲区是否就能够缓解整体的负载情况?要知道当一次弹性扩容完成后,下一次扩容要最少等待 3 分钟才可以继续扩容。为了解决这些问题,HPA 引入了边界值 △,目前在计算边界条件时,会自动加入 10% 的缓冲,这也是为什么在刚才的例子中最终的计算结果为 6 的原因。

    HPA 的演进历程

    在了解了 HPA 的基本原理后,我们来聊一下 HPA 的演进历程,目前 HPA 已经支持了 autoscaling/v1autoscaling/v1beta1 和 autoscaling/v1beta2 三个大版本。大部分的开发者目前比较熟悉的是autoscaling/v1 的版本,这个版本的特点是只支持 CPU 一个指标的弹性伸缩,大致的 yaml 内容如下:

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

    接下来我们再来看一下 v2beta1 与 v2beta2 的 yaml,会发现里面支持的 metrics 类型增加了很多,结构也复杂了很多。

    apiVersion: autoscaling/v2beta1
    kind: HorizontalPodAutoscaler
    metadata:
      name: php-apache
      namespace: default
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: php-apache
      minReplicas: 1
      maxReplicas: 10
      metrics:
      - type: Resource
        resource:
          name: cpu
          target:
            kind: AverageUtilization
            averageUtilization: 50
      - type: Pods
        pods:
          metric:
            name: packets-per-second
          targetAverageValue: 1k
      - type: Object
        object:
          metric:
            name: requests-per-second
          describedObject:
            apiVersion: extensions/v1beta1
            kind: Ingress
            name: main-route
          target:
            kind: Value
            value: 10k
    ---
    apiVersion: autoscaling/v2beta2
    kind: HorizontalPodAutoscaler
    metadata:
      name: php-apache
      namespace: default
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: php-apache
      minReplicas: 1
      maxReplicas: 10
      metrics:
      - type: Resource
        resource:
          name: cpu
          target:
            type: Utilization
            averageUtilization: 50

    而这些变化的产生不得不提的是 Kubernetes 社区中对监控与监控指标的认识与转变。在 Kubernetes 中,有两个核心的监控组件 Heapster 与 Metrics Server。Heapster 是早期 Kubernetes 社区中唯一的监控组件,它所包含的功能很强大,通过采集 kubelet 提供的 metrics 接口,并支持监控数据的离线与归档。

    大致的架构图如上:source 的部分是不同的数据来源,主要是 kubelet 的 common api 与后来提供的 summary api;processor 的作用是将采集的数据进行处理,分别在 namespace 级别、cluster 级别进行聚合,并创建新的聚合类型的监控数据;sink 的作用是数据离线与归档,常见的归档方式包括 influxdb、kafka 等等。Heapster 组件在相当长时间成为了 Kubernetes 社区中监控数据的唯一来源,也因此有非常多的和监控相关的组件通过 Heapster 的链路进行监控数据的消费。但是后来,Kubernetes 社区发现了 Heapster 存在非常严重的几个问题:

    • 强大繁多的 Sink 由不同的 Maintainer 进行维护,50% 以上的 Heapster Issues 都是关于 Sink 无法使用的,而由于 Maintainer 的活跃度不同造成 Heapster 社区有大量的 issues 无法解决;
    • 对于开发者而言,监控数据的类型已经不再是 CPU、Memory 这么简单的几个指标项了,越来越多的开发者需要应用内或者接入层的监控指标,例如 ingress 的 QPS、应用的在线活跃人数等等。而这些指标的获取是 Heapster 无法实现的;
    • Prometheus 的成熟让 Heapster 的生存空间不断被挤压,自从 Prometheus 被 CNCF 收录为孵化项目,Heapster 的不可替代地位被正式移除。

    社区经过反思后,决定将监控的指标边界进行划分,分为 Resource、Custom 和 External 三种不同的 Metrics,而 Heapster(Metrics Server) 的定位就只关心 Resource 这一种指标类型。为了解决代码维护性的问题,Metrics Server 对 Heapster 进行了裁剪,裁剪后的架构如下:

    去掉了 Sink 的机制,并将调用方式改为标准的 API 注册的方式,这样的好处是既精简了核心代码的逻辑又提供了替代的可能,也就是说此时 Metrics Server 也是可以替代的,只要实现了相同的 API 接口,并注册到 API Server 上,就可以替代 Metrics Server。
     
    接下来我们解析一下三种不同的 Metrics 与使用的场景:

      API 注释
    Resource metrics.k8s.io Pod的资源指标,计算的时要除以Pod数目再对比阈值进行判断
    Custom custom.metrics.k8s.io Object: CRD等对象的监控指标,直接计算指标比对阈值
    Pods : 每个Pod的自定义指标,计算时要除以Pods的数目
    External external.metrics.k8s.io External:集群指标的监控指标,通常由云厂商实现

    其中 autoscaling/v2beta1 支持 Resource 与 Custom 两种指标,而 autoscaling/v2beta2 中增加了 External 的指标的支持。

    最后

    HPA 目前已经进入了 GA 阶段,在大体的功能上面不会进行过多的变化,目前社区的主要发力点在如何配置化的调整细节参数、丰富监控 adapter 的实现等等。在本文中,我们在概念上给大家介绍了 HPA 的一些原理以及发展的趋势,在下一篇文章中,我们会为大家讲解如何开启 v2beta1 与 v2beta2 的。


    原文链接
    本文为云栖社区原创内容,未经允许不得转载。

    展开全文
  • Kubernetes—弹性伸缩

    2019-12-11 14:50:09
    从传统意义上,弹性伸缩主要解决的问题是容量规划与实践负载的矛盾。 蓝色水位线表示集群资源容量随着负载的增加不断扩容,红色曲线表示集群资源实际负载变化。 弹性伸缩就是要解决当实际负载增大,而集群资源容量...

    从传统意义上,弹性伸缩主要解决的问题是容量规划与实践负载的矛盾。
    在这里插入图片描述
    蓝色水位线表示集群资源容量随着负载的增加不断扩容,红色曲线表示集群资源实际负载变化。
    弹性伸缩就是要解决当实际负载增大,而集群资源容量没来得及反应的问题。

    1、Kubernetes中弹性伸缩存在的问题

    常规的做法是给集群资源预留保障集群可用,通常20%左右。这种方式看似没什么问题,但放到Kubernetes中,就会发现如下2个问题。
    (1)机器规格不统一造成机器利用率百分比碎片化
    在一个Kubernetes集群中,通常不只包含一种规格的机器,假设集群中存在4C8G与16C32G两种规格的机器,对于10%的资源预留,这两种规格代表的意义是完全不同的。
    在这里插入图片描述

    特别是在缩容的场景下,为了保证缩容后集群稳定性,我们一般会一个节点一个节点从集群中摘除,那么如何判断节点是否可以摘除其利用率百分比就是重要的指标。此时如果大规则机器有较低的利用率被判断缩容,那么很有可能会造成节点缩容后,容器重新调度后的争抢。如果优先缩容小规则机器,则可能造成缩容后资源的大量冗余。

    (2)机器利用率不单纯依靠宿主机计算
    在前面的调度算法中可以看出,调度过程对于资源利用率来说并不是唯一标准,所以可能导致某些节点资源利用非常紧张,某些节点大量资源空闲

    2.弹性伸缩的概念

    不是所有的业务都存在峰值流量,越来越细分的业务形态带来更多成本节省和可用性之间的跳转。

    ①在线负载型:微服务、网站、API
    ②离线任务型:离线计算、机器学习
    ③定时任务型:定时批量计算

    不同类型的负载对于弹性伸缩的要求有所不同,在线负载对弹出时间敏感,离线任务对价格敏感,定时任务对调度敏感
    (1)在k8s集群中弹性伸缩的布局
    在 Kubernetes 的生态中,在多个维度、多个层次提供了不同的组件来满足不同的伸缩场景。
    有三种弹性伸缩:
    CA(Cluster Autoscaler):Node级别自动扩/缩容
    cluster-autoscaler组件
    HPA(Horizontal Pod Autoscaler):Pod个数自动扩/缩容
    VPA(Vertical Pod Autoscaler):Pod配置自动扩/缩容,主要是CPU、内存
    addon-resizer组件
    如果在云上建议 HPA 结合 cluster-autoscaler 的方式进行集群的弹性伸缩管理。
    (2)Node自动扩/缩容
    ① Cluster AutoScaler
    扩容:Cluster AutoScaler 定期检测是否有充足的资源来调度新创建的 Pod,当资源不足时会调用 Cloud Provider 创建新的 Node。
    在这里插入图片描述
    缩容:Cluster AutoScaler 也会定期监测 Node 的资源使用情况,当一个 Node 长时间资源利用率都很低时(低于 50%)自动将其所在虚拟机从云服务商中删除。此时,原来的 Pod 会自动调度到其他 Node 上面。
    在这里插入图片描述
    支持的云提供商:
    阿里云:https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/alicloud/README.md

    AWS https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md

    Azure: https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/azure/README.md

    ② Ansible扩容Node
    在这里插入图片描述

    1.触发新增Node
    2.调用Ansible脚本部署组件
    3.检查服务是否可用
    4.调用API将新Node加入集群或者启用Node自动加入
    5.观察新Node状态
    6.完成Node扩容,接收新Pod

    (3)PodPod自动扩容/缩容(HPA)

    Horizontal Pod Autoscaler(HPA,Pod水平自动伸缩),根据资源利用率或者自定义指标自动调整replication controller, deployment 或 replica set,实现部署的自动扩展和缩减,让部署的规模接近于实际服务的负载。HPA不适于无法缩放的对象,例如DaemonSet。
    在这里插入图片描述

    ①HPA基本原理
    在这里插入图片描述
    在弹性伸缩中,冷却周期是不能逃避的一个话题, 由于评估的度量标准是动态特性,副本的数量可能会不断波动。有时被称为颠簸, 所以在每次做出扩容缩容后,冷却时间是多少。
    在 HPA 中,默认的扩容冷却周期是 3 分钟,缩容冷却周期是 5 分钟。
    可以通过调整kube-controller-manager组件启动参数设置冷却时间:
    –horizontal-pod-autoscaler-downscale-delay :扩容冷却
    –horizontal-pod-autoscaler-upscale-delay :缩容冷却

    ②HPA的演进历程
    目前 HPA 已经支持了 autoscaling/v1、autoscaling/v1beta1和autoscaling/v1beta2 三个大版本 。
    目前大多数人比较熟悉是autoscaling/v1,这个版本只支持CPU一个指标的弹性伸缩。
    而autoscaling/v1beta1增加了支持自定义指标,autoscaling/v1beta2又额外增加了外部指标支持。
    而产生这些变化不得不提的是Kubernetes社区对监控与监控指标的认识认识与转变。从早期Heapster到Metrics Server再到将指标边界进行划分,一直在丰富监控生态。
    示例:

    apiVersion: autoscaling/v1
    kind: HorizontalPodAutoscaler
    metadata:
      name: php-apache
      namespace: default
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: php-apache
      minReplicas: 1
      maxReplicas: 10
      targetCPUUtilizationPercentage: 50
    
    apiVersion: autoscaling/v2beta1
    kind: HorizontalPodAutoscaler
    metadata:
      name: php-apache
      namespace: default
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: php-apache
      minReplicas: 1
      maxReplicas: 10
      metrics:
      - type: Resource
        resource:
          name: cpu
          target:
            kind: AverageUtilization
            averageUtilization: 50
      - type: Pods
        pods:
          metric:
            name: packets-per-second
          targetAverageValue: 1k
      - type: Object
        object:
          metric:
            name: requests-per-second
          describedObject:
            apiVersion: extensions/v1beta1
            kind: Ingress
            name: main-route
          target:
            kind: Value
            value: 10k
    
    apiVersion: autoscaling/v2beta2
    kind: HorizontalPodAutoscaler
    metadata:
      name: php-apache
      namespace: default
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: php-apache
      minReplicas: 1
      maxReplicas: 10
      metrics:
      - type: Resource
        resource:
          name: cpu
          target:
            type: Utilization
            averageUtilization: 50
    

    ③ 基于CPU指标缩放
    1、 Kubernetes API Aggregation
    基于CPU指标缩放
    在这里插入图片描述
    在 Kubernetes 1.7 版本引入了聚合层,允许第三方应用程序通过将自己注册到kube-apiserver上,仍然通过 API Server 的 HTTP URL 对新的 API 进行访问和操作。为了实现这个机制,Kubernetes 在 kube-apiserver 服务中引入了一个 API 聚合层(API Aggregation Layer),用于将扩展 API 的访问请求转发到用户服务的功能。

    当你访问 apis/metrics.k8s.io/v1beta1 的时候,实际上访问到的是一个叫作 kube-aggregator 的代理。而 kube-apiserver,正是这个代理的一个后端;而 Metrics Server,则是另一个后端 。通过这种方式,我们就可以很方便地扩展 Kubernetes 的 API 了。
    如果你使用kubeadm部署的,默认已开启。如果你使用二进制方式部署的话,需要在kube-APIServer中添加启动参数,增加以下配置:

    # vi /opt/kubernetes/cfg/kube-apiserver.conf
    --requestheader-client-ca-file=/opt/kubernetes/ssl/ca.pem \
    --proxy-client-cert-file=/opt/kubernetes/ssl/server.pem \
    --proxy-client-key-file=/opt/kubernetes/ssl/server-key.pem \
    --requestheader-allowed-names=kubernetes \
    --requestheader-extra-headers-prefix=X-Remote-Extra- \
    --requestheader-group-headers=X-Remote-Group \
    --requestheader-username-headers=X-Remote-User \
    --enable-aggregator-routing=true \
    

    #用的所有证书都是k8s二进制搭建的时候用的证书
    在设置完成重启 kube-apiserver 服务,就启用 API 聚合功能了。
    (4)部署 Metrics Server
    在这里插入图片描述
    Metrics Server是一个集群范围的资源使用情况的数据聚合器。作为一个应用部署在集群中。
    Metric server从每个节点上Kubelet公开的摘要API收集指标。
    Metrics server通过Kubernetes聚合器注册在Master APIServer中。

    # git clone https://github.com/kubernetes-incubator/metrics-server
    # cd metrics-server/deploy/1.8+/
    # vi metrics-server-deployment.yaml   # 添加2条启动参数   
    
    ...
          containers:
          - name: metrics-server
            image: lizhenliang/metrics-server-amd64:v0.3.1
            command:
            - /metrics-server
            - --kubelet-insecure-tls
            - --kubelet-preferred-address-types=InternalIP
    ...
    
     kubectl apply -f .
    

    可通过Metrics API在Kubernetes中获得资源使用率指标,例如容器CPU和内存使用率。这些度量标准既可以由用户直接访问(例如,通过使用kubectl top命令),也可以由集群中的控制器(例如,Horizontal Pod Autoscaler)用于进行决策。
    测试:

    kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes
    kubectl top node
    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: web
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nginx-php
      template:
        metadata:
          labels:
            app: nginx-php
        spec:
          containers:
          - image: lizhenliang/nginx-php
            name: java
            resources: 
               requests:
                 memory: "300Mi"
                 cpu: "250m"
    ---
    
    apiVersion: v1
    kind: Service
    metadata:
      name: web
    spec:
      ports:
      - port: 80
        protocol: TCP
        targetPort: 80
      selector:
        app: nginx-php
    
    apiVersion: autoscaling/v1
    kind: HorizontalPodAutoscaler
    metadata:
      name: web
    spec:
      maxReplicas: 5
      minReplicas: 1
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: web
      targetCPUUtilizationPercentage: 60
    

    scaleTargetRef:表示当前要伸缩对象是谁
    targetCPUUtilizationPercentage:当整体的资源利用率超过50%的时候,会进行扩容。
    开启压测:
    可以使用shell的死循环来多窗口发起请求,也可以使用apache带的ab压测工具,使用压测工具的话根据自己的情况来配置请求量跟并发量
    yum install httpd-tools
    ab -n 100000 -c 100 http://10.1.206.176/status.php
    可以写死循环多窗口
    while true ;do curl http://10.0.0.104/status.php;done
    这个ip是svc的ip
    kubectl get hpa
    可以实时看着hpa中的cpu
    kubectl get pod
    过段时间就可以发现pod个数变多了
    kubectl describe hpa web (可以查看事件信息来看到hpa是根据cpu利用率来进行扩容了)
    在这里插入图片描述
    关闭压测,过一会检查缩容状态。
    (5)autoscaling/v2beta2(多指标)
    为满足更多的需求, HPA 还有 autoscaling/v2beta1和 autoscaling/v2beta2两个版本。
    这两个版本的区别是 autoscaling/v1beta1支持了 Resource Metrics(CPU)和 Custom Metrics(应用程序指标),而在 autoscaling/v2beta2的版本中额外增加了 External Metrics的支持。
    kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml

    apiVersion: autoscaling/v2beta2
    kind: HorizontalPodAutoscaler
    metadata:
      name: web
      namespace: default
    spec:
      maxReplicas: 3
      metrics:
      - resource:
          name: cpu
          target:
            averageUtilization: 36
            type: Utilization
        type: Resource
      minReplicas: 1
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: web
    

    与上面v1版本效果一样,只不过这里格式有所变化。
    v2还支持其他另种类型的度量指标,:Pods和Object

    type: Pods
    pods:
      metric:
        name: packets-per-second
      target:
        type: AverageValue
        averageValue: 1k
    
    type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: networking.k8s.io/v1beta1
        kind: Ingress
        name: main-route
      target:
        type: Value
        value: 2k
    

    metrics中的type字段有四种类型的值:Object、Pods、Resource、External。
    Resource:指的是当前伸缩对象下的pod的cpu和memory指标,只支持Utilization和AverageValue类型的目标值。
    Object:指的是指定k8s内部对象的指标,数据需要第三方adapter提供,只支持Value和AverageValue类型的目标值。
    Pods:指的是伸缩对象Pods的指标,数据需要第三方的adapter提供,只允许AverageValue类型的目标值。
    External:指的是k8s外部的指标,数据同样需要第三方的adapter提供,只支持Value和AverageValue类型的目标值。

    # hpa-v2.yaml
    apiVersion: autoscaling/v2beta2
    kind: HorizontalPodAutoscaler
    metadata:
      name: web
      namespace: default
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: web
      minReplicas: 1
      maxReplicas: 10
      metrics:
      - type: Resource
        resource:
          name: cpu
          target:
            type: Utilization
            averageUtilization: 50
      - type: Pods
        pods:
          metric:
            name: packets-per-second
          target:
            type: AverageValue
            averageValue: 1k
      - type: Object
        object:
          metric:
            name: requests-per-second
          describedObject:
            apiVersion: networking.k8s.io/v1beta1
            kind: Ingress
            name: main-route
          target:
            type: Value
            value: 10k
    

    3.基于Prometheus自定义指标缩放

    在这里插入图片描述
    资源指标只包含CPU、内存,一般来说也够了。但如果想根据自定义指标:如请求qps/5xx错误数来实现HPA,就需要使用自定义指标了,目前比较成熟的实现是 Prometheus Custom Metrics。自定义指标由Prometheus来提供,再利用k8s-prometheus-adpater聚合到apiserver,实现和核心指标(metric-server)同样的效果。

    (1)部署Prometheus
    Prometheus(普罗米修斯)是一个最初在SoundCloud上构建的监控系统。自2012年成为社区开源项目,拥有非常活跃的开发人员和用户社区。为强调开源及独立维护,Prometheus于2016年加入云原生云计算基金会(CNCF),成为继Kubernetes之后的第二个托管项目。
    Prometheus 特点:
    多维数据模型:由度量名称和键值对标识的时间序列数据
    PromSQL:一种灵活的查询语言,可以利用多维数据完成复杂的查询
    不依赖分布式存储,单个服务器节点可直接工作
    基于HTTP的pull方式采集时间序列数据
    推送时间序列数据通过PushGateway组件支持
    通过服务发现或静态配置发现目标
    多种图形模式及仪表盘支持(grafana)
    Prometheus组成及架构:
    在这里插入图片描述
    Prometheus Server:收集指标和存储时间序列数据,并提供查询接口
    ClientLibrary:客户端库
    Push Gateway:短期存储指标数据。主要用于临时性的任务
    Exporters:采集已有的第三方服务监控指标并暴露metrics
    Alertmanager:告警
    Web UI:简单的Web控制台

    部署的话请看K8S部署Prometheus
    https://blog.csdn.net/weixin_45413603/article/details/103270629

    (2)部署 Custom Metrics Adapter
    但是prometheus采集到的metrics并不能直接给k8s用,因为两者数据格式不兼容,还需要另外一个组件(k8s-prometheus-adpater),将prometheus的metrics 数据格式转换成k8s API接口能识别的格式,转换以后,因为是自定义API,所以还需要用Kubernetes aggregator在主APIServer中注册,以便直接通过/apis/来访问。
    https://github.com/DirectXMan12/k8s-prometheus-adapter
    该 PrometheusAdapter 有一个稳定的Helm Charts,我们直接使用。
    先准备下helm环境:
    wget https://get.helm.sh/helm-v3.0.0-linux-amd64.tar.gz
    tar zxvf helm-v3.0.0-linux-amd64.tar.gz
    mv linux-amd64/helm /usr/bin/
    helm repo add stable http://mirror.azure.cn/kubernetes/charts
    helm repo update
    helm repo list
    部署prometheus-adapter,指定prometheus地址:
    helm install prometheus-adapter stable/prometheus-adapter --namespace kube-system --set prometheus.url=http://prometheus.kube-system,prometheus.port=9090

    kubectl get pods -n kube-system
    验证,确保适配器注册到APIServer:
    kubectl get apiservices |grep custom
    kubectl get --raw “/apis/custom.metrics.k8s.io/v1beta1”

    (3)基于QPS指标实践
    部署一个应用:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: metrics-app
      name: metrics-app
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: metrics-app
      template:
        metadata:
          labels:
            app: metrics-app
          annotations:
            prometheus.io/scrape: "true"
            prometheus.io/port: "80"
            prometheus.io/path: "/metrics"
        spec:
          containers:
          - image: lizhenliang/metrics-app
            name: metrics-app
            ports:
            - name: web
              containerPort: 80
            resources:
              requests:
                cpu: 200m
                memory: 256Mi
            readinessProbe:
              httpGet:
                path: /
                port: 80
              initialDelaySeconds: 3
              periodSeconds: 5
            livenessProbe:
              httpGet:
                path: /
                port: 80
              initialDelaySeconds: 3
              periodSeconds: 5
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: metrics-app
      labels:
        app: metrics-app
    spec:
      ports:
      - name: web
        port: 80
        targetPort: 80
      selector:
    app: metrics-app
    

    该metrics-app暴露了一个Prometheus指标接口,可以通过访问service看到:
    curl http://10.0.0.58/metrics
    在这里插入图片描述
    创建HPA策略:

    vim app.yaml
    apiVersion: autoscaling/v2beta2
    kind: HorizontalPodAutoscaler
    metadata:
      name: metrics-app-hpa 
      namespace: default
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: metrics-app
      minReplicas: 1
      maxReplicas: 10
      metrics:
      - type: Pods
        pods:
          metric:
            name: http_requests_per_second
          target:
            type: AverageValue
            averageValue: 800m   # 800m 即0.8个/秒
    

    这里使用Prometheus提供的指标测试来测试自定义指标(QPS)的自动缩放。
    (4)配置适配器收集特定的指标
    当创建好HPA还没结束,因为适配器还不知道你要什么指标(http_requests_per_second),HPA也就获取不到Pod提供指标。
    ConfigMap在default名称空间中编辑prometheus-adapter ,并seriesQuery在该rules: 部分的顶部添加一个新的:

    # kubectl edit cm prometheus-adapter -n kube-system
    apiVersion: v1
    kind: ConfigMap
    metadata:
      labels:
        app: prometheus-adapter
        chart: prometheus-adapter-v0.1.2
        heritage: Tiller
        release: prometheus-adapter
      name: prometheus-adapter
    data:
      config.yaml: |
        rules:
        - seriesQuery: 'http_requests_total{kubernetes_namespace!="",kubernetes_pod_name!=""}'
          resources:
            overrides:
              kubernetes_namespace: {resource: "namespace"}
              kubernetes_pod_name: {resource: "pod"}
          name:
            matches: "^(.*)_total"
            as: "${1}_per_second"
          metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[2m])) by (<<.GroupBy>>)'
    ...
    

    该规则将http_requests在2分钟的间隔内收集该服务的所有Pod的平均速率。
    需要删除一下adapter 因为这个容器不支持热加载confimap,得重新加载一下
    上面的配置加的也就是说根据promeSQL写的
    kubectl delete pod -n kube-system prometheus-adapter-77b7b4dd8b-2x5p6

    测试API:

    kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/*/http_requests_per_second"
    

    查看HPA状态

    kubectl get hpa
    kubectl describe hpa metrics-app-hpa
    

    小结:
    在这里插入图片描述
    通过/metrics收集每个Pod的http_request_total指标;
    prometheus将收集到的信息汇总;
    APIServer定时从Prometheus查询,获取request_per_second的数据;
    HPA定期向APIServer查询以判断是否符合配置的autoscaler规则;
    如果符合autoscaler规则,则修改Deployment的ReplicaSet副本数量进行伸缩。

    展开全文
  • 设计弹性伸缩架构

    2020-08-17 18:27:50
    在我们讨论弹性伸缩内容之前,我们先讨论下与之相关的知识点—什么是垂直扩展和水平扩展。 垂直扩展和水平扩展 垂直扩展是指提升单个节点的自身的处理能力,比如通过升级节点的CPU,内存等硬件,这种通过升级原
  • 谈谈弹性伸缩

    2016-11-11 11:14:00
    什么是弹性伸缩弹性伸缩(Elastic Scaling)是根据业务需求和策略,自动调整其弹性计算资源的管理服务,达到优化资源组合的服务能力。在业务量上升时增加计算能力,当业务量下降时减小计算能力,以此保障业务...
  • 在上一篇文章中,我们介绍了在Kubernetes在处理弹性伸缩时的设计理念以及相关组件的布局,在今天这篇文章中,会为大家介绍在Kubernetes中弹性伸缩最常用的组件HPA(Horizontal Pod Autoscaler)。HPA是通过计算Pod的...
  • 传统弹性伸缩的困境

    2019-07-19 10:06:00
    传统弹性伸缩的困境 弹性伸缩是 Kubernetes 中被大家关注的一大亮点,在讨论相关的组件和实现方案之前。首先想先给大家扩充下弹性伸缩的边界与定义,传统意义上来讲,弹性伸缩主要解决的问题是容量规划与实际负载的...
  • 云计算之弹性伸缩

    千次阅读 2019-04-11 21:02:02
    弹性伸缩是更具用户的业务需求和策略,自动调整其弹性计算资源的管理服务 弹性伸缩产品特点: 随需应变——根据需求“恰到好处”的分配资源,无需担心需求预测的准确性,无需担心突增的业务变化 自动化——...
  • 阿里云弹性伸缩服务入门介绍

    千次阅读 2019-08-25 11:44:15
    弹性伸缩服务(Elastic Scaling Service)是根据用户的业务需求和策略,自动调整其 弹性计算资源的管理服务。用户根据自己的业务需求自动调整其弹性计算资源,在满足 业务需求高峰增长时无缝地增加 ECS 实例,并在...
  • 在本系列的前三篇中,我们介绍了弹性伸缩的整体布局以及HPA的一些原理,HPA的部分还遗留了一些内容需要进行详细解析。在准备这部分内容的期间,会穿插几篇弹性伸缩组件的最佳实践。今天我们要讲解的是 cluster-...
  • 弹性伸缩这种功能,不是很多系统都已经实现了,我们直接用就行了吗,为什么还需要个指南呢。 因为。。。。我们先来看看都有哪些相关知识点吧。。。 弹性伸缩涉及到各种软硬件,各色调度平台,策略和系统,其本身...
  • K8S弹性伸缩简谈

    2020-08-11 11:07:24
    k8s 默认提供了多个服务粒度的弹性伸缩组件。主要有 VPA, addon resizer 和 HPA。 此外,各大云厂商也积极贡献提供了多种伸缩组件,例如阿里云提供的 cronHPA。 在服务粒度的伸缩中,依据执行触发时机不同,可分为...
  • 微服务弹性伸缩与负载均衡

    千次阅读 2018-02-08 17:40:59
    微服务弹性伸缩与负载均衡 微服务如何实现弹性伸缩 云帮的应用弹性伸缩有不同的层次、类型及形式,且进行伸缩操作对用户是无影响的,服务不会有任何的中断(平滑伸缩)。由于平台是基于容器技术的,因此伸缩的...
  • 在本系列的前三篇文章中,我们介绍了弹性伸缩的整体布局以及 HPA 的一些原理,HPA 的部分还遗留了一些内容需要进行详细解析。在准备这部分内容的期间,会穿插几篇弹性伸缩组件的最佳实践。今天我们要讲解的是cluster...
  • 容器服务弹性伸缩简介本小节将基于使用原理对容器服务弹性伸缩进行简要的描述。本实践基于K8s的业务集群运行在专有云上,对测试业务进行压力测试,主要基于以下三种产品和能力: 利用阿里云的云企业网专线打通专有...
  • 容器服务kubernetes弹性伸缩高级用法

    千次阅读 2018-09-19 09:54:09
    近期,阿里云容器服务kubernetes发布了cluster-autoscaler的支持,开发者可以通过页面简单快捷的配置节点的弹性伸缩,支持普通实例、GPU实例以及竞价实例帮助开发者实现架构弹性和运营成本之间的博弈。阿里云容器...
  • 一、弹性伸缩组聚合监控原理 采用openfalcon中集群聚合模块(aggregator)来实现对弹性伸缩组中的所有的主机进行查询某个Counter(如:cpu.busy)的最新值,使用”分子:$(Counter) 分母:$#”的配置方式来实现对弹性...
  • 导读:Kubernetes弹性伸缩系列文章为读者一一解析了各个弹性伸缩组件的相关原理和用法。本篇文章中,阿里云容器技术专家莫源将为你带来定时伸缩组件kubernetes-cronhpa-controller的相关介绍与具体操作,目前该组件...
  • 弹性伸缩具有应突发、省成本、自动化的业务价值。平台侧将各业务零散、闲置资源进行整合,形成一个大规模资源池,通过弹性调度、库存管控技术在公司运营成本和业务体感中寻求较好的平衡。本文将介绍美团...
  • Kubernetes30--弹性伸缩总结

    千次阅读 2018-12-20 10:55:27
    前面学习有关弹性伸缩的论文以及k8s HPA的源码,对于云计算中弹性伸缩有了一些认识,总结一下。 弹性伸缩简介    伸缩理论关注的问题主要是在面临超出现有集群最大承载能力的时候,如何通过调整集群的规模以...
  • 传统弹性伸缩的困境 弹性伸缩是 Kubernetes 中被大家关注的一大亮点,在讨论相关的组件和实现方案之前。首先想先给大家扩充下弹性伸缩的边界与定义,传统意义上来讲,弹性伸缩主要解决的问题是容量规划与实际负载的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 8,904
精华内容 3,561
关键字:

弹性伸缩原理是什么