弹性伸缩是公有云和Kubernetes独有的特性，如何设计使用弹性伸缩是SRE工作的重点之一。

什么样的场景适合弹性伸缩

1. 流量具有明显潮汐的业务，如金融、教育等行业，此类弹性伸缩主要以降本为目的
2. 流量具有突发性、峰尖突出的业务，如社交、电商等行业，此类弹性伸缩主要以保持服务可用性为主要目的，兼顾降本

 什么样的场景不适合弹性伸缩

1. 以有状态服务为主的业务，如数据库、存储等相关服务，此类存在启动时间长、数据敏感等问题，频繁的弹性伸缩势必会造成服务的稳定性影响及数据不完整问题
2. 业务流量异常稳定的业务，如电子邮箱
3. 对稳定性和安全性有严格要求的业务，如军工行业

弹性伸缩的要点

1. 伸缩所依仗的指标，如CPU、内存、时间、第三方指标等
2. 测试及历史监控数据，用来得出服务的潮汐图
3. 完备的容量规划，结合第2项的数据，得出弹缩的数量范围
4. 业务容忍度，通过测试得出影响业务体验的具体数值，如服务最低数量、单位时间需要完成的弹缩数量
5. 缩的指标，缩的早了影响服务稳定，缩的晚了增加成本

弹性伸缩的常见场景        

       公有云

        以阿里云为例，如果服务已完成容器化，那么可以使用HPA/Keda+ESS的组合方式，设计弹性伸缩。伸缩的场景大致分为两种：

1. 以时间为规则的伸缩，如证券交易所，系统有着严格的运行时间，在设计伸缩计划的时候，Pod和节点伸缩可以单独按照时间规则撰写规则，具体在时间数值上，节点的伸缩时间要早于或晚于Pod的时间，因为节点加入Kubernetes集群需要时间，也要保证Pod先优雅的退出；当然如果服务还没有进行容器化，那么也可以单独使用ESS服务，只是要设置系统模板以及启动模板
2. 以资源监控为规则的伸缩，首先是Pod的伸缩，一般分类两类，第一种是以自身资源为规则，如CPU和内存，这个使用HPA即可实现， 第二种则是以第三方资源为规则，如网关流量、消息队列等，这个则就要使用Keda进行实现。而节点的伸规则一般使用Kubernetes的事件触发，缩规则则使用节点自身的资源规则。这种规则下，Pod的规则敏锐度和节点的启动时间是关键点，一般的经验中，我们会对Kubernetes的节点采用二八规则，即固定节点预留20%的空闲资源，保障在流量快速增长初期可以快速的完成Pod调度，这20%用完后再触发新的节点的扩充，保障服务的平稳，另外阿里云的ESS也可以使用预启动功能单独缩短节点的启动时间，或者在规律的服务潮汐规律下，有可以使用再加一个时间规则，这个规则和Kubernetes的事件规则不冲突，可以做为互补。               

        多云

          因容灾考虑或者业务分布问题，比如全球业务等，许多公司采用了多云架构，比如国内采用阿里云，海外采用AWS或者微软云；或者阿里云+腾讯云双云灾备结构。如果多云承载的业务不相同的话，那弹性伸缩计划只需照着上面的方式在每个云上独立布置即可。但如果是灾备架构的话，在设置弹性伸缩计划的时候，则需要不同的考虑。一般灾备主要是两种场景：

1. 主备模式，即平时主要是在主云山运行，备用云只运行少量Pod，或者零Pod，主云出现故障不可用后，触发备用云。这个整体的设计一般是利用域名的全局流量管理，将两云的解析设置成主备模式，当主云解析不可访问时，触发主备切换，将流量打入备用云的解析，在流量进入备用云后，触发弹性伸缩规则，完成服务请求承接。这个方案中，使用自身资源指标做为规则的HPA不太适用，第一是自身资源检测具有滞后性，第二则是HPA最低Pod数量不能为零。所以只能采用Keda，而扩充规则的指标则选择网关流量。这里面最重要的点是服务的启动时间，这关系着服务的中断时长，除了要选对指标外，还要调高规则触发的敏感度和数量，故障的用户请求挤压，会导致出现短暂数倍的请求压力。另一个影响速度的则是节点伸缩，阿里云的ESS也是支持第三方指标规则触发，如果备用云没有相应功能，则可以通过自研程序的方式实现，可以大大缩短服务扩充时间。
2. 主主模式，即服务均衡运行在多云上，没有主次之分。这种场景一般是那种区域比较大的业务场景，比如面向全球的服务，或者某大区的服务，一来因不同云的布局不同，可以最大化的提升服务体验，比如亚洲使用国内共有云，欧美使用海外云；国内北方使用某云，南方使用另外的云等。二来也可以互为灾备，毕竟体验差一些总好过不可用。这种模式下，相对主备模式，服务的弹缩要求要宽松许多，因为本身就有一定数量服务在运行中，有一定时间缓冲，弹缩方案可以参考主备模式，但在具体规则上，可以视业务要求，适当选择自身资源指标为规则，毕竟在稳定性来说，采集自身指标是最稳定的，调用第三方指标要承受多个不确定性(第三方服务的稳定性、网络稳定性等)

        混合云 

         虽然如今公有云大行其道，但私有云因其数据安全和长期成本低廉考虑，依然是不少大型公司不能放弃的选项，但公有云独有的快速弹缩能力，却是私有云所不能具备的，疫情期间许多公司满世界找服务器的场面可是历历在目。所以混合云架构是一个不错的选项。混合云的架构一般有三种，一种是参考上面公有云的主主模式，即私有云和公有云均部署完整的服务；第二种是按照服务分层模式，即Web入口层、服务层放在公有云，数据层放在私有云，这种模式下需要网络专线打通公有云和私有云；第三种则是私有云为主，公有云为辅的架构，即私有云负责日常主要请求，公有云负责增量请求。第一和第二种架构只需要参考上面公有云的弹缩方案即可，而第三种架构，除了上面的方案外，还有可以采用私有云+Serviceless的方案，Serviceless只需考虑服务层面的伸缩，不用考虑节点的伸缩，在伸缩效率上更加高效。