精华内容
下载资源
问答
  • 弹性伸缩是什么?它又在云计算中是如何工作的?
    2021-12-10 10:27:34

    云计算最大的优势就在于弹性

    云计算最大的优势就在于弹性。那这个弹性具体指哪些内容呢?

    一、计算弹性

    纵向的弹性,即单个服务器的配置变更。当您购买了云服务器或者存储的容量后,可以根据业务量的增长或者减少自由变更自己的配置。

    横向的弹性。对于游戏应用或直播平台出现的高峰期,可以使用弹性的方式帮助客户度过这样的高峰。当业务高峰消失时,您可以将多余的资源释放掉,以减少业务成本的开支。利用横向的扩展和缩减,配合云计算的弹性伸缩,完全可以做到定时定量的伸缩,或者按照业务的负载进行伸缩。

    二、存储弹性

    当存储量增多时,对于传统的IDC方案,您只能不断去增加服务器,而这样扩展的服务器数量是有限的。在云计算模式下,将为您提供海量的存储,当您需要时可以直接购买,为存储提供最大保障。

    三、网络弹性

    云上的网络也具有非常大的灵活性。只要您购买了专有网络,那么所有的网络配置与线下IDC机房配置可以是完全相同的,并且可以拥有更多的可能性。可以实现各个机房之间的互联互通,各个机房之间的安全域隔离,对于专有网络内所有的网络配置和规划都会非常灵活。

    总之,对于云计算的弹性而言,是计算的弹性、存储的弹性、网络的弹性以及对于业务架构重新规划的弹性。

    下载 (4)

    接下来我们看些应用案例:

    案例一

    2009年,第一次淘宝双十一活动,每秒订单只有400笔,支付达到极限每秒200笔。 2015年淘宝双十一,每秒订单创建24万笔,支付达到了每秒18.59万笔。

    每秒订单提升了350倍,支付能力提升了430倍。从后台来看,每年淘宝在双十一这个时候,后台服务器的数量都要比平时运维要多三到四倍。来保障双十一活动,双十一活动结束后,假如不做处理,这批机器的利用率将大大降低,直到次年的双十一活动。

    案例二

    2016年除夕之夜“咻一咻”抢红包,全民参与3245亿次,最高峰值每分钟210亿次。每秒3.5亿次峰值。当活动结束后,后台大量的服务器将会处于限制的状态。

    如上述案例,这些闲置机器怎么处理,怎么回收,次年活动开始时,服务器如何分配,这是一个大问题。

    还有其他场景,比如视频直播公司, 无法预估 业务负载情况,需要根据CPU利用率,load、贷款利用率、自动线性伸缩。如游戏公司,每天中午12点,每天晚上6点到九点,这时候处于业务高峰期,需要定时扩容。

    以上 案例都用到了弹性计算。

    那什么是弹性伸缩呢?

    阿里云对弹性伸缩的定义是:根据用户的业务需求和策略,自动调整其弹性计算资源的管理服务。其能够在业务增长时自动增加 ECS 实例,并在业务下降时自动减少 ECS 实例。

    弹性伸缩产品特点:

    随需应变——根据需求“恰到好处”的分配资源,无需担心需求预测的准确性,无需担心突增的业务变化

    自动化——无需人工干预,自动创建和释放ESC实例。自动配置负载均衡SLB

    伸缩模式丰富——多模式兼容,课同时配置定时、动态、自定义、健康模式。

    智能——智能调节应对各种复杂场景,根据设定策略自动调整弹性资源。

    伸缩模式:

    ● 定时模式,固定时间增加或减少ECS

    ● 动态模式 ,根据CPU、带宽、等资源使用率增加减少ECS

    ● 固定数量模式,手动添加

    ● 健康模式,将不健康的服务器移除,加入健康的服务器

    ● 自定义模式。

    ● 多模式并行

    阿里云的弹性伸缩方案

    伸缩组创建

    伸缩组是具有相同应用场景的ECS实例的集合,伸缩组定义了组内ECS实例数的最大值、最小值及其相关的SLB实例和RDS实例等属性。

    弹性伸缩一定要搭配SLB、云监控、RDS才能使用吗? 答案是否定的

    冷却时间

    移出策略

    伸缩配置

    创建

    伸缩规则

    创建

    如果伸缩规则的执行会照成伸缩组的ECS实例数低于MinSIze或高于MaxSize时, 则ESS会自动调整需要加入或移除的ECS实例数,使之按照“将伸缩组的实例数调整到minSize”或调整到 MAXsize。

    流程

    定时任务

    每个用户最多能创建20个定时任务。

    自动扩展流程

    弹性伸缩的限制条件

    1、伸缩组内部署在ECS实例的应用必须无状态并且可横向扩展。

    2、弹性伸缩会自动释放ECS实例,所以建议伸缩组内ECS实例不要保存应用状态信息和相关数据等信息,例如会话记录(Session)、数据库或者日志等。若有需要,可以保存状态信息到独立的状态云服务器ECS,保存数据库到云数据库RDS或者集中日志存储到日志服务。

    3、弹性伸缩无法自动添加ECS实例到开放缓存Memcache实例访问白名单,需要您自行添加。

    4、弹性伸缩无法纵向扩展。即弹性伸缩无法自动升降ECS实例的vCPU规格、内存和带宽等配置。

    5、您能创建的伸缩组、伸缩配置、伸缩规则、ECS实例、定时任务有一定的限制数量。

    云计算正加速成为一种新的IT资源提供方式, 按 需所取、弹性分配的云计算方式也更加符合大多数企业的利益要求,企业将更加专注于自身核心竞争力的提升,摆脱维护IT底层信息技术的烦恼。随着人工智能、大数据及物联网等创新型应用在云计算基础上的爆发性发展,云计算的红利正在加速释放。

    更多相关内容
  • 弹性伸缩这种功能,不是很多系统都已经实现了,我们直接用就行了吗,为什么还需要个指南呢。 因为。。。。我们先来看看都有哪些相关知识点吧。。。 弹性伸缩涉及到各种软硬件,各色调度平台,策略和系统,其本身...

    0x0 pre
    弹性伸缩这种功能,不是很多系统都已经实现了,我们直接用就行了吗,为什么还需要个指南呢。
    因为。。。。我们先来看看都有哪些相关知识点吧。。。
    在这里插入图片描述

    弹性伸缩涉及到各种软硬件,各色调度平台,策略和系统,其本身就是一个较复杂的课题。此外,kubernetes 不单单是一个容器调度平台,而是一个活跃,庞大的生态系统。
    kubernetes 弹性伸缩这个课题涉及了诸多知识点,主要如下:

    - 水平(Horizontal)伸缩
    - 垂直(Vertical)伸缩
    - 定时(Scheduled)伸缩
    - 预测(Predictive)性伸缩
    - 服务画像
    - node
    - service
    - CA
    - cloudprovider
    - VPA
    - HPA
    - HPA controller
    - metric
    - metric server
    - heapster
    - metric state
    - prometheus
    - CRD
    - custom metric api
    - prometheus adapter
    - cronhpa controller
    - cloud controller manager
    

    在刚开始调研这个课题的时候,一上来看到这么多名词和术语,肯定会一脸懵逼的。终于,
    在知识的海洋中遨游了好一阵后,终于了摸索出一条路,爬上岸来。
    本文旨在为想在 kubernetes 中使用弹性伸缩功能
    的读者解释相关概念,并制定一条较为清晰的路线图。
    在这里插入图片描述

    0x1 autoscaling
    在画路线图之前,先来了解下弹性伸缩的基本概念。

    目的
    我们做工程都是结果导向的,就是说,我们做弹性伸缩,不是因为它看上去很酷,不是为了做弹性伸缩而做。
    而是从公司的实际问题出发,为了解决什么问题,以及投入产出比是否合理,才决定是否要做弹性伸缩,以及怎么做。
    一般来讲,弹性伸缩主要用来解决两个问题:

    应对突发流量
    节省资源
    

    应对突发流量。这点很好理解,当系统由于外界因素(比如 XXX 突然结婚了, XXX 突然离婚了等突发的热门话题),
    导致系统负载激增,原有的配置已无法满足需求,需要增加系统配置。这种增加可能是自动的,可能是需要手工调整的,
    甚至是需要去购买机器,重启服务等对服务比较不友好的行为。具体进行何种操作,需要以及目前公司的弹性伸缩级别来制定
    相应的计划。关于弹性伸缩的级别,我们将在稍后说明。

    节省资源。绝大多数情况下,我们不可能让我们的工作负载跑满服务器(即便能跑满,为了服务稳定性,我们也不大敢这么做)。
    在不损失服务稳定性的大前提下,尽可能地提高资源利用率,一直是各个弹性伸缩方案不懈的目标。减少单个服务资源占用,
    通过合理调度资源减少服务器数量,及时增减服务数量等手段,都能直接或间接的达到节省资源的目的。

    针对以上两种目的,我们可能设计出完全不同的弹性伸缩方案。
    例如,如果我们的需求是 在流量激增时能够在数分钟内为指定服务扩容,保证服务稳定可用,那么我们可能仅仅需要
    把服务迁移到容器环境中,并配置一个延迟较低的监控报警系统,在出问题时能够及时通知到运维人员,然后手动为服务扩容即可;
    如果服务器成本在公司所有成本中已经占了很大的比重,要在不影响业务的情况下尽可能地减少服务器开支,秒级伸缩,则我们需要
    从公司后端服务各个方面好好设计一番了。

    节点和服务
    节点是承载工作负载的单元,是集群中提供容器运行环境的一台机器(物理机或虚拟机)。
    服务是具体的工作负载,具体在 kubernetes 中,就是 pod 以及 pod 所包含的容器。
    kubernetes 上的弹性伸缩会在节点和服务两个粒度进行。

    两个粒度之间会相互影响。例如,应对突发流量时,如果出发了服务粒度的扩容操作,就会占用部分节点资源,
    如果碰巧扩容到一半时,集群所有资源都被用完了,那么此时只有节点也能进行自动扩容才能完成服务的扩容,
    否则会导致服务由于没有找到足够的资源而扩容失败。当然,现实情况中,我们一般不会等到集群资源完全用完
    时才去出发节点扩容。一般会在资源超过某个特定阈值(90-95%)时,就会出发扩容。

    同样,在使用缩容来节省资源时,只有将负载低的服务缩容后,才能空闲出一批利用率较低的节点,此时节点弹性伸缩器检测到
    某些节点利用率低,关闭这些节点,或是从云厂商取消续订这些节点,才能达到节省资源的最终目的。

    垂直伸缩与水平伸缩
    垂直(Vertical)伸缩:调整节点或服务的资源配额。

    水平(Horizontal)伸缩: 调整节点或服务的数量。

    弹性伸缩的级别
    借鉴业界对自动驾驶的分级规则,现定义服务的弹性伸缩级别如下:
    在这里插入图片描述

    level 0
    系统还处在比较原始的阶段,服务不支持任何形式的扩容缩容。

    level 1
    系统直接跑在自己维护的虚拟机或物理机上,能够通过人工增加减少机器数量来实现扩缩容。
    此种方式的通常方案是在服务上层搭建一个负载均衡,然后在增加、减少机器时使负载均衡感知。
    这种方式扩缩容的时间通常较长,几分钟到几小时不等。

    level 2
    服务已经容器化
    有一套标准的容器调度管理平台(mesos/kubernetes)
    有一套完整的监控数据(prometheus/zabbix/open-falcon/ELK)
    由于容器的启动速度比虚拟机和物理机要快很多,所以容器化后,可以将扩容速度提高很多倍,能够达到秒级至分钟级。

    level 3
    由于 level 2 中我们已经有个各个维度的监控数据,在此基础之上,可以做一些自动化策略来减少人工操作的时间,
    能够将扩容速度稳定在秒级。

    level 4
    在弹性伸缩的级别中,自动缩容的等级(4)要比自动扩容(3)高一级,主要从两个方面考虑:

    1.从公司发展角度来看,肯定是先跑起来 --> 抗住大流量 --> 精细化控制成本。
    如果温饱问题都还没有解决, 公司生死存亡的问题都还没解决, 就去考虑节约成本,显然是没有抓对发展的大方向。

    2.从实现的技术难度来讲,缩容要考虑的细节要多一些。比如扩容时由于都是添加资源和服务,较容易做到业务无感知。
    但是在缩容时,如果想做到业务无感知,可能需要结合网关、负载均衡、部署策略、服务优雅关闭、服务发现、
    容器生性周期管理等多方面的知识才能实现。

    此外,在制定弹性伸缩策略时,业界通常会采用 激进的扩容,谨慎的缩容 的大方针来最大限度地保障服务的稳定性。

    level 5
    level 3 和 level 4 虽说已经实现了秒级的弹性伸缩,但是他们都是被动式的,换句话说,只能在事情发生后,
    再进行扩缩容。这样做可能会导致出现少量的请求超时或请求出错。一种更优雅的方案是在出现问题前,预先准备好充足的资源,
    避免问题的发生,前置性地进行伸缩。

    level 5 周期性的弹性伸缩是指基于对历史数据和公司、服务业务的资源用量波峰波谷的周期性规律的总结,定时对服务和集群
    规模进行扩缩容。

    例如如果公司主要业务是一款公交出行类软件,那么很显然每天的早晚上班期间是公司业务的高峰,且流量是闲时流量的数倍。该公司
    可以指定一个定时伸缩策略,每天早晨 5 点将集群规模扩大 x 倍,xx 业务规模扩大 y 倍,11 点再缩容至原规模,下午 4 点再进行扩容,
    以此类推。level 5 的弹性伸缩的实现,依赖于 level 3 和 level 4 对基础设施和中间件的优化与改造,只有在能保证扩缩容的过程中
    不会对业务产生影响,才可以频繁地进行扩缩容。

    level 6
    level 5 的周期性伸缩用一种简单地预测性的方式很好的解决了公司常规业务的资源使用率的问题。但由于仅仅采集了时间维度对系统资源使用
    情况影响的数据,其调整方式较为单一,无法应对突发情况。
    通常情况下,在系统出现高流量,高负载前,都会有一些前置性信号。这些信号包括但不限于以下方面:

    基于以往压测数据和以往运营活动数据对即将开展的营销活动的流量的预测
    利用社会工程学手段对社会上即将发生的热点事件和正在发生的热点事件的走向的预测
    利用机器学习对系统响应时间、流量走势、系统负载走势等多维度海量监控数据的分析对即将到来的高流量和高负载的预测(例如 netflx 的预测分析引擎Scryer)

    技术手段能够解决许多问题,但是并不能解决所有问题。在解决系统性问题时,尤其是较复杂的系统问题时,我们不能把思维完全限制在技术领域,
    同时结合多种手段,可以使许多看似无法用技术手段解决的问题迎刃而解。

    当然,随着机器学习技术的兴起,一些以往无法用传统方式解决的技术问题,也变得可解。只不过需要专业人士投入较多的人力物力,在使用
    这种方式时,要在充分考虑投入产出比后,再做决定。

    Netflix发现,对于部分基础架构和特定的工作负载,其预测分析引擎 Scryer 比传统的被动自动缩放方法提供了更好的结果。它特别适合以下场景:

    在不久的将来识别需求的巨大峰值,并提前一点准备好产能
    处理大规模中断,例如整个可用区和区域的故障
    处理可变的流量模式,根据一天中不同时间的典型需求水平和变化率,在横向扩展或纵向扩展速率上提供更大的灵活性

    任何系统和工程都不是一蹴而就的,只有当基础设施达到一定完善程度后,再逐级实现弹性伸缩,才是一个比较可行的路线。
    本文假定目前系统已经达到了2 级的弹性伸缩。以下主要讲述在此基础上,实现更高级的弹性伸缩的相关知识点。

    0x2 autoscaling in kubernetes
    接下来我们开始逐步详细讲解在文章开头绘制的路线图。

    service autoscaling
    首先,按照伸缩粒度,分为服务伸缩和节点伸缩。我们先来看服务伸缩。
    k8s 默认提供了多个服务粒度的弹性伸缩组件。主要有 VPA, addon resizer 和 HPA。
    此外,各大云厂商也积极贡献提供了多种伸缩组件,例如阿里云提供的 cronHPA。
    以下我们分别详细说明。

    在服务粒度的伸缩中,依据执行触发时机不同,可分为立即执行,定时执行和预测性执行。
    先来看立即执行。

    立即执行又细分为垂直伸缩和水平伸缩。

    垂直伸缩

    k8s 中的垂直伸缩一般是指调整 Pod 的内存和 CPU 配额(resource limit 和 request)。
    k8s 官方 autoscaler 包中有两个类型的垂直伸缩组件:
    VPA(vertical pod autoscaler) 和 addon resizer。
    addon resizer可以根据集群节点数量来动态地调整某个其他 deployment 中的 pod 的配额。
    addon resizer 周期性地查看集群节点数量,然后计算出监控的 pod 需要分配的内存和 CPU,如果 pod 的实际 pod 配额
    和所需配额超过某个阈值,则会修改 deployment 并触发生成新的 pod。addon resizer 的这种特性决定了它用来伸缩与集群
    规模密切相关的服务。一般, addon resizer 用来伸缩部署在集群内的 heapster, metrics-server, kube-state-metrics
    等监控组件。

    VPA的应用范围要广一些。设置 VPA 后,它能够自动为 pod 设定 request 和 limit 配额值,然后动态地将 pod 调度
    到合适的节点上去。

    VPA 在 k8s 中定义类型为 VerticalPodAutoscaler 的 CRD,
    为每个需要开启垂直弹性伸缩功能的 deployment 创建一个 custom resource,然后 VPA 会定期查看对应 pod 的资源使用情况,结合历史数据,
    自动调整 pod 的配额。

    VPA controller 由三部分组成。

    Recommender:它监视当前和过去的资源消耗,并基于此提供容器的cpu和内存请求的推荐值。
    Updater:它检查哪个托管的pod设置了正确的资源,如果没有,则杀死它们,以便它们的控制器可以用更新后的请求重新创建它们。
    Admission Plugin:它在新pod上设置正确的资源请求(由于Updater的活动,它们的控制器只是创建或重新创建了这些请求)。

    使用 VPA 监控 deployment 时,它并不会去改变 deployment 的配置,而是使用 admission plugin 以类似 pre hook 的方式
    在创建 pod 时动态为其配置配额值。

    使用 VPA 之前需要注意以下问题:

    VPA 默认会从 metrics server 中采集历史数据,因此使用 VPA 之前,需要配置好 metrics server。VPA 也支持从 prometheus 中
    采集历史数据,不过需要额外的配置。关于 metrics server、state metrics、prometheus 等监控服务的异同,我们将在 数据监控一节中
    详细介绍

    VPA 是在伸缩调整过程中,是通过重启 pod 来使调整生效的,因此已经公司基础架构不同,可能会引起服务闪断,需要具体分析服务是否可接受

    使用 VPA 扩容有上限,具体受 pod 所在宿主机影响。为 pod 分配的资源无法超过宿主机的大小。如果 recommender 计算出的 pod 所需资源
    超过节点可用资源,将导致 pod 一直 pending。这点可与通过与 cluster autoscaler 共同使用来部分解决。

    VPA 目前不应与基于内存和 CPU 监控的水平Pod自动调度器(HPA)一起使用,否则可能产生预期外的行为。

    水平伸缩
    Horizontal Pod Autoscaler 是 k8s 内置的水平伸缩控制器。 它根据观察到的CPU使用率(或使用自定义指标支持,基于某些其他应用程序提供的指标)
    自动缩放 replication 控制器,deployment,副本集或状态集中的 pod 数量。 需要注意的是,水平窗格自动缩放不适用于无法缩放的对象,
    例如DaemonSets。

    HPA 实现为Kubernetes API资源和控制器。资源决定控制器的行为。控制器定期(默认为 15 秒)调整复制控制器或部署中的副本数量,
    以使所观察到的平均CPU利用率与用户指定的目标相匹配。

    与 VPA 仅支持从 metrics server 中采集 CPU 和内存数据不同的是,HPA 支持多种数据维度和数据采集方式:

    从 heapster 中采集 CPU 和内存数据(自 kubernetes 1.11 起废除)
    遵循特定格式记录在 annotation 中的应用自定义 metrics(自 kubernetes 1.6 起废除)
    使用 metrics API 采集 metric server 中的数据
    通过 custom metrics adapter 将 prometheus 等第三方中的数据采集提供给 custom metrics API 使用。

    和 VPA 一样,使用 HPA 一般需要先搭建 metrics server,具体方法可参考 kubernetes 官方指南。

    在新版本(kubernetes 1.6 以后)的 metrics API 中,引入聚合层(aggregation layer),为应用查询 metrics server
    内部的数据和第三方数据提供了一致的抽象。第三方监控数据只需自己实现相应的 adapter,并在 metrcis API 中为其
    监控的 metric 注册相应的 custom metrics API 即可。

    下图展示了使用 HPA 根据 metrics server 和 prometheus 中的数据进行弹性伸缩的过程。

    在这里插入图片描述

    定时伸缩
    kubernetes 官方并没有提供定时伸缩相关的组件,但是其原理并不难,只需按照设定的时间调用 kubernetes 的 API 即可。
    kubernetes-cronhpa-controller 是阿里云工程师基于 go-cron
    开源的定时伸缩组件。

    预测性伸缩
    目前暂无成熟的技术方案。

    node autoscaling

    垂直伸缩

    与 kubernetes 本身关系不大,其功能主要取决于云厂商。例如,厂商是否支持主机的升降配,以及升降配过程中是否
    需要重启主机等。如果需要重启主机,那么在进行伸缩之前,我们需要先把节点上的 pod 驱逐到其他主机。
    但是如果我们是由于机器资源不够用而扩容的话,这样会加剧资源不够用的情况,造成更大的 pending 状态的 pod。
    因此,如果如果云厂商不支持不重启就能扩容的话,我们不建议采用这种方式进行节点扩容。

    水平伸缩
    CA(Cluster Autoscaler) 是 kubernetes 官方的节点水平伸缩组件。
    它可以在下列条件之一为真时自动调整Kubernetes集群的大小:

    集群中有 pod 由于资源不足而一直 pending
    集群中有些节点在很长一段时间内没有得到充分利用,且其上的 pod 可以被调度到其他节点上。

    cluster autoscaler 虽然是 kubernetes 官方标准,但是由于其去云厂商依赖较深,因此具体使用方法,功能以及限制以
    云厂商具体实现为准。目前支持以下云厂商: Google Cloud Platform, AWS, AliCloud, Azure, BaiduCloud。

    以 AliCloud 为例,默认单个用户按量付费实例的配额是30台,单个VPC的路由表限额是50条;且每个可用区的同一类型的实例
    库存容量波动很大,如果短时间内大量购买同一区同一配置的实例,很容易出现库存不足导致扩容失败。
    建议在伸缩组中配置多种同规格的实例类型,提高节点伸缩成功率。

    实际使用中,一般为 node 建立多个 node group,专门配置几个 group 来启用弹性伸缩应对突发流量进行扩缩容。
    主要的 group 并不进行扩缩容,来避免扩缩容导致对大范围的服务的影响。

    此外,节点水平伸缩能否成功实施,与调度策略密切相关。kubernetes 在为 pod 选择可分配节点时,
    是采用 LeastRequestedPriority 策略,简单来说就是就是尽可能把资源打散,把 pod 分配到资源利用率低的节点。
    这样会倒是有一批利用率较低,但未到缩容阈值的节点,因此会导致无法成功缩容,资源利用率低。因此实际使用时,需要
    调整 kubernetes 调度策略,来达到最优的结果。

    定时伸缩
    目前暂无成熟的技术方案。

    数据监控
    heapster
    heapster 是一个数据收集器,从每个 node 上采集数据并进行汇总,然后转存到第三方工具中,
    它本身并不生成监控数据,也不负责存储。

    目前 heapster 已经被逐渐废弃(从 kubernetes 1.11 开始),不再维护和推荐使用。

    heapster 曾负责以下功能:

    监控节点、pod 的 cpu 内存基础数据。这部分数据采自每个节点的 cadvisor(新版本的 kubernetes 已集成到 kubelet)。
    通用的数据项目监控。
    kubernetes 事件信号转发。 heapster 调用 api-server 并将集群的 event 转发处理。
    目前这三个功能可依次由 metrics server、pormetheus operator、eventrouter 等独立的组件替换。

    metrics server
    metrics server 是 heapster 的继承者,kubernetes 1.8 开始,集群内监控数据可以通过 metrics API
    从监控数据聚合器 metrics server 中获取。
    Metrics API相比于之前的监控采集方式(hepaster)是一种新的思路,官方希望核心指标的监控应该是稳定的,版本可控的,
    可以直接被用户访问(kubectl top),也可以由组件通过 API 调用。由于监控数据量巨大,不适宜像其他资源一样存到 etcd 中,
    因此 Metrics server 将数据存在内存中,只提供实时数据的查询,不提供历史数据查询功能。
    除了可以通过 metrics API 查询内部监控数据外,metrics server 提供了灵感的扩展方式。

    系统可以为自定义监控数据实现对应的 adapter, 用户就可以以 custom metrics API 的方式查询数据,保持与查询原生数据一致的体验。

    通常, metrics server 的数据可作为各个维度弹性伸缩的数据指标。

    state metrics
    kube-state-metrics 侦听 Kubernetes API服务器并生成关于对象状态的指标。它并不关注Kubernetes组件的健康状况,而是关注内部各种对象
    (如 deployment、node 和 pod)的健康状况。
    我们可以直接访问 Kube-state-metrics 的 /metrics HTTP 接口来查看监控数据。 这些数据用来提供给 prometheus 获取其它一些第三方程序
    抓取使用。

    关于 state metrics 和 metrics server 的差异:

    metrics server 仅采集 kubernetes 中的 CPU、内存等核心指标,它周期性地调用所有节点的 kubelet
    提供的 summary API。这些数据是按 pod、node 维度聚合的,存储在内存中,并且以 metrics API
    的格式提供。它仅存储最新数据,并且不负责将这些数据导出提供给第三方使用。

    kube state metrics 主要关注于从 deployment, replica set, stateful set 等 kubernetes
    对象生成新的监控数据,将原始数据重新聚合、呈现。它在内存中存储整个 kubernetes 集群的状态快照,并在此之上持续生成新的监控数据。同样,
    它也负责将这些数据导出提供给第三方使用。

    prometheus
    用于存储、聚合、查询监控数据的时序型数据库。

    0x3 其他
    最后分享一张我们分析弹性伸缩时用到的思维导图:

    在这里插入图片描述

    展开全文
  • 弹性伸缩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才能解决问题。
    展开全文
  • 设计弹性伸缩架构

    2020-08-17 18:27:50
    Hello大家好,欢迎来到《AWS解决方案架构师认证 Professional(SAP)中文视频培训课程》,我们今天的课程内容为设计弹性伸缩架构,我们开始今天的课程内容。 在我们讨论弹性伸缩内容之前,我们先讨论下与之相关的知识...
    关注公众号:AWS爱好者(iloveaws)
    文 | 沉默恶魔(禁止转载,转载请先经过作者同意)
    网站:www.iloveaws.cn
    

    Hello大家好,欢迎来到《AWS解决方案架构师认证 Professional(SAP)中文视频培训课程》,我们今天的课程内容为设计弹性伸缩架构,我们开始今天的课程内容。

    在这里插入图片描述

    在我们讨论弹性伸缩内容之前,我们先讨论下与之相关的知识点—什么是垂直扩展和水平扩展。

    垂直扩展和水平扩展

    垂直扩展是指提升单个节点的自身的处理能力,比如通过升级节点的CPU,内存等硬件,这种通过升级原有的服务器或将其更换为更强大的硬件来提升单个节点的处理能力称为垂直扩展;比如对应AWS,就是通过改变或提升实例的类型和大小使其有更强的计算等能力,比如当工作负载增加时,将处理负载的实例从m5.large升级为m5.24xlarge, 这就是垂直扩展。需要注意垂直扩展是有上限的,上限取决于AWS提供的最大实例的大小。

    那什么是水平扩展呢?

    水平扩展指的是通过增加更多的节点来分散处理工作负载,从而实现节点计算等能力的扩展。对应AWS举例,比如我们之前处理某个工作负载使用了一台m5.large,当这个工作负载增加后,我们不是像垂直扩展去升级硬件,而是通过增加多台m5.large实例处理工作负载的方式就是水平扩展。 当然,水平扩展对您的应用的架构设计是有要求的。另外水平扩展理论上是可以无限扩展的,除非将AWS的所有实例都用完了。可以通过不断的添加实例,分散工作负载从而提高处理能力。

    那么问题来了,能不能将水平扩展自动化执行呢?当工作负载高的时候自动进行架构的水平扩展,通过添加更多的实例加快处理工作负载;而当工作负载恢复正常水平时在自动进行缩减实例数量以节省成本呢?当然是可以的,这就是我们接下来要讨论的弹性伸缩的内容。
    在这里插入图片描述

    设计使系统的容量可以弹性伸缩

    我们先看一个案例,某公司开发了一款线上办公系统并已对外提供服务,左图是这套系统一周中每一天所使用的计算容量。
    通过图中可以看到,因为是办公系统,周六和周日大部分公司放假访问量不高,所以使用的计算容量很低;周二和周三访问量最高,大概比周末高出6,7倍。

    按照传统做法,可通过两种方式为线上办公系统这些容量变化做好规划。第一种是添加足够多的服务器,以便线上办公系统始终具有足够的容量来满足需求。周三系统的访问量最高,就按照周三的最大容量准备服务器,如果周三的访问量需要10台服务器提供服务,就会部署10台服务器。但是,这种做法的缺点是线上办公系统在某些天并不需要这么多容量。比如周末可能只需要1,2台服务器就可以满足系统需求。剩下的额外容量闲置不用,实际上提高了系统运行的成本。

    第二种做法是只准备线上办公系统平均需求所需的容量。比如就准备6台服务器,可以满足一周中的4天的计算容量需求。这种做法成本更低,因为不用购买仅仅偶尔使用到的服务器。然而,这样做的风险是:当对系统的需求超过其可用容量时,比如尤其是周二和周三,可能造成糟糕的客户体验。

    前面的两种方式都不是太理想,要么会浪费资源提高运行的成本;要么就是某些高峰时间点可能会给用户造成糟糕的用户体验。

    那有没有更好的做法呢?答案是肯定的,通过设计使我们系统的容量可以弹性伸缩。对应AWS EC2,通过使用 Amazon EC2 Auto Scaling,可以仅在需要时才向应用程序添加新实例,并在不再需要这些实例时终止它们,因此只需在使用时为使用的实例付费。

    比如对应我们这个案例,通过对Auto Scaling的配置,周三的时候办公系统访问量较大,Auto Scaling就会自动增加新的实例处理负载;而周四的时候系统访问量比周三少了一半,Auto Scaling会自动终止一些实例只保留满足系统需要的实例数量。这样的话我们就有了一个具有成本效益的架构,可在尽量减少支出的同时提供最佳客户体验。

    在这里插入图片描述

    EC2 Auto Scaling可根据业务需求和策略设置扩展选项,比如配置扩展策略在业务需求增长时自动为您增加实例以保证计算能力,在业务需求下降时自动减少实例数量以节约成本。

    在认证考试中,经常会有一些题干描述的场景为应用系统 一周中不同天 或者 一天的不同时间段 业务量会有波动,有访问量波峰也有波谷,如一天的不同时间段,晚上高峰时间段的业务量可能最高,然后凌晨之后业务量可能会减少,问如何设计能够满足业务波峰时的容量并兼顾成本效益,这个时候就要注意很可能是Auto Scaling相关的考点。

    当然Auto Scaling不仅适合业务量不断波动的应用程序,同时也适合业务量稳定的应用程序,这一点我们后面会讨论。

    AWS爱好者网站的弹性伸缩

    我们在看一个案例,AWS爱好者网站,里面有很棒的AWS视频课程和文章,很多同学和职场精英白天上完班,晚上下班回家吃了饭后,都会访问AWS爱好者网站来充电,提升个人的职场竞争力。网站的访问量在白天大家都上班的时候不是特别高,基本上1台实例就够了,CPU使用率大概20%左右;而到了晚上19点,大家都来网站看视频课程,这台实例可能CPU会突增到80%多的使用率,甚至有的时候CPU使用率会到100%,就会导致我的网站访问异常,造成不好的用户体验。(当然我们假设网站的带宽等其他指标都没问题,瓶颈是以为CPU使用率过高造成的)。

    我们现在假设要通过EC2 Auto Scaling,实现弹性伸缩,白天运行一个实例提供服务,在晚高峰时,运行3个实例提供服务。

    可以通过EC2 Auto Scaling,配置扩展策略,然后通过定义Auto Scaling组平均 CPU 使用率指标实现弹性伸缩。

    我们可以定义规则,当Auto Scaling 组的平均 CPU 使用率大于70%时,新启动两台实例处理网站负载;然后在配置一个规则当Auto Scaling 组的平均 CPU 使用率小于25%时,终止2个实例。

    这样的话,在白天网站访问量不是很高的时候,只会有1台实例提供网站服务,而到晚上19点后访问量上去后,当CPU使用率大于70%时,Auto Scaling会启动两台新实例处理网站负载,加上之前的1台实例,一共3台实例提供网站服务;而当22点之后,访问量下去之后,如果平均CPU使用率小于25%,Auto Scaling就会终止2台实例,继续保持最小容量1台实例运行。

    这样的话,我们通过Auto Scaling服务,在网站访问量高的时候一共3台实例处理负载,提升了网站用户的体验;当访问量降低时,只保留1台实例处理负载,节省了成本。

    在这里插入图片描述

    弹性伸缩配置

    我已经创建好了Auto Scaling组,as-test-group为我们已经创建的Auto Scaling组。

    我将组的最小容量配置为1,最大容量配置为3 。

    最小容量是指确保始终运行一定数量的实例,按照前面我们的案例,我设置的是1就代表无论怎么缩减这个Auto Scaling组始终会保持最少运行1台实例对外提供服务。如果设置为5呢?就代表始终会保持最少运行5台实例。

    最大容量是指最大限制允许 Auto Scaling 根据需要向外扩展实例数,以满足增长需求。我们设置的是3,就代表这个Auto Scaling组最多可扩展为3个实例。

    然后参照前面我网站的案例,我为这个Auto Scaling组配置了扩展策略,策略的内容当Auto Scaling组的平均 CPU 使用率 大于等于 70%时添加2台实例;当Auto Scaling组的平均 CPU 使用率 小于 25% 删除2台实例。

    这个平均 CPU 使用率 大于等于 70%以及小于25%实际上是通过我在cloudwatch中配置的警报,然后将cloudwatch警报与当Auto Scaling组相关联,这样当 CloudWatch 警报处于 ALARM 状态时,Auto Scaling组就会执行相应的添加和删除实例的动作。
    在这里插入图片描述

    我们到cloudwatch控制台看下。

    我们在前面Auto Scaling组关联的两个警报实际上是在cloudwatch这里定义的,可以看到警报的条件, CPU 使用率 大于等于 70%以及小于等于25%,然后配置Auto Scaling组将其相关联,当对应 CloudWatch 警报处于 ALARM 状态时,Auto Scaling组就会执行相应的添加和删除实例的动作。

    关于Auto Scaling的具体配置我们会在后面的课程详细讨论和实操演示,所以学友们先做了解,后面的课程我们会介绍Auto Scaling的重要知识点,对创建和配置Auto Scaling做实操的演示。

    好,以上就是我们今天的课程内容。

    在这里插入图片描述

    希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助,如您有任何疑问

    关注公众号:AWS爱好者(iloveaws)
    文 | 沉默恶魔(禁止转载,转载请先经过作者同意)
    网站:www.iloveaws.cn
    
    展开全文
  • 弹性伸缩具有应突发、省成本、自动化的业务价值。平台侧将各业务零散、闲置资源进行整合,形成一个大规模资源池,通过弹性调度、库存管控技术在公司运营成本和业务体感中寻求较好的平衡。本文将介绍美团...
  • 阿里云弹性伸缩服务入门介绍

    千次阅读 2019-08-25 11:44:15
    弹性伸缩服务(Elastic Scaling Service)是根据用户的业务需求和策略,自动调整其 弹性计算资源的管理服务。用户根据自己的业务需求自动调整其弹性计算资源,在满足 业务需求高峰增长时无缝地增加 ECS 实例,并在...
  • Kubernetes—弹性伸缩

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

    2021-09-04 12:02:05
    弹性伸缩 弹性伸缩为用户提供高效管理计算资源的策略。用户可设定时间周期性地执行管理策略或创建实时监控策略,来管理VM实例数量,并完成对实例的环境部署,保证业务平稳顺利运行。在需求高峰时,弹性伸缩自动增加...
  • 背景弹性伸缩是根据用户的业务需求和策略,自动“调整”其“弹性资源”的管理服务。通过弹性伸缩功能,用户可设置定时、周期或监控策略,恰到好处地增加或减少“弹性资源”,并完成实例配置,保证业务平稳健康运行。...
  • K8S弹性伸缩简谈

    千次阅读 2020-08-11 11:07:24
    k8s 默认提供了多个服务粒度的弹性伸缩组件。主要有 VPA, addon resizer 和 HPA。 此外,各大云厂商也积极贡献提供了多种伸缩组件,例如阿里云提供的 cronHPA。 在服务粒度的伸缩中,依据执行触发时机不同,可分为...
  • 由于大部分云资源是按需取用,按量计费模式,相比使用 IDC,使用云的用户从弹性伸缩获得的成本优势是非常明显的,弹性伸缩也是大多数云上用户的选择。而关于如何用好弹性伸缩,一直是用户非常关心的问题,本文尝试...
  • 弹性伸缩ESS

    千次阅读 2017-07-17 17:30:49
    概念弹性伸缩ESS——根据用户的业务需求和策略,经济地自动调整弹性计算资源的管理服务。特点 可以监控集群,随时自动替换不健康的实力,节省运维成本。 可以管理集群,在高峰期自动增加ECS实例,在业务回落时自动...
  • 阿里云服务器叫ECS,阿里云弹性伸缩服务叫ESS。 顾名思义,弹性伸缩就是根据您设置的伸缩规则,在业务需求增长时自动为您增加ECS实例以保证计算能力,在业务需求下降时自动减少ECS实例以节约成本。自动为您调整弹性...
  • 弹性伸缩具有应突发、省成本、自动化的业务价值。平台侧将各业务零散、闲置资源进行整合,形成一个大规模资源池,通过弹性调度、库存管控技术在公司运营成本和业务体感中寻求较好的平衡。本文将介绍美团...
  • Kubernetes30--弹性伸缩总结

    千次阅读 2018-12-20 10:55:27
    前面学习有关弹性伸缩的论文以及k8s HPA的源码,对于云计算中弹性伸缩有了一些认识,总结一下。 弹性伸缩简介    伸缩理论关注的问题主要是在面临超出现有集群最大承载能力的时候,如何通过调整集群的规模以...
  • ACP 学习-03-弹性伸缩(Auto Scaling)

    千次阅读 2020-09-03 23:23:06
    弹性伸缩 使用弹性伸缩(Auto Scaling),您可以根据业务需求和策略设置伸缩规则,在业务需求增长时自动为您增加ECS实例以保证计算能力,在业务需求下降时自动减少ECS实例以节约成本。 弹性伸缩不仅适合业务量不断...
  • 高性能 高可用 可弹性伸缩 本文是我们名为Java Concurrency Essentials的学院课程的一部分。 在本课程中,您将深入探讨并发的魔力。 将向您介绍并发和并发代码的基础知识,并学习诸如原子性,同步和线程安全性的...
  • 腾讯云除了纵向伸缩最近推出弹性伸缩即横向伸缩,根据现有业务需求变化,动态调配资源,实现高度弹性伸缩,用户不必介入具体操作流程,只需关注结果即可。   一、弹性伸缩关键优势   1. ...
  • 微服务弹性伸缩与负载均衡

    千次阅读 2018-02-08 17:40:59
    微服务弹性伸缩与负载均衡 微服务如何实现弹性伸缩 云帮的应用弹性伸缩有不同的层次、类型及形式,且进行伸缩操作对用户是无影响的,服务不会有任何的中断(平滑伸缩)。由于平台是基于容器技术的,因此伸缩的...
  • 弹性伸缩弹性伸缩是根据用户的业务需求和策略,自动调整其弹性计算资源的管理服务。其能够在业务增长时自动增加 ECS 实例,并在业务下降时自动减少 ECS 实例。 伸缩组:伸缩组是具有相同应用场景的 ECS 实例的集合...
  • 在 Kubernetes 中弹性伸缩主要有三种:HPA、VPA、CA。本文不再详细说明,有兴趣的可以看那篇文章。这里主要来说下 Pod 水平缩放 HPA。 随着 Kubernetes v1.23 的发布,HPA 的 API 来到了稳定版 autoscaling/v2: ...
  • 弹性伸缩服务1-2-3

    2017-01-16 15:38:44
    弹性伸缩是根据用户的业务需求自动调整弹性计算资源的服务,即能够根据应用负载情况自动扩张和收缩应用环境所使用的计算资源。在请求增加时,弹性伸缩能够为自动分配更多的计算资源,在请求下降时,弹性伸缩能够自动...
  • 主要整理了Flexbox模型布局功能、属性术语、语法规范、各版本语法变更和新版本Flexbox模型!除此之外,还有更头疼的是浏览器兼容性,需要多次练习整理才能好好使用伸缩布局模型来解决布局问题。
  • 1 弹性伸缩场景 在业务场景中,常常会碰到对服务器资源需求大幅波动的情况。如电商在双十一等促销活动时,百万甚至千万级用户同时进行着搜索商品、下单等操作,要求电商后台具备集中时间段内应对大请求量的处理能力...
  • 弹性伸缩弹性伸缩适应负载变化,以弹性可伸缩的方式提供资源。Pod的弹性伸缩就是修改Replication Controller的Pod副本数。可以通过Kubectl scale命令实现。创建Replication Controllertest-rc.yamlapiVersion: ...
  • flink 作业运行所需要的资源 资源伸缩时(TM节点增加或者减少时),flink 作业自动重启 reactive 模式只支持 standalone 方式部署 二、flink master 节点进程中运行的相关组件(本篇涉及到的) RestServer ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 13,630
精华内容 5,452
关键字:

弹性伸缩是指