精华内容
下载资源
问答
  • 弹性伸缩原理是什么
    2021-11-30 10:29:44

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

    一、计算弹性

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

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

    二、存储弹性

    当存储量增多时,对于传统的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底层信息技术的烦恼。随着人工智能、大数据及物联网等创新型应用在云计算基础上的爆发性发展,云计算的红利正在加速释放。

    更多相关内容
  • 弹性伸缩的学习

    2022-04-24 17:32:58
    弹性伸缩是根据业务需求和策略自动调整计算能力(即实例数量)的服务。在业务需求增长时,弹性伸缩自动增加指定类型的实例,来保证计算能力;在业务需求下降时,弹性伸缩自动减少指定类型的实例,来节约成本。弹性...

    一、概念

            弹性伸缩是根据业务需求和策略自动调整计算能力(即实例数量)的服务。在业务需求增长时,弹性伸缩自动增加指定类型的实例,来保证计算能力;在业务需求下降时,弹性伸缩自动减少指定类型的实例,来节约成本。弹性伸缩不仅适合业务量不断波动的应用程序,同时也适合业务量稳定的应用程序。

    二、工作原理

    1.工作流程

    2.弹性伸缩

    (1)弹性扩容

    (2)弹性缩容

    (3)弹性治愈

    三、产品优势

    1.自动化

    (1)弹性扩张

    • 自动创建指定数量,指定实例的实例,确保伸缩内所有实例的计算能力能满足业务需求。
    • 如果伸缩关联了负载均衡,自动为创建的ECS实例关联负载均衡。负载均衡需将访问请求分发给改ECS实例。
    • 如果伸缩组是ECS类型,且关联了RDS数据库,自动将创建的ESC实例IP添加到RDS访问白名单。该ECS实例可以将应用数据保存到RDS数据库。

    (2)弹性收缩

    • 自动移出数量,指定类型的实例,确保冗余的资源及时的到释放。
    • 如果伸缩关联负载均衡,自动为移出的ECS实例取消关联的负载均衡,负载均衡不再给该ECS实例分发访问请求。
    • 如果伸缩组是ECS类型,且关联了RDS数据库,自动从RDS访问白名单中移出ECS实例IP。该ECS实例不再保存应用数据到RDS数据库。

    2.降成本

            弹性伸缩按需取用,自动释放,提高了资源利用率,有效降低了成本。

    • 无需提前准备冗余的ECS实例,来防止业务高峰期受到影响;无需担心不能及时释放冗余资源,造成成本浪费。弹性伸缩能够适时调整计算能力,降低资源的拥有成本。
    • 无需投入大量人力来调整计算资源,节约了人力成本和时间成本。

    3.高可用

            弹性伸缩支持监测ECS实例的健康状况(即运行状况)。如果发现一台ECS实例未处于运行中状态,则弹性伸缩判定为该ECS实例不健康,并及时自动增加ECS实例替换不健康的ECS实例来确保业务的高可用。弹性伸缩可以有效避免因不能及时发现ECS实例的不健康状态,而导致业务连续性受到影响的情况。

    4.灵活智能

            弹性伸缩的功能丰富、灵活智能、高可用,可以有效降低手动配置的复杂度,提高操作效率。

    • 支持指定提供计算能力的实例类型,即ECS实例。
    • 支持多伸缩模式兼容,可灵活调度应对各种复杂场景。伸缩模式包括固定数量、健康、定时、动态、自定义等,其中动态模式支持通过API对接外部的监控系统。
    • 支持灵活的实例模板,提高创建实例的成功率。
    • 支持丰富的扩缩容策略,可灵活适用于各种业务场景。

    5.易审计

            弹性伸缩自动记录每一个伸缩活动的详细信息,有助于您快速定位问题根源,降低了排查难度。弹性伸缩还提供伸缩组监控功能,可以通过云监控查看伸缩组内的实例运行状态。

    四、使用流程

     

    1.创建伸缩组

            伸缩组是具有相同应用场景的ECS实例集合,是弹性伸缩的核心单元。

    2.创建伸缩配置

            伸缩配置是弹性伸缩自动创建ECS实例时所使用的实例模板。

    3.启用伸缩组

            首次创建伸缩配置后,会自动提示启用伸缩组。

    4.创建伸缩规则

            伸缩规则用于指定扩缩容ECS实例的数量等信息或者智能地设置伸缩组边界值。

    5.创建自动伸缩任务

            创建伸缩规则后,您可以通过自动伸缩任务自动执行伸缩规则,实现自动扩缩容。

    (1)定时任务

            如果可以预测业务量波动的时间,使用定时任务在指定时间自动扩缩容。

    (2)报警任务

            如果需要基于ECS实例的运行指标自动扩缩容,可以使用报警任务。

    展开全文
  • 降本必备—弹性伸缩的基本原理

    千次阅读 2021-11-15 16:19:22
    弹性伸缩的基本原理-推文 ...什么是弹性伸缩 弹性——服务器对业务量的变化应具备一定的容忍度; 伸缩——针对业务量的变化,系统需要在线对资源进行调整。伸缩完成以后,系统对外服务的能力应恢复到正常水

    弹性伸缩(Auto Scaling)是云商提供的、根据自身业务需求自动调整计算能力(即实例数量)的服务。使用该服务时,实例数量可根据工作负载自动进行伸缩,从而在业务需求增长时提供资源支持、在业务需求下降时降低成本。

    SpotMax云资源优化服务及其中的MaxGroup工具可与弹性伸缩功能充分结合,在保障用户服务稳定的前提下,最大化利用Spot实例,从而降低用云成本。==>>> 戳链接了解 SpotMax 与 MaxGroup

    那么,弹性伸缩的基本原理是怎样的?我们如何判断弹性伸缩的效果、进行优化?来一探究竟——

    • 什么是弹性伸缩

    弹性——服务器对业务量的变化应具备一定的容忍度;

    伸缩——针对业务量的变化,系统需要在线对资源进行调整。伸缩完成以后,系统对外服务的能力应恢复到正常水平。

    我们使用弹性伸缩需要达到2大目的:1.服务可靠;2.资源成本节省

    首先,了解一下弹性伸缩服务的部署架构:

    请求从网关服务(即LoadBalance)进来后,到达应用(App)。应用所需要的云主机,往往交给伸缩组来管理。伸缩组会根据主机资源的使用情况,自动购买新机器、回收旧机器,从而让整个集群的资源使用率保持在预期的水平。

    那么,伸缩组如何完成这一系列“炫酷”操作?

    “伸缩”主要集中在两个方向:

    1. 水平方向,通过加节点和减节点,在节点数上面进行调整来达到伸缩效果。
    2. 垂直方向:通过加配置和减配置,来达到伸缩效果。


    除此以外,如果想做好弹性,我们必须对资源的使用情况进行监控。如流程图所示,指标监控服务,负责从APP和集群进行实时的数据采集,采集到的结果会交给autoscaler(伸缩调度器)。Autoscaler会根据预定的策略进行判断(例如,基于CPU或者基于QPS),可能会设定一个伸缩的阈值,如果判断触发了扩缩容,Autoscaler会联系节点组购买机器或者回收机器。伸缩完成的节点,将会和网关进行同步,这样就完成了一个基本的弹性伸缩Web服务。

    • 什么才是优秀的弹性伸缩方案?

    弹性伸缩流程的每一个步骤,都以不同方式影响着弹性伸缩效果:

    首先,监测服务作为弹性伸缩的起点,其数据有效性、实时性,将影响伸缩的准确性和灵敏性;而监测指标的丰富程度,则决定了策略的可操作范围;

    其次,Autoscaler的算法和策略直接决定了伸缩策略的效果。

    再次,伸缩的力度和伸缩的速度会直接的影响到伸缩的效率、资源的使用率。

    最后,应用作为服务本身的载体,其拉取速度、启动速度以及启动的成功率,直接决定了最终的结果。

    综上,一个优秀的弹性伸缩方案,应该尽量满足三个要素。

    • 可靠,它必须具备一定的突增压力的抵抗能力
    • 高效,它能够快速的调整到预期资源的使用量。
    • 经济,它必须在合理范围内尽量的去提高资源的使用率,减少浪费。

    弹性伸缩降本伴侣:SpotMax云资源优化服务

    对于用云企业来说,随着业务增长,用云成本将迅速增加,成为制约企业快速发展的“绊脚石”。SpotMax作为一款云资源优化服务,其中的MaxGroup工具能够充分发挥弹性伸缩的特点,帮助用云企业解决Spot实例被回收、可用资源不足的问题,从而在维护服务稳定的同时,降低用云成本。

    以AWS为例,通常情况下,AWS的弹性伸缩(Auto Scaling)服务在Spot实例不足时,用户无法继续申请实例资源,导致资源长时间短缺,用户面临大流量冲击风险。而MaxGroup在发现autoscaling无法申请资源时,可以及时为用户补充on-demand实例,使服务所需要的资源充盈,而当能继续申请到Spot资源时,MaxGroup会主动将on-demand实例替换为Spot,在服务稳定的前提下,保障成本最低的目标。长期实践证明,SpotMax平均可帮助企业节省60%的用云成本,最多时可降本90%。

    在云端,当资源可以按需伸缩,限制你想象的只有成本。SpotMax解决方案能够助力企业实现极致用云成本节省,释放业务增长潜力。想要了解更多?戳下方链接,一键get你的云成本节省秘籍!

    了解SpotMax

    了解MaxGroup

    展开全文
  • 这节,将学习弹性的将服务部署到多个节点上。 检查 检查部署情况 kubectl get deployments $ kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE mynode 1/1 1 1 10m READY 显示当前/所需副本的比率 UP-...
  • 在上一篇文章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注释
    Resourcemetrics.k8s.ioPod的资源指标,计算的时要除以Pod数目再对比阈值进行判断
    Customcustom.metrics.k8s.ioObject: CRD等对象的监控指标,直接计算指标比对阈值
    Pods : 每个Pod的自定义指标,计算时要除以Pods的数目
    Externalexternal.metrics.k8s.ioExternal:集群指标的监控指标,通常由云厂商实现

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

    最后

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


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

    展开全文
  • 弹性伸缩AS

    千次阅读 2021-04-25 15:03:38
    了解弹性伸缩服务的概念,应用场景 掌握弹性伸缩(Auto Scaling)的功能,组成 掌握弹性伸缩(Auto Scaling)的基本操作 目录 AS的概念 弹性伸缩AS的概念 AS适合的场景 AS使用的功能限制 AS的配置 AS使用流程 ...
  • 弹性伸缩具有应突发、省成本、自动化的业务价值。平台侧将各业务零散、闲置资源进行整合,形成一个大规模资源池,通过弹性调度、库存管控技术在公司运营成本和业务体感中寻求较好的平衡。本文将介绍美团...
  • Kubernetes(k8s)的弹性伸缩

    千次阅读 2020-07-02 21:46:00
    1、什么是K8s的弹性伸缩? 答:Hpa(全称叫做Horizontal Pod Autoscaler),Horizontal Pod Autoscaler的操作对象是Replication Controller、ReplicaSet或者Deployment对应的Pod(k8s中可以控制Pod的是rc、rs、...
  • k8s的弹性伸缩(HPA)

    2021-12-17 06:29:01
    在kubernetes中,我们使用pod对外提供服务。这时候,我们需要以下两种情形需要关注: pod因为不明原因挂掉,导致服务不可用 ...那么今天就来介绍一下在k8s 1.6中的弹性伸缩的实施 k8s是kubernetes的官方简...
  • 云计算之-弹性伸缩

    2021-09-04 12:02:05
    弹性伸缩 弹性伸缩为用户提供高效管理计算资源的策略。用户可设定时间周期性地执行管理策略或创建实时监控策略,来管理VM实例数量,并完成对实例的环境部署,保证业务平稳顺利运行。在需求高峰时,弹性伸缩自动增加...
  • 容器云之弹性伸缩

    2019-10-08 08:03:54
    弹性伸缩是容器云的一个重要特性,也是实施容器云的一个重要业务场景,更是容器云产品的重要卖点。这也是我们非常关注的功能。所以我们一直也在考虑服务弹性伸缩的问题。 目前Kubernetes支持CPU、Memory伸缩策略,...
  • 容器服务弹性伸缩简介本小节将基于使用原理对容器服务弹性伸缩进行简要的描述。本实践基于K8s的业务集群运行在专有云上,对测试业务进行压力测试,主要基于以下三种产品和能力: 利用阿里云的云企业网专线打通专有...
  • 弹性伸缩这种功能,不是很多系统都已经实现了,我们直接用就行了吗,为什么还需要个指南呢。 因为。。。。我们先来看看都有哪些相关知识点吧。。。 弹性伸缩涉及到各种软硬件,各色调度平台,策略和系统,其本身...
  • Kubernetes—弹性伸缩

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

    千次阅读 2019-08-25 11:44:15
    弹性伸缩服务(Elastic Scaling Service)是根据用户的业务需求和策略,自动调整其 弹性计算资源的管理服务。用户根据自己的业务需求自动调整其弹性计算资源,在满足 业务需求高峰增长时无缝地增加 ECS 实例,并在...
  • —— 而我相信,你终将成为那个懂得原理、能做成事还乐于分享的高手。 弹性计算相关背景介绍 云计算底层离不开虚拟化技术,虚拟化让人们有安全感和幸福感,它解决了资源的安全隔离和高效利用两大问题。操作虚拟机,...
  • 弹性伸缩是 Kubernetes

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

    千次阅读 2020-08-11 11:07:24
    k8s 默认提供了多个服务粒度的弹性伸缩组件。主要有 VPA, addon resizer 和 HPA。 此外,各大云厂商也积极贡献提供了多种伸缩组件,例如阿里云提供的 cronHPA。 在服务粒度的伸缩中,依据执行触发时机不同,可分为...
  • 简介:混合云K8s容器化应用弹性伸缩实战1. 前提条件本最佳实践的软件环境要求如下:应用环境:①容器服务ACK基于专有云V3.10.0版本。②公共云云企业网服务CEN。③公共云弹性伸缩组服务ESS。配置条件:1)使用专有云...
  • kubernetes 弹性伸缩布局 在 Kubernetes 的生态中,在多个维度、多个层次提供了不同的组件来满足不同的伸缩场景 1 有三种弹性伸缩: (1) CA(Cluster Autoscaler): Node级别自动扩/缩容cluster-autoscaler组件。...
  • 弹性伸缩具有应突发、省成本、自动化的业务价值。平台侧将各业务零散、闲置资源进行整合,形成一个大规模资源池,通过弹性调度、库存管控技术在公司运营成本和业务体感中寻求较好的平衡。本文将介绍美团...
  • Kubernetes(k8s) Pod 弹性伸缩详解与使用 Kubernetes HPA(Horizontal Pod Autoscaling)Pod水平自动伸缩,通过此功能,只需简单的配置,集群便可以利用监控指标(cpu 使用率等)自动的扩容或者缩容服务中Pod数量,当...
  • autoscaling/v2beta1 2.1 metrics-server安装 2.2 限制CPU和MEM 2.3 自定义metric 前言 HPA(Horizontal Pod Autoscaler)Pod自动弹性伸缩,K8S通过对Pod中运行的容器各项指标(CPU占用、内存占用、网络请求量)的...
  • 前言弹性伸缩介绍Metrics Server聚合 API安装HPA(弹性伸缩实验)缩放间隙基于内存弹性伸缩 弹性伸缩介绍 在使用中我们使用一条 kubectl scale 命令可以来实现 Pod 的扩缩容功能,但是这个毕竟是完全手动操作的,要...
  • HPA到目前为止,已经演进了三个大的版本,在本文中会为大家详细解析HPA底层的原理以及在Kubernetes中弹性伸缩概念的演变历程。 HPA基本原理 HPA是根据实际工作负载水平伸缩容器数目的组件,从中可以提炼出两...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 11,127
精华内容 4,450
关键字:

弹性伸缩原理是什么