也说K8S弹性伸缩
1.手动伸缩
得益于K8S的架构设计，在计算资源足够的情况下，相比于扩容虚拟机手动伸缩应用POD变得异常便捷。但是互联网时代，流量波动大。自动弹性伸缩能最大保证应用的可用性以及服务器成本之间的平衡。
基于什么指标扩缩容、何时扩缩容、扩缩多少比例，扩缩容的速度、扩缩容带来平台计算资源需求的变化都是自动弹性伸缩的痛点。
2.基于什么指标扩容
K8S自带的HPA默认使用CPU、内存来作为扩缩容指标。但是这显然并不是扩缩容的指标银弹。衡量一个服务健康程度、扩缩容需求应从多重因素考虑。比如QPS、RTS、队列堆积、中间件日志（例如PHP进程繁忙）报错等等。
解决方法：
事件驱动自动伸缩 KEDA（https://keda.sh/）。
3.应对瞬时高峰
自动扩展POD虽然好用，但如果扩展的指标（CPU、内存等）设置的过高，如：50%以上，那么，当突然有翻倍的流量过来时，根本来不及扩展POD，服务直接就超时或挂掉。
解决方法：
尽可能的把指标设置在一个较小的值，对以往流量做参考评估，确保了当有2倍、3倍甚至5倍的流量突袭时不至于hold不住。（这也是大多数公司对于核心业务弹性伸缩的保护策略，比如应用CPU超过百分30的时候就应该考虑扩容）
4.定时伸缩容
通常，节点的自动伸缩依赖于POD的自动扩展时资源是否充足。然而在面对定时突然流量高峰的业务时，这种伸缩显然来不及，甚至常常出现高峰10分钟后才扩容的机器，流量已经回到低谷，完全启不到作用。并且，流量到底是因为业务属性很快回落，还是因为扩容不及时导致的流失？
解决方法：
根据自身业务，参考以住流量数量及推广时间，找到规律，提前或定时触发自动扩容（安装插件）。
5.扩容带来的计算节点压力
在大规模扩容的时候可能会遇到NODE节点资源不充足的情况。这个时候如果去手工扩容计算节点，有可能会错过流量高峰导致业务异常，