【发布时间】:2021-11-12 07:37:26
【问题描述】:
我已经配置了容器内存阈值最小 30% 和最大 70% 的 Auto Scalar 规则。当应用程序被使用时,请求将以循环方式发送到实例。因此,当第一个实例达到其阈值但自动标量不会创建新实例时;因为它会根据平均值创建新实例。
作为#1 实例,达到了它的极限;实例正在崩溃,对该实例的请求失败。
我们也可以在实例级别配置规则吗?
【问题讨论】:
标签: cloud cloud-foundry autoscaling
我已经配置了容器内存阈值最小 30% 和最大 70% 的 Auto Scalar 规则。当应用程序被使用时,请求将以循环方式发送到实例。因此,当第一个实例达到其阈值但自动标量不会创建新实例时;因为它会根据平均值创建新实例。
作为#1 实例,达到了它的极限;实例正在崩溃,对该实例的请求失败。
我们也可以在实例级别配置规则吗?
【问题讨论】:
标签: cloud cloud-foundry autoscaling
这适用于 PCF Auto Scaler(不是同名的 OSS Cloud Foundry 项目)。
使用 PCF Auto Scaler 的基于内存和 CPU 的自动缩放很难正确配置,并且通常不会按照用户期望的方式运行。我相信你在这里所经历的就是其中的一部分。另一个棘手的问题是,一些应用程序运行时将独立于操作系统进行自己的内存管理。因此,从操作系统的角度来看,这是用于自动扩展的指标,看起来您使用的内存比实际使用的更多,这可能会过早地扩展,并可能阻止应该发生的缩减。
我的建议是您尝试自动缩放代表您的实际目标的指标,而不是系统的状态。如果您有一个 Web 应用程序,那么使用基于延迟的 Auto Scaling 规则非常有意义。您可以配置您的 Auto Scaling 规则,以便满足为您的应用程序设置的延迟服务目标。
您也可以使用基于 HTTP 吞吐量的缩放,尽管旧版本的自动缩放器存在严重的性能错误,所以 check here to make sure you're patched for that。
如果这些都不起作用,那么我建议缩减自定义指标。您可以导出对您的应用程序有意义的内容,例如它正在处理的工作量(每秒处理的作业数)或对您的应用程序有意义的任何内容。
【讨论】: