动态缩放以实现有状态的最佳做法

Question

背景

我使用分片的mongodb和elasticsearch statefulsets在kubernetes集群中运行应用程序。我为应用程序中的部署组件设置了水平Pod自动缩放器，一切正常。

问题

流量增加时会出现问题。我的服务器部署可以很好地扩展，但是mongodb碎片和elasticsearch节点无法处理这么多的流量并限制了总体响应时间。

简单的解决方案是使用更多的碎片，更多的副本来配置这些有状态集。让我感到烦恼的是，流量高峰每天发生约3-4个小时，因此让所有这些男孩在一天中的其余时间里闲坐都是很浪费的。

我做了一些研究，看起来一般来说数据库不应该动态扩展/扩展，因为它会消耗大量的网络和磁盘io，只是为了在它们之间进行复制。在按比例放大和按比例缩小期间，还可能会丢失数据和出现不一致的情况。

问题

如果可能，在mongodb，elasticsearch ...和一般数据库中处理动态缩放的正确方法是什么？
如果没有，那么我该怎么办才能节省我的云费用，因为我们每天只需要短时间从数据库Pod中获得最大的电力即可。

Answer 1

您应该阅读有关Kubernetes自动缩放的知识-HPA。

Horizo​​ntal Pod Autoscaler基于观察到的CPU利用率（或借助自定义指标支持，基于某些其他应用程序提供的指标）自动缩放复制控制器，部署，副本集或状态集中的pod数量。请注意，水平Pod自动缩放不适用于无法缩放的对象，例如DaemonSets。

Horizo​​ntal Pod Autoscaler被实现为Kubernetes API资源和控制器。该资源确定控制器的行为。控制器会定期调整复制控制器或部署中的副本数，以使观察到的平均CPU利用率与用户指定的目标相匹配。

使用HPA，您还必须注意卷安装和数据延迟。

---

正如@Serge在评论中提到的那样，我建议检查MongoDB和Elasticsearch本身提供的本机扩展群集选项。

看看

• MongoDB运算符documentation
• Elasticsearch运算符documentation
• Elasticsearch未来版本autoscaling

我对MongoDB和使用Kubernetes的Elasticsearch不太熟悉，但是也许这些教程可以帮助您：

• https://medium.com/faun/scaling-mongodb-on-kubernetes-32e446c16b82
• https://www.youtube.com/watch?v=J7h0F34iBx0
• https://kubernetes.io/blog/2017/01/running-mongodb-on-kubernetes-with-statefulsets/
• https://sematext.com/blog/elasticsearch-operator-on-kubernetes/#toc-what-is-the-elasticsearch-operator-1

---

如果您使用helm，请看banzaicloud Horizontal Pod Autoscaler operator

您可能不希望也不能编辑Helm图表，而只是添加自动缩放功能。几乎所有图表都支持自定义注释，因此我们认为仅通过向部署中添加一些简单注释就可以设置自动缩放功能是个好主意。

我们已经开源了“水平Pod自动缩放器”运算符。如果您提供正确的自动缩放注释，此运算符将监视您的Deployment或StatefulSet并自动创建Horizo​​ntalPodAutoscaler资源。

---

希望您觉得这有用。