问如何决定在Kubernetes中我需要多少个服务实例？

EN

这是一个具有复杂答案的问题，这取决于您的特定应用程序行为和资源利用率。简单地说，“简短的答案”将是：“视情况而定”。这取决于以下主要因素：

• 应用资源利用
  • 内存、CPU、磁盘、套接字等.您的应用程序通常使用: Average吗？马克斯？敏？
  • 应用程序首先遇到哪些瓶颈或资源限制？
  • 应用程序中的哪些例程可能导致高于正常利用率？(这就是很多复杂性的来源.应用程序都是不同的，在响应诸如客户机请求之类的输入时执行许多功能。并非每个函数都具有相同的行为w.r.t。(资源利用)

​

• 高可用性/故障转移
  • 您选择Kubernetes的原因之一可能是因为易于扩展应用程序并使其在没有单一故障点的情况下高度可用。
  • 这可以归结为:您需要如何使用您的应用程序？
  • 在群集/服务器级别上:有多少节点可以下降或不健康，并且仍然能够维护足够的工作节点来处理请求？
  • 在应用程序/容器级别:有多少Pod可以下降并仍然处理请求或预期的操作？
  • 什么级别的服务降级是可以接受的？

​

• 这些独立的应用程序是如何相互作用的&如何一起运行？
  • 另一个非常复杂的问题，如果不一起观察他们的行为，很难确定。
  • 您可以尝试对诸如“每秒请求”和资源利用率&峰值这样的指标进行一些分析。然而，这很难简化成一个单一的数字或常量/线性因果关系。
  • 某些请求或输入会导致子组件的负载“扇出”或放大吗？
  • 例如：
    • 是否有一些SQL查询会导致比其他查询更高的DB负载？
    • 在Pod支持其他Service的过程中，是否有一些操作会导致更高的资源利用率？
    • 在“最大负载”情况下，系统是如何一起工作的？

​

​

如果不进行负载测试，这类事情很难回答。我见过的公司很少这样做！可悲的是，任何这样的问题通常都会发生在生产过程中，并且必须在事后处理。结果是DevOps、Ops或待命工程师不得不处理它，这并不是最好的场景，因为通常这个人不完全了解应用程序的代码，以便对其进行全面的诊断和内省。

如果您正在使用kubernetes，那么使用：

• 用于无状态组件(如pod服务器)的水平pod自动分频器
• 用于app服务器的水平吊舱自动分频器
• DB compoenet的有状态集或操作符(估计集群的初始大小，然后手动增长)

一切都完成了。

随着负荷的增加，东西会自动增长和收缩。

注意:使用@Trin的答案来指导如何配置自动分词器和自动标度标准。有一个由kubernetes度量系统公开的度量列表，可以用于自动缩放。