基于 keda事件驱动在Kubernete 集群上的弹性自动缩放应用

在k8s集群中使用keda

概念
工作原理
架构
安装
- step1:添加helm源
- step2:更新源
- step3:部署服务
使用
- step1:编写keda文件（以kikitrade-dev上的kmarket服务为例）
- step2:部署
- step3:查看

概念

KEDA （Kubernetes Event Driven Autoscaler）是一个基于 Kubernetes 的事件驱动自动缩放器。KEDA可以根据需要处理的事件数量来驱动 Kubernetes 中任何容器的进行扩展。

KEDA 是一个单一用途的轻量级组件，可以添加到任何 Kubernetes 集群中。 KEDA 与 Horizontal Pod Autoscaler 等标准 Kubernetes 组件一起工作，可以在不覆盖或复制的情况下扩展功能。使用 KEDA，可以明确映射到想要使用事件驱动规模的应用程序，而其他应用程序继续运行。从而使得 KEDA 能够成为与任意 Kubernetes 上的应用程序一起灵活安全运行成为可能。

工作原理

KEDA在Kubernetes中扮演两个关键角色：

代理 - KEDA 激活和停用 Kubernetes 部署以在没有事件的情况下从零扩展。这是安装 KEDA 时运行的 keda-operator 容器的主要角色之一。
指标 — KEDA 充当 Kubernetes 指标服务器，向 hpa 暴露丰富的事件数据，如队列长度或流延迟，以推动横向扩展。由 Deployment直接从源中使用事件。度量服务是在安装 KEDA 时运行的 keda-operator-metrics-apiserver 容器的主要角色。

架构

安装

step1:添加helm源

helm repo add kedacore https://kedacore.github.io/charts

step2:更新源

helm repo update

step3:部署服务

helm install keda kedacore/keda --namespace custom-metrics  #命名空间提前创建或者使用已有的命名空间

使用

step1:编写keda文件（以kikitrade-dev上的kmarket服务为例）

参数详见：https://keda.sh/docs/2.1/concepts/scaling-deployments/

主要使用了prometheus的数据、metric数据（cpu、mem）、定时任务

cat    kmarket-ScaledObject-promethues.yaml

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:name: blue-kmarket-prometheusnamespace: kikitrade-dev
spec:scaleTargetRef:apiVersion: apps/v1  # 可选参数. Default: apps/v1kind: Deployment     # 可选参数. Default: Deploymentname: blue-kmarket   # 必填参数. Must be in the same namespace as the ScaledObject#envSourceContainerName: {container-name}  # 可选参数，Default: .spec.template.spec.containers[0]pollingInterval:  15   # 可选参数. 检查每个触发器的时间间隔， Default: 30 secondscooldownPeriod:   30   # 可选参数. 上一次触发后等待的时间段报告为活动，然后再将资源缩放回minReplicaCount设定的数量，Default: 300 secondsminReplicaCount: 1     # 可选参数. Default: 0maxReplicaCount: 5     # 可选参数. Default: 100advanced:                                          # 可选参数. Section to specify advanced optionsrestoreToOriginalReplicaCount: true              # 可选参数. 指的是 是否恢复到原始的副本数，如果是false，则会恢复到0，true 则会恢复到原始的副本数，Default: falsehorizontalPodAutoscalerConfig:                   # 可选参数. Section to specify HPA related optionsbehavior:                                      # 可选参数. Use to modify HPA's scaling behaviorscaleDown:                                   # 缩容stabilizationWindowSeconds: 180            # 设置伸缩的窗口期，等待三分钟在开始缩容policies:                                  # 缩容策略# - type: Percent                            # 百分比#   value: 20                                # 20%，向上取整，如7.2，按照8算#   periodSeconds: 60                        # 一分钟内只允许缩容20%的pod数- type: Pods                               # 伸缩对象为podvalue: 2periodSeconds: 60                        # 一分钟内最多缩减pod的数量是2个scaleUp:                                     # 扩容stabilizationWindowSeconds: 60             # 设置伸缩的窗口期，等待一分钟在扩容policies:#- type: Percent#  value: 20#  periodSeconds: 60- type: Pods                               # 伸缩对象为podvalue: 2                                 # 每次扩容新增2个PodperiodSeconds: 60                        # 一分钟内最多扩容pod的数量是2个triggers:# - type: prometheus#   metadata:#     serverAddress: http://prometheus-kube-prometheus-prometheus.prometheus:9090#     metricName: Dubbo Request Concurrent#     threshold: '1'#     query: sum(increase(dubbo_request_concurrent_total{application='kmarket',namespace="kikitrade-dev",pod=~"blue.*"}[2m])/120)# - type: prometheus#   metadata:#     serverAddress: http://prometheus-kube-prometheus-prometheus.prometheus:9090#     metricName: Dubbo Request Success Rate#     threshold: '8000'#     query: avg(dubbo_request_success_rate{application='kmarket', quantile='0.9',namespace="kikitrade-dev",pod=~"blue.*"} or vector(100))- type: prometheusmetadata:serverAddress: http://prometheus-kube-prometheus-prometheus.prometheus:9090metricName: Dubbo Request Latencythreshold: '200'query: sum(dubbo_request_latency_seconds{application='kmarket', quantile='0.9',namespace="kikitrade-dev",pod=~"blue.*"}*1000)- type: cpumetadata:type: Utilizationvalue: "50"- type: memorymetadata:type: Utilizationvalue: "50"- type: cronmetadata:timezone: Asia/Shanghaistart: 50 11 * * *end: 58 11 * * *desiredReplicas: "3"

step2:部署

kubectl apply -f kmarket-ScaledObject-promethues.yaml

step3:查看

step4:测试使用
1）cpu测试（内存测试同理，不再演示）
当前cpu使用率状况如下

进入pod中，模拟cpu压测

for i in `seq 1 4`; do dd if=/dev/zero of=/dev/null & done

在阿里云ack界面上可以看到cpu的使用率已经上来了

cpu上去之后，服务开始扩容，直到cpu降到预设的50%以下，不在扩容

kill掉模拟的cpu脚本，将cpu的使用率降下来，等待一会，结合阿里云界面，会发现pod进入缩容状态

2）自定义数据测试
由于我们在文件中定义的promethues收集的服务的自定义指定是Dubbo Request Latency,因此我们可以在根据PromQL语句在promethues的界面查询下当前的值是多少

为了便于测试，我们将阀值设置到40，然后扩容的状况

kubectl edit scaledobjects.keda.sh -n kikitrade-dev blue-kmarket-prometheus  #直接编辑scaledobjects，将200改为40

可以发现，当将values改为40的时候，在伸缩窗口期过后，pod开始伸缩

结合阿里云ack界面，查看时间信息

当values低于40之后，pod会降下来，所以我们再次将values设定到200，查看pod的伸缩状况

可以看到pod已经缩容回去了

3）定时测试（14:26-14:30扩容到3副本）
扩容前

由于达到设定的开始时间后，但是我们有配置服务的伸缩窗口，所以在等待60秒后，开始扩容

同样在到达设定的结束时间后，在等待伸缩窗口期（180秒）后，服务进行缩容，由于restoreToOriginalReplicaCount: true，所以会恢复到最原始的副本数。