资源请求

资源使用

资源请求

我们所有的容器都包含预定义的资源请求值。默认情况下，我们没有设置资源限制。但是我们建议用户设置限制，特别是如果他们在没有大量多余内存容量的节点上运行时，对内存进行限制。（您应希望避免在任何 Kubernetes 节点上耗尽内存，因为内核 memory killer 可能会结束重要的 Kube 进程）

为了提供我们的默认请求值，我们运行应用程序，并想出一种方法来为每个服务生成不同级别的负载。我们监控服务，并调用我们认为最好的默认值。

我们将测量：

空闲负载 - 没有默认值应该低于这些值，但空闲进程没有用，所以通常我们不会根据这个值设置默认值。
最小负载 - 完成最基本的有用工作量所需的值。通常，对于 CPU，这将用作默认值，但内存请求会带来内核 reaping processes 的风险，因此我们将避免将其用作内存默认值。
平均负载 - 什么被认为是平均？问题的答案高度依赖于安装，对于我们的默认值，我们将尝试在一些我们认为合理的负载下进行一些测量。（我们将列出使用的负载）。如果服务有 pod autoscaler，我们通常会尝试根据这些设置缩放目标值。还有默认的内存请求。
压力任务 - 衡量服务应该执行的压力最大的任务的使用情况。（在负载下不需要）。应用资源限制时，请尝试将限制设置为高于此值和平均负载值。
严重负载 - 尝试为服务进行压力测试，然后测量执行此操作所需的资源使用情况。我们目前不将这些值用于任何默认值，但用户可能希望在平均负载/压力任务和此值之间的某个位置设置资源限制。

GitLab Shell

使用调用 nohup git clone <project> <random-path-name> 的 bash 循环测试负载，以便有一些并发性。在未来的测试中，我们将尝试包括持续并发负载，以更好地匹配我们为其他服务所做的测试类型。

空闲值
- 0 tasks, 2 pods
  - cpu: 0
  - memory: 5M
最小负载
- 1 tasks (one empty clone), 2 pods
  - cpu: 0
  - memory: 5M
平均负载
- 5 concurrent clones, 2 pods
  - cpu: 100m
  - memory: 5M
- 20 concurrent clones, 2 pods
  - cpu: 80m
  - memory: 6M
压力任务
- SSH clone the Linux kernel (17MB/s)
  - cpu: 280m
  - memory: 17M
- SSH push the Linux kernel (2MB/s)
  - cpu: 140m
  - memory: 13M
  - 上传连接速度可能是我们测试期间的一个因素
严重负载
- 100 并发克隆, 4 pods
  - cpu: 110m
  - memory: 7M
默认请求
- cpu: 0 (来自最小负载)
- memory: 6M (来自平均负载)
- 目标 CPU 平均值: 100m (来自平均负载)
推荐限制
- cpu: > 300m (大于压力任务)
- memory: > 20M (大于压力任务)

Webservice

可以查看 Webservice 资源文档。

Sidekiq

可以查看 Sidekiq 资源文档。

KAS

在我们进一步了解用户需求之前，我们预计用户将按照以下方式使用 KAS。

空闲值
- 0 agents connected, 2 pods
  - cpu: 10m
  - memory: 55M
最小负载:
- 1 agents connected, 2 pods
  - cpu: 10m
  - memory: 55M
平均负载: 1 agent is connected to the cluster.
- 5 agents connected, 2 pods
  - cpu: 10m
  - memory: 65M
压力任务:
- 20 agents connected, 2 pods
  - cpu: 30m
  - memory: 95M
严重负载:
- 50 agents connected, 2 pods
  - cpu: 40m
  - memory: 150M
超重负载:
- 200 agents connected, 2 pods
  - cpu: 50m
  - memory: 315M

此 chart 设置的 KAS 资源默认值足以处理 50 个代理场景。如果您打算达到我们认为的 Extra Heavy Load，那么您应该考虑调整默认值以扩大规模。

默认值: 2 pods，每个
- cpu: 100m
- memory: 100M