尖刻的kubernetes HPA，具有公制数量的pubsub未破解消息

Question

当前，我们有一条数据流管道：api调用-> google pub / sub-> BigQuery。 api调用的次数取决于网站的访问量。

我们创建了一个kubernetes部署（在GKE中），用于将数据从发布/订阅中提取到BigQuery。此部署具有带有metricName: pubsub.googleapis.com|subscription|num_undelivered_messages和targetValue: "5000"的水平容器自动缩放器（HPA）。这种结构能够在流量突然增加时自动缩放。但是，它将导致尖锐的缩放。

我所说的尖刻如下：

1. 未确认邮件的数量将超过目标值
2. 自动定标器将增加豆荚的数量
3. 由于未确认的数量将缓慢减少，但由于其仍高于目标值，因此自动缩放器仍将增加容器的数量->直到我们达到自动缩放器中的容器的最大数量为止
4. 未确认的数量将减少，直到降至目标以下并保持在非常低的水平
5. 自动缩放比例会将Pod的数量减少到最小Pod的数量
6. 未确认消息的数量将再次增加，并且将与（1）相似，并且会进入尖峰循环/循环

以下是尖峰图表（流量上升，但稳定且不尖峰）： The spiky number of unacknowledged message in pub/sub

如果未确认消息的数量超过20k，我们将在堆栈驱动器中设置一个警报，在这种情况下，它将始终频繁触发。

在这种情况下，有没有办法使HPA变得更稳定（非尖峰）？

任何评论，建议或答案都很好。

谢谢！

Answer 1

我一直在处理相同的行为。我最终要做的是使用移动平均线平滑num_undelivered_messages。我设置了一个k8s cron，每分钟将最后20分钟的时间序列数据的平均值发布到自定义指标。然后将HPA配置为响应自定义指标。

这很好，但并不完美。我观察到，一旦平均值收敛到实际值，HPA就会将服务缩减得太低。因此，我最终仅添加了一个常数，因此自定义指标只是平均值+常数。我发现我的具体案例的价值为25,000。

有了这个，并且在输入targetAverageValue之后，自动缩放非常稳定。

我不确定这是由于缺陷还是仅由于num_undelivered_messages指标在高负载下的性质所致。

编辑： 我使用了stackdriver / monitoring golang软件包。有一种简单的方法可以汇总时间序列数据。参见“汇总数据” https://cloud.google.com/monitoring/custom-metrics/reading-metrics

https://cloud.google.com/monitoring/custom-metrics/creating-metrics