[弹性扩缩容] 求问生产中弹性扩缩容最佳实践

[Charlie17Li]

RT ，求问实际生产集群中，弹性扩缩容是怎么做的呢🤔，lz 最近看了一些相关的技术博客，以及一些云厂商的 HPA 与 VPA 相关的用户手册，目前感觉下来：

1. HPA 相比于 VPA 应用得更多，VPA 感觉风险挺大的，没有啥最佳实践
2. HPA 看得比较多的就是 CronHPA ，以及，流量预测+HPA ，但两者实际都属于提前扩容，当面对紧急扩容时，仍存在一些问题，这方面的博客貌似不多。

下图是我目前针对 VPA 和 HPA 想到的三个问题，请问实际生产中有什么好的解决方法吗？

针对 HPA 主要是应用启动慢（假设 Java 应用），包括启动时需要与数据库、缓存等建连，时间不可控；其次，应用刚启动通常需要预热才能正常对外提供服务？

针对 VPA 主要是当扩容时，存在回弹风险，即增加应用容器的可用资源时，Node 节点的资源不够，从而导致应用容器被驱逐。

[seers]

我司还是传统压测固定 pod 数，java 启动太慢了

[luozic]

@seers graalvm +aot +预热，现在 Java 变化不少了

[standchan]

我们使用 k8s 的 hpa 和 cronhpa 。节点资源方面，如果节点不够用了会自动申请新的节点加入。没用 vpa ，vpa 不是特别适合实际生产。
如果你启动的比较慢，那就把阈值调整一点。另外，在服务准备的过程中，其他服务其实是可以超过一些 request 的，也没关系。

[Charlie17Li]

@standchan 好的，感谢，不过没有太理解 “在服务准备的过程中，其他服务其实是可以超过一些 request 的，也没关系”，这个对 HPA 有啥影响吗 🤔

另外，今天刚看到 Tencent 在 2023 KubeCon 关于容器热迁移的分享，貌似能够与 VPA 做一定的融合，所以我想多问一下“vpa 不是特别适合实际生产”的原因还有哪些呢🤔

[dropdatabase]

@Charlie17Li 1. 阈值可以大于 100% 2. 可以配置延时生效 3.可以配合其他指标扩

[standchan]

@Charlie17Li #4 @Charlie17Li #4 在新的服务准备过程中，旧的服务因为请求的增多 cpu/mem 也会增多，可能出现超过 cpu requests ，mem requests 的情况。vpa 存在即合理，但是怎么说呢，线上环境更多的策略意味着更多的复杂度，如果是 hpa 能完全对付的，那感觉就用 hpa 好了。楼下说的可以配合其他指标也是不错的办法，配合缓存 mq 队列长度等等来进行扩容，不一定是 cpu 。