时间窗口的设置，当前 HPA 控制器中针对扩容和缩容分别有一个时间窗口，即在该窗口内会尽量保证 HPA 扩缩容的目标副本数处于稳定的状态，其中扩容是3分钟，而缩容是5分钟。若时间窗口设置得较小，则副本数可能频繁变化导致集群状态不稳定；若时间窗口设置得较大，则扩缩容反应时间太慢，无法有效应对突发流量。
影响精确度的问题扩容是有可能失败的，这对流量突发场景可能是致命的，例如：云上的资源是有可能售罄的，此时无法扩容。
当前 Cluster Autoscaler 的节点扩缩容主要依赖 Pod 的 Pending 情况，数据过于单一，精度有待提高。并且 Pod 的 Pending 只查看已分配的资源请求和限制，而不是实际的资源使用情况，对业务方来说，过度配置 Pod 是常见的做法，这些都影响着弹性伸缩的精度。
一个集群中存在多个规格的 CVM，扩容和缩容应优先处理哪种规格的 CVM，例如：缩容大规格节点容易引发容器重新调度后的争抢饥饿，缩容小规格节点有可能导致集群最后仅剩下大规格节点。
自动化程度的问题当前的弹性伸缩的各种方法还不够自动化，虽然最后能实现自动的弹性扩缩容，但是它还是建立在前期大量的手工配置上面，这些配置需要很强的业务经验和积累，以及对 Kubernetes 各种弹性伸缩的深刻理解。
以 HPA 为例，目前 TKE 已经支持了五大类共 30 个不同的指标，了解更多详细内容请参见 TKE 自动伸缩指标说明，此外，TKE 还提供了使用自定义指标进行弹性伸缩的方法。这么多的指标该如何选择？那种指标才是最合适自己业务的指标？指标的数值设置成多少合适？副本数的变化范围该如何设置？这里都是影响弹性伸缩的关键因素。
可观测性的问题什么时间因为什么事情造成了什么样的弹性扩缩容结果，这对现有的监控系统来说，还需要做较多努力。因为现有的监控系统通常都是监控某一项指标，它可以监控副本数的变化，可以监控弹性伸缩对象的变化，也可以监控资源使用率的情况，甚至可以监控事件/日志等信息，但是把它们有机的结合在一起，互联互通却是一件相对来讲较为困难的事情，当前弹性伸缩的可观测性方面还需要人工聚合和分析多方面的监控数据，需要高度定制化，对运维人员来说依旧是一件比较繁琐的事情。
其它问题 1、弹性维度当前 HPA 监控的是 Pod 的指标，但是有些 Pod 里存在多个容器，主业务容器高负载的情况下，如果此时 sidecar 容器低负载，并且此 Pod 下所有容器的平均资源利用率低于引发扩容的阈值时，也无法引发扩容，配置的弹性伸缩无效。维度方面还有一个高维度的问题：同样以 HPA 为例，作用对象是 Pod 级别，但产品通常是以应用为中心，HPA 的弹性伸缩缺少“联动效应”，例如一个 Pod 的扩缩容是否可以自动引发同一个应用下其它 Pod 的扩缩容？
2、驱逐选择一个 Pod 资源利用率很低，若它的资源被弹性收缩后，资源被别的负载侵占，此时如果这个 Pod 负载突然变高，但节点又没有剩余可用资源，是该驱逐该 Pod 还是驱逐别的 Pod？
腾讯云容器服务弹性伸缩愿景介绍我们致力于依托腾讯云原生团队提供的各种弹性伸缩服务，帮助客户实现自动化的资源管理，减少人力维护成本以及资源浪费，提升弹性伸缩灵敏度、精确度、自动化、可观测性。具体可参照的 Kubernetes 降本增效标准指南系列的上一篇文章《资源利用率提升工具大全》。
欢迎广大读者试用并且提出您宝贵的建议。