这是个创建于 603 天前的主题，其中的信息可能已经有所发展或是发生改变。
RT ，求问实际生产集群中，弹性扩缩容是怎么做的呢，lz 最近看了一些相关的技术博客，以及一些云厂商的 HPA 与 VPA 相关的用户手册，目前感觉下来：
- HPA 相比于 VPA 应用得更多，VPA 感觉风险挺大的，没有啥最佳实践
- HPA 看得比较多的就是 CronHPA ，以及，流量预测+HPA ，但两者实际都属于提前扩容，当面对紧急扩容时，仍存在一些问题，这方面的博客貌似不多。
下图是我目前针对 VPA 和 HPA 想到的三个问题，请问实际生产中有什么好的解决方法吗？
针对 HPA 主要是应用启动慢（假设 Java 应用），包括启动时需要与数据库、缓存等建连，时间不可控；其次，应用刚启动通常需要预热才能正常对外提供服务？
针对 VPA 主要是当扩容时，存在回弹风险，即增加应用容器的可用资源时，Node 节点的资源不够，从而导致应用容器被驱逐。
 | 1 seers 2024-04-20 21:10:39 +08:00 via iPhone 我司还是传统压测固定 pod 数，java 启动太慢了 |
 | 3 standchan 2024-04-20 21:49:09 +08:00 我们使用 k8s 的 hpa 和 cronhpa 。节点资源方面，如果节点不够用了会自动申请新的节点加入。没用 vpa ，vpa 不是特别适合实际生产。 如果你启动的比较慢，那就把阈值调整一点。另外，在服务准备的过程中，其他服务其实是可以超过一些 request 的，也没关系。 |
 | 4 Charlie17Li OP @standchan 好的，感谢，不过没有太理解 “在服务准备的过程中，其他服务其实是可以超过一些 request 的，也没关系”，这个对 HPA 有啥影响吗 另外，今天刚看到 Tencent 在 2023 KubeCon 关于容器热迁移的分享，貌似能够与 VPA 做一定的融合，所以我想多问一下“vpa 不是特别适合实际生产”的原因还有哪些呢 |
 | 5 Pbe2RsrnVcPrF 2024-04-21 00:32:28 +08:00 via iPhone @Charlie17Li 1. 阈值可以大于 100% 2. 可以配置延时生效 3.可以配合其他指标扩 |
| 6 standchan 2024-04-21 08:35:07 +08:00 @Charlie17Li #4 @Charlie17Li #4 在新的服务准备过程中，旧的服务因为请求的增多 cpu/mem 也会增多，可能出现超过 cpu requests ，mem requests 的情况。vpa 存在即合理，但是怎么说呢，线上环境更多的策略意味着更多的复杂度，如果是 hpa 能完全对付的，那感觉就用 hpa 好了。楼下说的可以配合其他指标也是不错的办法，配合缓存 mq 队列长度等等来进行扩容，不一定是 cpu 。 |
Select Language