精华内容
下载资源
问答
  • 弹性伸缩弹性伸缩是指适应负载变化,以弹性可伸缩的方式提供资源。Pod的弹性伸缩就是修改Replication Controller的Pod副本数。可以通过Kubectl scale命令实现。创建Replication Controllertest-rc.yamlapiVersion: ...

    弹性伸缩

    弹性伸缩是指适应负载变化,以弹性可伸缩的方式提供资源。

    Pod的弹性伸缩就是修改Replication Controller的Pod副本数。可以通过Kubectl scale命令实现。

    创建Replication Controller

    test-rc.yaml

    apiVersion: v1
    kind: ReplicationController
    metadata:
      name: test-rc
    spec:
      replicas: 2
      selector:
        app: test
      template:
        metadata:
          labels:
            app: test
        spec:
          containers:
          - name: test
            command:
              - sleep
              - "3600"
            image: 192.168.121.143:5000/busybox
            imagePullPolicy: IfNotPresent
          restartPolicy: Always

    创建RC

    # kubectl create -f test-rc.yaml 

    查看创建出的Pod

    # kubectl get pod --selector app=test -o wide

    这里写图片描述

    扩容Pod的数量到4

    # kubectl scale rc test-rc --replicas=4
    # kubectl get pod --selector app=test -o wide

    这里写图片描述

    缩容Pod的数量到1

    # kubectl scale rc test-rc --replicas=1
    # kubectl get pod --selector app=test -o wide

    这里写图片描述

    把Pod的数量设为0,即可删除RC关联的所有Pod。

    滚动升级

    滚动升级采用逐步替换的策略。

    通过一个例子进行演示,演示应用从V1版本升到V2版本。

    创建V1版本的RC。

    my-app-v1-rc.yaml

    apiVersion: v1
    kind: ReplicationController
    metadata:
      name: myapp-v1
    spec:
      replicas: 10
      selector:
        app: myapp
        version: v1
      template:
        metadata:
          labels:
            app: myapp
            version: v1
        spec:
          containers:
          - name: myapp
            command:
              - sleep
              - "3600"
            image: 192.168.121.143:5000/busybox:v1
            imagePullPolicy: IfNotPresent
          restartPolicy: Always

    创建RC,查看RC和Pod。

    # kubectl create -f my-app-v1-rc.yaml
    # kubectl get rc myapp-v1 -o wide
    # kubectl get pods --selector app=myapp -o wide

    这里写图片描述

    创建V2版本的RC。

    my-app-v2-rc.yaml

    apiVersion: v1
    kind: ReplicationController
    metadata:
      name: myapp-v2
    spec:
      replicas: 10
      selector:
        app: myapp
        version: v2
      template:
        metadata:
          labels:
            app: myapp
            version: v2
        spec:
          containers:
          - name: myapp
            command:
              - sleep
              - "3600"
            image: 192.168.121.143:5000/busybox:v2
            imagePullPolicy: IfNotPresent
          restartPolicy: Always

    开始滚动升级

    # kubectl rolling-update myapp-v1 -f my-app-v2-rc.yaml --update-period=10s

    通过–update-period=10s设置每隔10s逐步增加V2版本的RC的Pod副本数量,逐步减少V1版本的RC的Pod副本数量。
    升级完成后,删除V1版本的RC,保留V2版本的RC。
    这里写图片描述

    在升级过程中,可以进行回退。如果升级完成,则不可以使用这条指令进行回退。

    # kubectl rolling-update myapp-v1 -f my-app-v2-rc.yaml --update-period=10s --rollback
    展开全文
  • 设计弹性伸缩架构

    2020-08-17 18:27:50
    关注公众号:AWS爱好者(iloveaws) 文 | 沉默恶魔(禁止转载,转载请先经过作者同意) ... Hello大家好,欢迎来到《AWS...垂直扩展是指提升单个节点的自身的处理能力,比如通过升级节点的CPU,内存等硬件,这种通过升级原
    关注公众号: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
    
    展开全文
  • 背景弹性伸缩是根据用户的业务需求和策略,自动“调整”其“弹性资源”的管理服务。通过弹性伸缩功能,用户可设置定时、周期或监控策略,恰到好处地增加或减少“弹性资源”,并完成实例配置,保证业务平稳健康运行。...

    20170615184547_663.jpg

    背景

    弹性伸缩是根据用户的业务需求和策略,自动“调整”其“弹性资源”的管理服务。通过弹性伸缩功能,用户可设置定时、周期或监控策略,恰到好处地增加或减少“弹性资源”,并完成实例配置,保证业务平稳健康运行。

    这里的调整是指:在满足业务需求高峰增长时无缝地增加“弹性资源”,并在业务需求下降时自动减少"弹性资源"以节约成本。

    在基于容器的PaaS平台中,弹性资源包含两种资源:微服务实例、宿主计算机资源

    属于IaaS计算资源池的范畴,PaaS并不直接操作这些资源,只提供一个触发器,用来打通PaaS和IaaS。当PaaS感知底层计算资源使用情况满足配置规则时,触发IaaS对资源池扩缩容。

    本文主要讨论第一种情况及“微服务实例”的自动弹性伸缩

    产品需求

    定义弹性伸缩功能,就是定义一下两块内容:

    触发规则:涉及在什么时候(定时、周期)、按照什么方式(监控项、判断标准)。

    弹性伸缩行为:定位目标资源、伸缩的流程控制。

    2.1用户视图

    从用户的角度,要指定某个微服务的弹性伸缩规则需要操作如下内容:

    目标对象:微服务名称

    全局参数:1.使能开关 2.单次伸缩操作可增减的实例数(步长) 3.最大实例数 4.最小实例数 5.两次操作之间的触发间隔 6.用于触发弹性伸缩行为的判断指标 (CPU/Memory/Calendar)

    目标对象:微服务名称

    CPU

    扩容规则:门限值(>95%)持续时间(5 min)

    缩容规则:门限值(<20%)持续时间(5 min)

    Memory

    扩容规则:门限值(>4GB)持续时间(5 min)

    缩容规则: 门限值(<500MB)持续时间(5 min)

    Calender

    周期类型(月/星期)

    起始时间(精确到秒,如:01日 08:00:00 - 03

    18:00:00)

    周期内弹性伸缩规则细节 (CPU/Memory/Calendar-Time)

    Calendar-Time:(CPU/Memory同上)

    伸缩方向:(Up/Down,进入该时 间段的起始时间执行扩缩容、偏离该时间段恢复原实例数)

    20170615184547_200.jpg

    UI界面

    2.2数据模型

    20170615184547_625.png

    方案-A

    软件架构如下图所示:

    20170615184548_768.png

    orchestration 统一调度和管理弹性伸缩规则,比如当某一个stack中的微服务配置了弹性伸缩规则,orchestration会负责启动service对应的实例,然后调用弹性伸缩API gateway的API来下发配置。配置里面包含了具体某个service所属的租户、环境、stack(通过它们可以在整个系统中唯一索引到一个service);同时,该配置中好包含了每一个service对应的弹性伸缩规则(即上一节中提到的全局参数和规则细节)。

    API gateway作为弹性伸缩对外的同一入口,一方面接受来自orchestration的用户配置并读取配置请求;另一方面,接收来自monitor的告警信息。

    DB用于存储弹性伸缩需要持久化的配置数据,以及操作日志等信息。

    20170615184548_558.png

    Routine负责弹性伸缩的处理逻辑;每一个 service都会通过golang启动一个routine。

    20170615184548_506.png

    由于每一个service的弹性伸缩规则都包含了其作用时间;于是,我们按照这些时间片划分,可以将每一个时间片的弹性伸缩规则看做该service的一个状态。那么,弹性伸缩的状态机的变化,就是由timer和外部事件驱动的。

    它们主要是以下三类事件:

    服务弹性伸缩规则更新

    接收到监控告警

    当前strategy的作用时间终结

    我们来分析这三种事件的响应方式

    服务弹性伸缩规则更新: 当用户在UI上修改某个微服务的弹性伸缩规则时触发该事件,它要求立即结束当前所在的状态(比如,从calendar类型状态中恢复微服务实例的数量,或者从CPU、Memory类型状态中删除配置到监控模块的告警规则...)

    接收到监控告警:需要判断当前是否处于CPU、Memory类型状态中,是否当前时间允许触发扩缩容操作。当这些条件都满足,然后确定伸缩的方向、步长、保障允许操作实例数的最大值最小值。然后对目标微服务做扩缩容操作。

    当前strategy的作用时间终结:实现中,先对微服务的所有strategy按照时间片段来排序,然后通过与当前时间比较,从而确定当前时间有效的current strategy。但是,通过计算current strategy时间片的结束时间与当前时间的差值来确定何时结束 current strategy的作用范围。于是,只需要设置一个timer,其超时时间为 (end time of current strategy - now time)。

    存在的问题与缺陷

    这样的设计,存在一定的缺陷:

    无法支持多实例部署:因为每一个 Routine本质是一个service的状态机,它的状态被外部事件驱动;意味着在多实例部署时,外部请求被哪个实例接收到,该实例就进入下一个状态;而其它实例并没有同步变化。

    数据操作繁琐:orchestration与弹性伸缩各自维护了一套service作为Key的数据表;当用户通过orchestration对某个服务的弹性伸缩规则做增删查改时,数据访问流程复杂;由于各自的数据结构不一致,涉及到繁琐的数据转换。

    协程间内部消息通信复杂:由于每一个service对应一个Routine,Routine与各种事件之间相互通信,需要引入较多的golang channel,一旦没用好,极容易导致阻塞。

    方案—B

    基于方案-A 设计存在的几种弊端,我们对 方案-A 做了一些改进,引入了 方案-B,具体如下

    与方案A的差异在于:

    在弹性伸缩服务内部,不设数据库。所有弹性伸缩的配置信息均存在orchestration的DB中,一旦有读取弹性伸缩配置的需求,orchestration会直接从自己的数据库中获取;数据结构可以完全基于orchestration的需求来定义,减少了数据转换流程,更加高效。

    在orchestration与弹性伸缩之间引入Redis。Redis作为orchestration与弹性伸缩之间传递配置信息,同时作为多个弹性伸缩实例间共享运行时状态数据的介质。它解耦了orchestration与弹性伸缩之间的强依赖,从而使得两者能够基于Redis上的数据各司其职。

    将之前基于service有状态的routine 更新为基于timer无状态的routine。新的Routine每秒钟被触发一次,

    从Redis读取弹性伸缩服务列表,并按照列表中包含的服务,逐一为每一个服务启动一个service Routine。service Routine无状态,只check当前时刻应该生效的strategy,是否与Redis中已存的current strategy一致。如果不一致,切换stategy(执行相应操作,比如删除上一个strategy发送到监控模块的告警规则,重新下发新的告警规则等),然后终结该service Routine。

    支持多个弹性伸缩服务实例。因为Routine内部不再维护一个多实例见无法同步的service的状态机,同时,redis作为多实例的一个共享数据介质,为支持多实例提供了条件。

    展开全文
  • K8S弹性伸缩简谈

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

    按照伸缩粒度,分为服务伸缩和节点伸缩

    1. 服务伸缩
      k8s 默认提供了多个服务粒度的弹性伸缩组件。主要有 VPA, addon resizer 和 HPA。
      此外,各大云厂商也积极贡献提供了多种伸缩组件,例如阿里云提供的 cronHPA。
      在服务粒度的伸缩中,依据执行触发时机不同,可分为:立即执行,定时执行和预测性执行
      1.1 立即执行
      立即执行又细分为垂直伸缩和水平伸缩
      1.1.2 垂直伸缩
      k8s 中的垂直伸缩一般是指调整 Pod 的内存和 CPU 配额
      可用工具: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 中采集历史数据,不过需要额外的配置。
      VPA 在伸缩调整过程中,是通过重启 pod 来使调整生效的,因此基础架构不同,可能会引起服务闪断,需要具体分析服务是否可接受使用 VPA 扩容有上限,具体受 pod 所在宿主机影响。为 pod 分配的资源无法超过宿主机的大小。如果 recommender 计算出的 pod 所需资源超过节点可用资源,将导致 pod 一直 pending。这点可与通过与 cluster autoscaler 共同使用来部分解决。VPA 目前不应与基于内存和 CPU 监控的水平Pod自动调度器(HPA)一起使用,否则可能产生预期外的行为。
      1.1.3 水平伸缩
      根据观察到的CPU使用率(或使用自定义指标支持,基于某些其他应用程序提供的指标)
      自动缩放 replication 控制器,deployment,副本集或状态集中的 pod 数量。
      Horizontal Pod Autoscaler 是 k8s 内置的水平伸缩控制器
      使用 HPA 一般需要先搭建 metrics server,metrics server的搭建及使用将另起一篇文章专门讲述
      HPA 实现为Kubernetes API资源和控制器。资源决定控制器的行为。控制器定期(默认为 15 秒)调整复制控制器或部署中的副本数量,以使所观察到的平均CPU利用率与用户指定的目标相匹配
      1.2 定时伸缩
      kubernetes 官方并没有提供定时伸缩相关的组件,但是其原理并不难,只需按照设定的时间调用 kubernetes 的 API 即可。
      1.3 预测性伸缩
      目前暂无成熟的技术方案。

    2. 节点伸缩
      节点伸缩分为垂直伸缩、水平伸缩、定时伸缩(目前暂无成熟方案,本文不介绍)
      2.1 垂直伸缩
      与 kubernetes 本身关系不大,其功能主要取决于厂商。例如,厂商是否支持主机的升降配,以及升降配过程中是否需要重启主机等。如果需要重启主机,那么在进行伸缩之前,我们需要先把节点上的 pod 驱逐到其他主机。但是如果我们是由于机器资源不够用而扩容的话,这样会加剧资源不够用的情况,造成更大的 pending 状态的 pod。因此,如果如果厂商不支持不重启就能扩容的话,不建议采用这种方式进行节点扩容。
      2.2 水平伸缩
      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 调度策略,来达到最优的结果。

    参考文章:https://segmentfault.com/a/1190000021545907

    展开全文
  • 如何实现K8s Pod核心指标弹性伸缩

    千次阅读 2019-04-24 09:07:47
    Pod核心指标相对于自定义指标而言的,也就是通过采集Pod CPU、内存等核心资源指标实现Pod弹性伸缩。Metrics-server用来替换heapster获取集群资源指标数据的服务,heapster从1.11开始逐渐被废弃了。 metrics-...
  • 2019年10月24日,支付宝大楼的一个会场里,十名选手面对电脑,或运如飞,或苦苦思索,空气里弥漫着紧张的气氛。 原来,这支付宝“超级MA力大赛”的决赛现场。 每年的10月24日支付宝的“代码节”, “You are...
  • flex是弹性布局,一种常见的布局方式,主要体现在布局盒子的灵活性; 关键字:display: flex; 给父盒子设置. 1.1-设置盒子为伸缩盒子/弹性盒子 .box { width: 500px; background: yellow; margin: 0...
  • 弹性计算是指可快速扩展或缩减计算机处理、内存和存储资源以满足不断变化的需求。实现了既满足了计算需求也实现了成本节约。也叫做弹性伸缩(Auto Scaling),可以根据业务需求和策略设置伸缩规则,在业务需求增长时...
  • 简介 :flex布局, 又叫做伸缩布局, 弹性布局, 弹性盒子 其实都是指的是同一个东西 Flex是Flexible Box的缩写,翻译成中文就是“弹性盒子”,用来为盒装模型提供最大的灵活性。任何一个容器都可以指定为Flex布局。...
  • 变形缝是指在建筑物因温差、不均匀沉降以及地震而可能引起结构破坏变形的敏感部位或其它必要的部位,预先设缝将建筑物断开,令断开后建筑物的各部分成为独立的单元,或者是划分为简单、规则的段,并令各段之间的缝...
  • 其特点在于自动容错,位置感知性调度和可伸缩性。二、RDD的属性 1.一组分片。即数据集的基本组成单位。对于RDD来说,每个分片都会被一个计算任务处理,并决定并行计算的粒度。用户可以在创建RDD时...
  • 通过提供消息传递和消息排队模型再分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步功能。 大致过程这样的: 发送者把消息发送给消息服务器,消息服务器将消息存放在队列/主题topic中...
  • 云服务器详解 服务器是我们每个人基本都会接触到或者...云服务器(Elastic Compute Service,ECS)的标准定义是指一种简单高效、安全可靠、处理能力可弹性伸缩的计算服务。其管理方式比物理服务器更简单高效。用户无需
  • 1、概念区分:云服务器是一种简单高效、安全可靠、处理能力可弹性伸缩的计算服务,管理方式比物理服务器更简单高效。 虚拟主机是指在网络服务器上分出一定的磁盘空间,用户可以租用此部分空间放置站点及应用组件,...
  • Baas什么?区块链Baas平台开发解决方案带你知晓 ...区块链资源层包括计算资源、通讯资源、存储资源等基础资源服务,为区块链系统提供可扩展的存储、高速的网络、按需弹性伸缩和故障自动恢复的节点
  • 一直以来,云数据库所表现的“即开即用、稳定可靠、安全运行、弹性伸缩、轻松实用”等等优势特点,被电商、游戏、视频、IoT等领域公司列为上云重点关注的部分。 对于云数据库,首先我们要了解什么云数据库? 云...
  • 计算机英文简写含义

    2019-05-16 10:14:46
    11、SEO是搜索引擎优化(Search Engine optimization),是指提高网站浏览量而做的优化手段。 10、SPL是标准的PHP类库(Standard PHP Library)。 9、ECS是阿里云的服务器(Elastic compute service),是一种弹性伸缩...
  • 通过提供消息传递和消息排队模型,它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能,其作为分布式系统架构中的一个重要组件,有着举足轻重的地位。 目前开源的消息...
  • Kubernetes集群和组件

    2020-05-05 16:28:14
    一、知识图谱 二、k8s集群 Kubernetes(k8s)是Google使用Go语言编写的一个自动化ring器操作开源平台,包括部署,调度和节点集群间的扩展。...弹性伸缩 负载均衡:IPVS 适合无状态服务(是指该服务运行的实例不会在本...
  • 什么消息系统?... 目前消息系统已经广泛使用于互联网企业,各类业务系统都有它的身影,一方面其传统的功能特点:系统间调用的异步解耦,减低系统的复杂度、流量的削峰填谷,便于业务弹性伸缩、易于...
  • kafka与rabbitmq

    2019-04-21 00:37:50
    kafka一种高吞吐量的分布式...通过提供消息传递和消息排队模型,它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能 RabbitMQ 采用 Erlang 语言实现的 AMQP 协议的...
  • 通过提供消息传递和消息排队模型,它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能,其作为分布式系统架构中的一个重要组件,有着举足轻重的地位。
  • MQ入门概述

    2020-03-22 18:19:42
    什么MQ?...通过提供消息传递和消息排队模型在分布式环境下提供应用解耦,弹性伸缩,冗余存储、流量削峰,异步通信,数据同步等功能。 大致的过程这样的:发送者把消息发送给消息服务器,消息服务器...
  • 消息队列中间件

    2019-06-28 11:54:59
    通过提供消息传递和消息排队模型,它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能,其作为分布式系统架构中的一个重要组件,有着举足轻重的地位。目前开源的消息...
  • 云服务器(Elastic Compute Service, 简称ECS),一种简单高效,处理能力可以弹性伸缩的计算服务。ECS的相关术语说明如下: 实例(Instance):一个虚拟的计算环境,由CPU、内存、系统盘和运行的操作系统组成;...
  • 通过提供消息传递和消息排队模型,它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能,其作为分布式系统架构中的一个重要组件,有着举足轻重的地位。 目前开源的消息...
  • 通过提供消息传递和消息排队模型,它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能,其作为分布式系统架构中的一个重要组件,有着举足轻重的地位。 目前开源的消息...
  • 通过提供消息传递和消息排队模型在分布式环境下提供应用解耦,弹性伸缩,冗余存储、流量削峰,异步通信,数据同步等功能。 大致的过程这样的:发送者把消息发送给消息服务器,消息服务器将消息
  • 2020-09-25

    2020-09-26 21:56:35
    云服务器(Elastic Compute Service, 简称ECS),一种简单高效,处理能力可以弹性伸缩的计算服务。ECS的相关术语说明如下: 实例(Instance):一个虚拟的计算环境,由CPU、内存、系统盘和运行的操作系统组成;...
  • ESC:云服务器,一种简单高效,处理能力可以弹性伸缩的计算服务。 实例:一个虚拟的计算环境,由CPU、内存、系统盘和运行的操作系统组成;ESC实例作为云服务器最为核心的概念,其他资源,比如磁盘,IP,镜像,...

空空如也

空空如也

1 2 3 4 5 6
收藏数 110
精华内容 44
关键字:

弹性伸缩是指