用 KEDA 根据工作负载进行快速扩容

太长不看版:用单一指标指导单一工作负载进行扩缩容实在是太低效了。

历史问题

众所周知,Kubernetes 有个亲生的 HPA 组件,在云原生早期,这个名义上的自动扩缩容的能力给 Kubernetes 赢得了不少掌声。当然现在回头看看,仅仅根据 CPU 和内存这样“贫瘠”的指标,不论是用于判断负载水平,还是用于计算扩容目标,都不是很够用的。这个阶段里,HPA 的扩缩容效率也是广受诟病的一个问题,在一个多级微服务调用的业务场景里,压力是逐级传递的,下图展示了一个常见情况:

turn

如上图,用户流量进入集群之后:

  1. 首先在 Deploy A 造成负载,指标变化迫使 Deploy A 扩容
  2. A 扩容之后,吞吐量变大,B 受到压力,再次采集到指标变化,扩容 Deploy B
  3. B 吞吐变大,C ..

这个逐级传递的过程不仅缓慢,而且可以说是步步惊心——每一级的扩容都是直接被 CPU 或内存的飙高触发的,被“冲垮”的可能性是普遍存在的。这种被动、滞后的方式,很明显是有问题的。

推陈出新

造成 HPA 窘境的原因之一,就是“自扫门前雪”,每个 Pod 都只能根据自身负载情况来进行扩缩容决策。如果能够直接根据业务流量的变化进行决策,并且将流量流经的所有微服务进行扩缩容,看起来情况就会好很多了。 HPA 的自定义指标支持,给这个问题了一个可行的方案。该能力让 HPA 可以用其它的指标来作为扩缩容的触发器,例如我们可以用 Promethues 采集消息中间件的深度或者负载均衡器的队列长度,作为一个更能如实反映业务流量的指标,直接用来触发相关的多个微服务的扩缩容,如下图所示:

prom-adapter

在上图中:

  1. Prometheus 采集消息队列和负载均衡等更能反映业务流量的指标
  2. 使用 Prometheus Adapter 将 Promethues Metrics 转换为 Kubernetes 的 Aggregated API
  3. HPA 使用自定义指标,同时对多个应用进行扩缩容。

这中间涉及到的 Prometheus Adapter,通过配置文件完成步骤 2 的转换:

- seriesQuery: '{__name__=~"^container_.*_total",container!="POD",namespace!="",pod!=""}'
  resources:
    overrides:
      namespace: {resource: "namespace"}
      pod: {resource: "pod"}
  seriesFilters:
  # since this is a superset of the query above, we introduce an additional filter here
  - isNot: "^container_.*_seconds_total$"
  name: {matches: "^container_(.*)_total$"}
  metricsQuery: "sum(rate(<<.Series>>{<<.LabelMatchers>>,container!="POD"}[2m])) by (<<.GroupBy>>)"

当然,完全可以自行实现 Aggregated API 来支持这种指标的采集和呈现工作。Prometheus 所提供的大量 Exporter 是吸引我们写这种古怪语法的最大动力。

那么如果是 KEDA 的话,这个问题又如何呢?KEDA 提供了几十个被称为 Scaler 的东西,其中除了 Promethues 之外,还包括 Kafka、Redis、PostgreSQL 等多种选择。所以在很多场景中,无需 Promethues,也能使用 Scaler 完成对输入指标的读取和判断。下面用 KEDA 为例,看看这种伸缩方法的具体实现。

KEDA

假设一个容器化应用由多个工作负载组成:

  • Ingress:负责接收业务流量
  • Backend 1、Backend 2:负责处理 Ingress 发来的任务
  • Database:数据库

我们希望达成的效果是 —— Ingress、Backend 1、Backend 2、Database,实例数量保持在 1:2:1.5:2 的关系,Keda 的大致流程如下图所示:

images

首先使用 Helm 安装 KEDA:

$ helm repo add kedacore https://kedacore.github.io/charts
$ helm install keda kedacore/keda --namespace default
NAME: keda
LAST DEPLOYED: Wed Nov 29 18:56:36 2023
NAMESPACE: default
STATUS: deployed
REVISION: 1
...

随便创建几个工作负载,冒充微服务:

$ kubectl create deploy ingress --image=nginx
deployment.apps/ingress created
$ kubectl create deploy backend1 --image=nginx
deployment.apps/backend1 created
$ kubectl create deploy backend2 --image=nginx
deployment.apps/backend2 created
$ kubectl create deploy database --image=nginx
deployment.apps/database created
$ kubectl get pods | cut -d - -f 1 | grep -v keda | sort
...
backend1
backend2
database
ingress

运行成功后,我们可以看到,四个微服务,每个微服务都有一个实例。

按照刚才瞎掰的比例,编写一个 ScaleObject

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: bk1
spec:
  scaleTargetRef:
    name: backend1
  triggers:
  - type: kubernetes-workload
    metadata: 
      podSelector: 'app=ingress'
      value: '0.5'
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: bk2
spec:
  scaleTargetRef:
    name: backend2
  triggers:
  - type: kubernetes-workload
    metadata: 
      podSelector: 'app=ingress'
      value: '0.67'      
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: db
spec:
  scaleTargetRef:
    name: database
  triggers:
  - type: kubernetes-workload
    metadata: 
      podSelector: 'app=ingress'
      value: '0.5'

上述代码引入了 kubernetes-workload 类型的触发器,他会监控 app=ingress 的容器,并对 scaleTargetRef 中提到的工作负载数量比例进行扩缩容。

提交到集群之后,会看到实例数量数量发生了变化:

$ kubectl get pods | cut -d - -f 1 | sort | uniq --count
...
   2 backend1
   2 backend2
   2 database
   1 ingress
   3 keda

我们把 Ingress 扩容到 2 实例,再次统计:

$ kubectl scale deployment ingress --replicas=2
deployment.apps/ingress scaled
$ kubectl get pods | cut -d - -f 1 | sort | uniq --count
...
   4 backend1
   3 backend2
   4 database
   2 ingress
   3 keda

可以看到,的确是按照我们设定的比例,同步产生了缩放。如果缩减 Ingress 服务实例数,几分钟之后,其它工作负载也会随之缩容。

$ kubectl scale deployment ingress --replicas=1
deployment.apps/ingress scaled
$ kubectl get pods | cut -d - -f 1 | sort | uniq --count                                                         \
...
   2 backend1
   2 backend2
   2 database
   1 ingress

结论

虽说云原生架构的复杂性问题越来越被强调,但是这一生态的宗旨应该还是没有变化——用简单的透明的手段解决复杂问题。

Avatar
崔秀龙

简单,是大师的责任;我们凡夫俗子,能做到清楚就很不容易了。

comments powered by Disqus
下一页
上一页