update at 2024-04-24 14:20:11
parent
f15dfd19bb
commit
c441dce948
|
@ -0,0 +1,19 @@
|
||||||
|
# KEDA 方案
|
||||||
|
|
||||||
|
## 概述
|
||||||
|
|
||||||
|
KEDA 是一个开源的 Kubernetes 基于事件驱动的弹性伸缩器(参考 [KEDA 介绍](../keda/overview))),官方内置了几十种常用的触发器,其中也包含 prometheus 触发器,即可以根据 proemtheus 中的监控数据进行伸缩。
|
||||||
|
|
||||||
|
## Prometheus 触发器使用方法
|
||||||
|
|
||||||
|
参考 [KEDA 基于 Prometheus 自定义指标的弹性伸缩](../keda/prometheus) 。
|
||||||
|
|
||||||
|
## 与 prometheus-adapter 对比
|
||||||
|
|
||||||
|
[prometheus-adapter](https://github.com/kubernetes-sigs/prometheus-adapter) 也支持相同的能力,即根据 Prometheus 中的监控指标数据进行伸缩,但相比 KEDA 的方案有以下不足:
|
||||||
|
|
||||||
|
* 每次新增自定义指标,都要改动 `prometheus-adapter` 的配置,且改配置是集中式管理的,不支持通过 CRD 管理,配置维护起来比较麻烦。
|
||||||
|
* `prometheus-adapter` 的配置语法晦涩难懂,不能直接写 `PromQL`,需要学习一下 `prometheus-adapter` 的配置语法,有一定的学习成本,而 KEDA 的 prometheus 配置则非常简单,指标可以直接写 `PromQL`。
|
||||||
|
* `prometheus-adapter` 只支持根据 Prometheus 监控数据进行伸缩,而对于 KEDA 来说,Prometheus 只是众多触发器中的一种。
|
||||||
|
|
||||||
|
综上,推荐使用 KEDA 方案。
|
|
@ -1,4 +1,4 @@
|
||||||
# HPA 使用自定义指标进行伸缩
|
# prometheus-adapter 方案
|
||||||
|
|
||||||
Kubernetes 默认提供 CPU 和内存作为 HPA 弹性伸缩的指标,如果有更复杂的场景需求,比如基于业务单副本 QPS 大小来进行自动扩缩容,可以考虑自行安装 [prometheus-adapter](https://github.com/DirectXMan12/k8s-prometheus-adapter) 来实现基于自定义指标的 Pod 弹性伸缩。
|
Kubernetes 默认提供 CPU 和内存作为 HPA 弹性伸缩的指标,如果有更复杂的场景需求,比如基于业务单副本 QPS 大小来进行自动扩缩容,可以考虑自行安装 [prometheus-adapter](https://github.com/DirectXMan12/k8s-prometheus-adapter) 来实现基于自定义指标的 Pod 弹性伸缩。
|
||||||
|
|
|
@ -4,16 +4,6 @@
|
||||||
|
|
||||||
KEDA 支持 `prometheus` 类型的触发器,即根据自定义的 PromQL 查询到的 Prometheus 指标数据进行伸缩,完整配置参数参考 [KEDA Scalers: Prometheus](https://keda.sh/docs/latest/scalers/prometheus/),本文将给出使用案例。
|
KEDA 支持 `prometheus` 类型的触发器,即根据自定义的 PromQL 查询到的 Prometheus 指标数据进行伸缩,完整配置参数参考 [KEDA Scalers: Prometheus](https://keda.sh/docs/latest/scalers/prometheus/),本文将给出使用案例。
|
||||||
|
|
||||||
## 对比 prometheus-adapter
|
|
||||||
|
|
||||||
[prometheus-adapter](https://github.com/kubernetes-sigs/prometheus-adapter) 也支持相同的能力,即根据 Prometheus 中的监控指标数据进行伸缩,但相比 KEDA 的方案有以下不足:
|
|
||||||
|
|
||||||
* 每次新增自定义指标,都要改动 `prometheus-adapter` 的配置,且改配置是集中式管理的,不支持通过 CRD 管理,配置维护起来比较麻烦。
|
|
||||||
* `prometheus-adapter` 的配置语法晦涩难懂,不能直接写 `PromQL`,需要学习一下 `prometheus-adapter` 的配置语法,有一定的学习成本,而 KEDA 的 prometheus 配置则非常简单,指标可以直接写 `PromQL`。
|
|
||||||
* `prometheus-adapter` 只支持根据 Prometheus 监控数据进行伸缩,而对于 KEDA 来说,Prometheus 只是众多触发器中的一种。
|
|
||||||
|
|
||||||
综上,推荐使用 KEDA 方案。
|
|
||||||
|
|
||||||
## 案例:基于 istio 的 QPS 指标伸缩
|
## 案例:基于 istio 的 QPS 指标伸缩
|
||||||
|
|
||||||
如果你使用 isito,业务 Pod 注入了 sidecar,会自动暴露一些七层的监控指标,最常见的是 `istio_requests_total`,可以通过这个指标计算 QPS。
|
如果你使用 isito,业务 Pod 注入了 sidecar,会自动暴露一些七层的监控指标,最常见的是 `istio_requests_total`,可以通过这个指标计算 QPS。
|
||||||
|
|
|
@ -70,7 +70,19 @@ const sidebars: SidebarsConfig = {
|
||||||
},
|
},
|
||||||
items: [
|
items: [
|
||||||
'autoscaling/hpa-velocity',
|
'autoscaling/hpa-velocity',
|
||||||
'autoscaling/hpa-with-custom-metrics',
|
{
|
||||||
|
type: 'category',
|
||||||
|
label: 'HPA 使用自定义指标进行伸缩',
|
||||||
|
collapsed: true,
|
||||||
|
link: {
|
||||||
|
type: 'generated-index',
|
||||||
|
slug: '/autoscaling/hpa-with-custom-metrics'
|
||||||
|
},
|
||||||
|
items: [
|
||||||
|
'autoscaling/hpa-with-custom-metrics/prometheus-adapter',
|
||||||
|
'autoscaling/hpa-with-custom-metrics/keda',
|
||||||
|
]
|
||||||
|
},
|
||||||
{
|
{
|
||||||
type: 'category',
|
type: 'category',
|
||||||
label: '事件驱动弹性伸缩(KEDA)',
|
label: '事件驱动弹性伸缩(KEDA)',
|
||||||
|
|
Loading…
Reference in New Issue