众所周知，Kubernetes 有个亲生的 HPA 组件，在云原生早期，这个名义上的自动扩缩容的能力给 Kubernetes 赢得了不少掌声。当然现在回头看看，仅仅根据 CPU 和内存这样“贫瘠”的指标，不论是用于判断负载水平，还是用于计算扩容目标，都不是很够用的。这个阶段里，HPA 的扩缩容效率也是广受诟病的一个问题，在一个多级微服务调用的业务场景里，压力是逐级传递的，下图展示了一个常见情况：
图片
如上图，用户流量进入集群之后：
这个逐级传递的过程不仅缓慢，而且可以说是步步惊心——每一级的扩容都是直接被 CPU 或内存的飙高触发的，被“冲垮”的可能性是普遍存在的。这种被动、滞后的方式，很明显是有问题的。
造成 HPA 窘境的原因之一，就是“自扫门前雪”，每个 Pod 都只能根据自身负载情况来进行扩缩容决策。如果能够直接根据业务流量的变化进行决策，并且将流量流经的所有微服务进行扩缩容，看起来情况就会好很多了。HPA 的自定义指标支持，给这个问题了一个可行的方案。该能力让 HPA 可以用其它的指标来作为扩缩容的触发器，例如我们可以用 Promethues 采集消息中间件的深度或者负载均衡器的队列长度，作为一个更能如实反映业务流量的指标，直接用来触发相关的多个微服务的扩缩容，如下图所示：
图片
在上图中：
这中间涉及到的 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 为例，看看这种伸缩方法的具体实现。
假设一个容器化应用由多个工作负载组成：
我们希望达成的效果是 —— Ingress、Backend 1、Backend 2、Database，实例数量保持在 1:2:1.5:2 的关系，Keda 的大致流程如下图所示：
图片
首先使用 Helm 安装 KEDA：
$ helm repo add kedacore https://kedacore.github.io/charts$ helm install keda kedacore/keda --namespace defaultNAME: kedaLAST DEPLOYED: Wed Nov 29 18:56:36 2023NAMESPACE: defaultSTATUS: deployedREVISION: 1...随便创建几个工作负载，冒充微服务：
$ kubectl create deploy ingress --image=nginxdeployment.apps/ingress created$ kubectl create deploy backend1 --image=nginxdeployment.apps/backend1 created$ kubectl create deploy backend2 --image=nginxdeployment.apps/backend2 created$ kubectl create deploy database --image=nginxdeployment.apps/database created$ kubectl get pods | cut -d - -f 1 | grep -v keda | sort...backend1backend2databaseingress运行成功后，我们可以看到，四个微服务，每个微服务都有一个实例。
按照刚才瞎掰的比例，编写一个 ScaleObject：
apiVersion: keda.sh/v1alpha1kind: ScaledObjectmetadata: name: bk1spec: scaleTargetRef: name: backend1 triggers: - type: kubernetes-workload metadata: podSelector: 'app=ingress' value: '0.5'---apiVersion: keda.sh/v1alpha1kind: ScaledObjectmetadata: name: bk2spec: scaleTargetRef: name: backend2 triggers: - type: kubernetes-workload metadata: podSelector: 'app=ingress' value: '0.67' ---apiVersion: keda.sh/v1alpha1kind: ScaledObjectmetadata: name: dbspec: 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=2deployment.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=1deployment.apps/ingress scaled$ kubectl get pods | cut -d - -f 1 | sort | uniq --count /... 2 backend1 2 backend2 2 database 1 ingress虽说云原生架构的复杂性问题越来越被强调，但是这一生态的宗旨应该还是没有变化——用简单的透明的手段解决复杂问题。
本文链接：http://www.28at.com/showinfo-26-35285-0.html一篇学会用 KEDA 根据工作负载进行快速扩容
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： Git 难用？有救！
下一篇： useEffect 实践案例之一
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号