【云原生系列】KEDA和HPA

KEDA有啥用，相对HPA有啥优势。HPA针对于cpu,内存来进行弹性伸缩，有点不太精确。KEDA可以接入prometheus，根据prometheus的数据指标进行弹性伸缩，相比更加的精准实用。

KEDA 地址:

GitHub

KEDA 官网

什么是 KEDA?

Kubernetes 事件驱动自动缩放 (KEDA: Kubernetes Event-driven Autoscaling) 是对 Kubernetes 内置的水平 Pod 自动缩放器 (HPA) 的补充。

KEDA 并没有取代 HPA，它仍然使用 HPA 来发挥它的魔力，这一点在官方文档中可以找到。

KEDA 有非常好的文档，所以很容易设置，同时 KEDA 是一个由微软支持的开源原生云项目，它在 Azure AKS (Azure 的 Kubernetes 产品) 中得到了完全支持。

微软 (Microsoft)、Zapier 和阿里巴巴云 (Alibaba cloud) 等大公司都在使用它，因此它正在大规模地运行于生产环境中。

这里你可以查到当前 KEDA 支持的外置指标扩展器: https://keda.sh/docs/2.6/scalers/

可以看到当前 KEDA 可以支持多种云厂商以及知名的开源软件的扩展器:

PgSQL

MySQL

MongoDB

Elasticsearch

Cassandra

Apache Kafka

Keda’s架构

• Scaler：连接到外部组件（例如，RabbitMQ）并获取指标（例如，待处理消息队列大小）。

• Operator(Agent)：负责“激活”一个 Deployment 并创建一个 Horizontal Pod Autoscaler 对象。

• Metrics Adapter：将来自外部来源的指标呈现给 Horizontal Pod Autoscaler。

KEDA 如何实现“0 to 1”和“1 to 0”的缩放 ？

• 每当 KEDA 的 metric 适配器检测到不存在负载时，它就会将 Deployment 缩小到零。

• 当没有应用程序在运行并且 Metric 适配器感知负载时，它会将 Deployment 从 0 扩展到 1。

如何使用KEDA？我是否必须编写很多配置才能使其工作？

答案是——不是这样的。

KEDA 为缩放器指标和资源自动缩放逻辑之间的所有类型的映射提供单个 CRD 。让我们以使用 Prometheus 作为扩展部署的度量源为例。

Prometheus 已成为存储 Kubernetes 指标的标准。所以在 ScaledObject 中，我们必须添加一个 PromQL 查询来进行自动缩放。

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: prometheus-scaledobject
  namespace: keda
spec:
  scaleTargetRef:
    deploymentName: my-deployment
  triggers:                                         # List of triggers
    - type: prometheus
      metadata:
        serverAddress: http://:9090  # Prometheus Server
        metricName: http_requests_total
        threshold: '100'
        query: sum(rate(http_requests_total{deployment="my-deployment"}[2m]))  #Scale if Average request per 2 minutes is greater than 100
  pollingInterval:  30                               # Optional. Default: 30 seconds
  cooldownPeriod:   300                              # Optional. Default: 300 seconds
  idleReplicaCount: 0                                # Optional. Default: ignored, must be less than minReplicaCount 
  minReplicaCount:  1                                # Optional. Default: 0
  maxReplicaCount:  100                              # Optional. Default: 100
  fallback:                                          # Optional. Section to specify fallback options
    failureThreshold: 3                              # Mandatory if fallback section is included
    replicas: 6                                      # Mandatory if fallback section is included

只需添加一行 PromQL 查询，我们现在就可以根据查询返回的值自动扩展我们的资源。

现在让我们深入了解 ScaledObject 的一些配置

• pollingInterval：这是拉取指标的时间间隔。KEDA 将检查该 ScaledObject 上的每个触发源，并相应地扩大或缩小部署。

• coolDownPeriod: 在缩小到零之前等待的时间。

• minReplicaCount：您的应用程序需要的最小副本。默认为 0。

Prometheus 自动缩放器真的很酷！但是现在，当我们看到下一个缩放器在起作用时，事情会变得更加有趣。

在销售的时候，亚马逊和其他电子商务平台面临着大量的流量。所以在 KEDA 的帮助下，我们可以根据cron schedule自动扩展。我们基本上可以按照固定的时间表抢先扩大副本数量。

triggers:
- type: cron
  metadata:
    # Required
    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.
    start: 30 * * * *       # Every hour on the 30th minute
    end: 45 * * * *         # Every hour on the 45th minute
    desiredReplicas: "20"

在上述配置中，我们必须指定 KEDA 将您的资源扩展到所需副本的时区和时间跨度。

在 cron 缩放器的帮助下，您可以提前做好管理流量的准备。