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

概念

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

KEDA 是一个单一用途的轻量级组件，可以添加到任何 Kubernetes 集群中。 KEDA 与 Horizo​​ntal 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-prometheus
  namespace: kikitrade-dev
spec:
  scaleTargetRef:
    apiVersion: apps/v1  # 可选参数. Default: apps/v1
    kind: Deployment     # 可选参数. Default: Deployment
    name: blue-kmarket   # 必填参数. Must be in the same namespace as the ScaledObject
    #envSourceContainerName: {container-name}  # 可选参数，Default: .spec.template.spec.containers[0]
  pollingInterval:  15   # 可选参数. 检查每个触发器的时间间隔， Default: 30 seconds
  cooldownPeriod:   30   # 可选参数. 上一次触发后等待的时间段报告为活动，然后再将资源缩放回minReplicaCount设定的数量，Default: 300 seconds
  minReplicaCount: 1     # 可选参数. Default: 0
  maxReplicaCount: 5     # 可选参数. Default: 100
  advanced:                                          # 可选参数. Section to specify advanced options
    restoreToOriginalReplicaCount: true              # 可选参数. 指的是 是否恢复到原始的副本数，如果是false，则会恢复到0，true 则会恢复到原始的副本数，Default: false
    horizontalPodAutoscalerConfig:                   # 可选参数. Section to specify HPA related options
      behavior:                                      # 可选参数. Use to modify HPA's scaling behavior
        scaleDown:                                   # 缩容
          stabilizationWindowSeconds: 180            # 设置伸缩的窗口期，等待三分钟在开始缩容
          policies:                                  # 缩容策略
         # - type: Percent                            # 百分比
         #   value: 20                                # 20%，向上取整，如7.2，按照8算
         #   periodSeconds: 60                        # 一分钟内只允许缩容20%的pod数
          - type: Pods                               # 伸缩对象为pod
            value: 2
            periodSeconds: 60                        # 一分钟内最多缩减pod的数量是2个
        scaleUp:                                     # 扩容
          stabilizationWindowSeconds: 60             # 设置伸缩的窗口期，等待一分钟在扩容
          policies:
          #- type: Percent
          #  value: 20
          #  periodSeconds: 60
          - type: Pods                               # 伸缩对象为pod
            value: 2                                 # 每次扩容新增2个Pod
            periodSeconds: 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: prometheus
    metadata:
      serverAddress: http://prometheus-kube-prometheus-prometheus.prometheus:9090
      metricName: Dubbo Request Latency
      threshold: '200'
      query: sum(dubbo_request_latency_seconds{application='kmarket', quantile='0.9',namespace="kikitrade-dev",pod=~"blue.*"}*1000)
  - type: cpu
    metadata:
      type: Utilization
      value: "50"
  - type: memory
    metadata:
      type: Utilization
      value: "50"
  - type: cron
    metadata:
      timezone: Asia/Shanghai
      start: 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，所以会恢复到最原始的副本数。