阿里云在应用扩缩容下遇到的挑战与选型思考中，原生基于 HPA 的应用扩缩容策略逐渐暴露出了哪些不足之

第一，对基于细粒度的应用级负载指标（比如：RT 或者 QPS）进行自动扩缩支持不佳。 作为一个“ The Platform for Platform”项目，Kubernetes 提供的内置能力主要是围绕着容器级别的管理和编排来展开的，但是对于以应用和用户为核心关注点的产品来说，像 CPU 和 Memory 这样粒度的 扩缩容指标就显得太粗粒度了。但是一个“尴尬”的局面是，尽管 HPA 提供了一定程度的自定义指标功能，但它的可扩展性整体上还是不够灵活，自定义指标的可插拔性也不是很好，尤其是当我们希望把指标细化到应用甚至源码层面的时候，经常会碰到需要修改 HPA 代码的情况（而 HPA 代码又是 Kubernetes 代码的一部分）。这就迫切的需要我们在思考如何通过一个扩展性更强的、外部框架来进行细粒度的应用扩缩容策略。 第二，无法支持对应用 Scale To Zero 的需求。我们知道，在Serverless/FaaS 场景中 Scale To Zero 是一个比较典型的自动伸缩场景，可以有效的帮助用户节省闲置资源、降低平台的使用成本。实际上， 现代微服务应用中，很多用户托管在云上的微服务，也都具备 Serverless 应用的一些特征，比如无状态、主要根据流量进行响应等等，对于它们来说，Scale To Zero 也是一个非常重要的诉求。但是，Kubernetes 内置的 HPA 并不关注这个场景，是不会提供出这个能力的。而 EDAS 作为一个全功能通用 PaaS 产品，对 Scale To Zero 的诉求是独立的、无平台锁定的原子性能力，不可能通过引入 OpenFaaS 或者 Knative 这样的 Serverless 专属方案来解决所有用户场景下的问题。 第三，无法支持定时扩缩容的需求。 除了 Scale To Zero 之外，定时扩缩容也是 EDAS 的企业级用户非常迫切需要的一个能力。同样的，对于这个应用运维能力的诉求，也必须是独立的原子性能力，而不能为了一个需求引入一整套其它的平台级方案进来。

答复内容摘自《云原生技术与架构实践年货小红书》，这本电子书收录开发者藏经阁 下载连接：https://developer.aliyun.com/topic/download?id=1127