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