默认的 HPA 扩容策略，能够满足绝大数场景，但业务的场景更多，因此也出现了匹配业务熟悉具备更高精确度的对 Pod 进行扩缩容的组件如：
● 业务属性跟时间相关，通过 CronHPA (腾讯容器服务为 HPC 功能) 来控制更精确的扩缩容时间。
● 基于事件的自动扩缩容 KEDA ，通过替换指标的数据源来匹配业务的诉求如离线计算的场景。
● ......
相信社区后续在 Pod 级别的扩缩容上也还会出现越来越丰富的组件，以适配业务的多样的场景来提高弹性伸缩的精确度。
自动化的程度如果要通过一个可衡量的数值来参考，可以考虑选择运维或开发在IT资源管理上投入的时间，时间越少，自动化程度越高， 投入的时间越少，也意外着投入的人力成本越低。这里的时间还可以继续拆分到投入扩缩容 IT 资源的时间和对 IT 资源资源维护的时间如故障替换等。
想要提高弹性伸缩的自动化程度，理解弹性的基本工作原理是最基础的要求。下文也会详细展开 Kubenetes 服务下的几个基本的弹性伸缩组件的工作原理。
在理解弹性伸缩工作原理的基础上，企业往往会结合自身的运维平台，将弹性伸缩集成进去，成为运维系统的一部分，以结合业务的诉求。因此自动化也要求云服务商对弹性伸缩的可配置性、API 的易用性也有较高的要求，如若各位读者有使用腾讯云容器服务相关的弹性伸缩 API，欢迎各位给产品提供优质的建议。
之所以将弹性伸缩的可观测性单独作为一个影响运维成本的关键点，是因为当前 Kubernetes 的弹性伸缩的自动化还不能达到完全脱离运维人员的状态，良好的可观测性能让负责 IT 管理的人员减少心智负担，让业务的运行更加透明。同时也让自动化无法处理的工作能够有更快人员介入处理。
可观测性包含对弹性伸缩对象的盘点和管理、弹性伸缩对象基本的系统指标、运行状态的监控、以及故障告警等等。
云厂商的产品包括腾讯云容器系列的产品都会提供一些基本的可观测性的产品能力，也可以采用社区的 Grafana 等仪表盘工具构建企业自己的可观测性平台。
业务的扩容相对来讲是一件低风险的事情，最大的影响是支出可能会增多，但对业务本身来说是一件安全的事情。但是弹性伸缩不仅有扩容，也有缩容。业务被缩容之后，针对下次的突发流量是否能快速扩容？特别是如果剩余资源被别的业务抢占，或云上的资源售罄的情况下，临时再扩容是一件风险比较大的事情。
业务的应用之间存在依赖关系时，一个应用扩缩容后，另一个应用是否也该扩缩容？是否会有连锁反应？这些都是可能导致系统故障的风险点。
上面提到的弹性伸缩基于的特征和属性、策略、对象都有很多种，任何一种方式都可以弹性伸缩，到底哪一个才是最好最适合的扩容方式？往往需要非常强的技术积累和经验，很难自动化。
使用弹性不当，导致账单爆涨的案例比比皆是。要理解弹性伸缩工作的原理、才能更准确的使用弹性伸缩，降低业务成本，提高业务稳定性。建议使用 Kubernetes 弹性伸缩能力之前先详细阅读 Kubernetes 弹性伸缩相关官方文档或 Git 文档。
· ClusterAutoScaler: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler
· HPA: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
· VPA：https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler
Kubernetes 弹性领域仍存在的问题 灵敏度存在的问题弹性伸缩需要监控到“变化”（这个变化指的是上面提到的弹性伸缩的特征和属性），才能根据提前制定的“策略”，对要操作的“对象”进行弹性伸缩。但是从实际业务流量的变高，到负载量“变化”，再到监控组件监控到负载量变化，到最后引发弹性扩缩容发生往往需要较长的时间。
此外，为了保证 Pod 高的 QoS，防止重要 Pod 被 Kubernetes 的调度器驱逐，用户会将容器设置相同的 Request 和 Limit，此时用户实际的资源使用率最多只有 100%。假设用户使用 HPA，且阈值设置为 90%，则每次扩容，副本数最多只能扩容到现在的 1/0.9=1.11 倍。倘若此时流量突然增大到必须使用现在两倍的资源量，即两倍的副本数，则需要扩容 8 次才能承载两倍的流量：（1（1.18）= 2.14），很明显这个扩容步骤过多，周期过长。