Skip to main content
版本:v1.1

性能调优

推荐配置

在集群规模变大,应用数量变多时,可能会因为 KubeVela 的控制器性能跟不上需求导致 KubeVela 系统内的应用运维出现问题,这可能是由于你的 KubeVela 控制器参数不当所致。

在 KubeVela 的性能测试中,KubeVela 团队验证了在各种不同规模的场景下 KubeVela 控制器的运维能力。并给出了以下的推荐配置:

规模集群节点数应用数量Pod 数量concurrent-reconcileskube-api-qpskube-api-burstCPUMemory
< 200< 3,000< 18,00023005000.51Gi
< 500< 5,000< 30,000450080012Gi
< 1,000< 12,000< 72,00048001,00024Gi

上述配置中,单一应用的规模应在 2~3 个组件,5~6 个资源左右。如果你的场景下,应用普遍较大,如单个应用需要对应 20 个资源,那么你可以按照比例相应提高各项配置。

调优方法

性能瓶颈出现时一般可能会有以下一些不同的表现:

  1. 新创建的应用能够获取到,其直接关联资源获取得到,但间接关联资源获取不到。如应用内包含的 webservice 对应的 Deployment 成功创建,但 Pod 迟迟无法创建。这种情况一般和相应资源的控制器有关,比如 kube-controller-manager。可以排查相应控制器是否存在性能瓶颈或问题。
  2. 新创建的应用能够获取到,关联资源无法获取,且应用渲染本身没有问题 ( 在应用的信息内没有出现渲染错误 )。检查 apiserver 内是否存在大量排队请求,这种场景有可能是由于分发的下属资源,如 Deployment 请求到了 apiserver,但由于先前的资源在 apiserver 处排队导致新请求无法及时处理。
  3. 新创建的应用能够获取到,但是没有状态信息。这种情况如果应用本身的内容格式没有问题,有可能是由于 KubeVela 控制器出现瓶颈,如访问 apiserver 被限流,导致吞吐量跟不上请求的速率。可以通过提高 kube-api-qps / kube-api-burst 来解决。如果限流不存在问题,可以检查控制器所用的 CPU 资源是否已经用满;如果 CPU 过载。则可以通过提高控制器的 CPU 资源来解决。如果 CPU 资源未使用满,但始终保持在同一负载上,有可能是线程数小于所给 CPU 数量。
  4. KubeVela 控制器本身由于内存不足频繁崩溃,可以通过给控制器提高内存量解决。

更多细节可以参考 KubeVela 性能测试报告