tencent cloud

容器服务

动态与公告
产品动态
公告
产品发布记录
产品简介
产品概述
产品优势
产品架构
应用场景
产品功能
基本概念
原生 Kubernetes 名词对照
容器服务高危操作
地域和可用区
开源组件
购买指南
购买指引
购买 TKE 标准集群
购买原生节点
购买超级节点
快速入门
新手指引
快速创建一个标准集群
入门示例
容器应用部署 Check List
集群配置
标准集群概述
集群管理
网络管理
存储管理
节点管理
GPU 资源管理
远程终端
应用配置
工作负载管理
服务和配置管理
组件和应用管理
弹性伸缩
容器登录方式
可观测配置
运维可观测性
成本洞察和优化
调度配置
调度组件概述
资源利用率优化调度
业务优先级保障调度
Qos 感知调度
安全和稳定性
容器服务安全组设置
身份验证和授权
应用安全
多集群管理
计划升级
备份中心
云原生服务指南
云原生 etcd
Prometheus 监控服务
TKE Serverless 集群指南
TKE 注册集群指南
实践教程
集群
Serverless 集群
调度
安全
服务部署
网络
发布
日志
监控
运维
Terraform
DevOps
弹性伸缩
容器化
微服务
成本管理
混合云
AI
故障处理
节点磁盘爆满排障处理
节点高负载排障处理
节点内存碎片化排障处理
集群 DNS 解析异常排障处理
集群 Kube-Proxy 异常排障处理
集群 API Server 网络无法访问排障处理
Service&Ingress 网络无法访问排障处理
Service&Ingress 常见报错和处理
Nginx Ingress 偶现 Connection Refused
CLB Ingress 创建报错排障处理
Pod 网络无法访问排查处理
Pod 状态异常与处理措施
授权腾讯云售后运维排障
CLB 回环问题
API 文档
History
Introduction
API Category
Making API Requests
Elastic Cluster APIs
Resource Reserved Coupon APIs
Cluster APIs
Third-party Node APIs
Relevant APIs for Addon
Network APIs
Node APIs
Node Pool APIs
TKE Edge Cluster APIs
Cloud Native Monitoring APIs
Scaling group APIs
Super Node APIs
Other APIs
Data Types
Error Codes
TKE API 2022-05-01
常见问题
TKE 标准集群
TKE Serverless 集群
运维类
隐患处理
服务类
镜像仓库类
远程终端类
事件类
资源管理类
服务协议
TKE Service Level Agreement
TKE Serverless Service Level Agreement
联系我们
词汇表

认识 KEDA

PDF
聚焦模式
字号
最后更新时间: 2024-12-24 15:51:18

什么是 KEDA?

KEDA(Kubernetes-based Event-Driven Autoscaler)是在 Kubernetes 中事件驱动的弹性伸缩器,功能非常强大。不仅支持根据基础的 CPU 和内存指标进行伸缩,还支持根据各种消息队列中的长度、数据库中的数据统计、QPS、Cron 定时计划以及您可以想象的任何其他指标进行伸缩,甚至还可以将副本缩到0。
该项目于2020年3月被 CNCF 接收,并于2021年8月开始孵化,最终在2023年8月宣布毕业,目前已经非常成熟,可放心在生产环境中使用。

为什么需要 KEDA?

HPA 是 Kubernetes 自带的 Pod 水平自动伸缩器,只能根据监控指标对工作负载自动扩缩容,指标主要是工作负载的 CPU 和内存的利用率(Resource Metrics),如果需要支持其它自定义指标,一般是安装 prometheus-adapter 来作为 HPA 的 Custom Metrics 和 External Metrics 的实现来将 Prometheus 中的监控数据作为自定义指标提供给 HPA。理论上,用 HPA + prometheus-adapter 也能实现 KEDA 的功能,但实现上会非常麻烦。例如,如果想根据数据库中任务表里记录的待执行的任务数量统计进行伸缩,就需要编写并部署 Exporter 应用,将统计结果转换为 Metrics 暴露给 Prometheus 进行采集,然后 prometheus-adapter 再从 Prometheus 查询待执行的任务数量指标来决定是否伸缩。
KEDA 的出现主要是为了解决 HPA 无法基于灵活的事件源进行伸缩的问题,内置了几十种常见的 Scaler,可直接跟各种第三方应用对接,例如各种开源和云托管的关系型数据库、时序数据库、文档数据库、键值存储、消息队列、事件总线等,也可以使用 Cron 表达式进行定时自动伸缩,它涵盖了常见的伸缩场景,并且如果发现不支持的场景,还可以自己实现一个外部 Scaler 来配合 KEDA 使用。

KEDA 的原理

KEDA 并不是要替代 HPA,而是作为 HPA 的补充或者增强。实际上,KEDA 经常与 HPA 一起使用。以下是 KEDA 官方的架构图:



当要将工作负载的副本数缩到闲时副本数,或从闲时副本数扩容时,由 KEDA 通过修改工作负载的副本数实现(闲时副本数小于 minReplicaCount,包括0,即可以缩到0)。
其他情况下的扩缩容由 HPA 实现,HPA 由 KEDA 自动管理,HPA 使用 External Metrics 作为数据源,而 External Metrics 后端的数据由 KEDA 提供。
KEDA 各种 Scalers 的核心其实就是为 HPA 暴露 External Metrics 格式的数据,KEDA 会将各种外部事件转换为所需的 External Metrics 数据,最终实现 HPA 通过 External Metrics 数据进行自动伸缩,直接复用了 HPA 已有的能力,如果需要控制扩缩容的行为细节(例如快速扩容、缓慢缩容),可以直接通过配置 HPA 的 behavior 字段来实现(要求 Kubernetes 版本 ≥1.18)。
除了工作负载的扩缩容,对于任务计算类场景,KEDA 还可以根据排队的任务数量自动创建 Job 来实现对任务的及时处理:




哪些场景适合使用 KEDA?

以下是适合使用 KEDA 的场景。

微服务多级调用

在微服务中,存在多级调用的业务场景,压力是逐级传递的,下面展示了一个常见的情况:



如果使用传统的 HPA 根据负载扩缩容,用户流量进入集群后:
1. Deploy A 负载升高,指标变化迫使 Deploy A 扩容。
2. A 扩容之后,吞吐量变大,B 受到压力,再次采集到指标变化,扩容 Deploy B
3. B 吞吐变大,C 受到压力,扩容 Deploy C
这个逐级传递的过程缓慢且危险:每一级的扩容都是直接被 CPU 或内存的飙高触发,被 “冲垮” 的可能性是普遍存在。这种被动、滞后的方式,很明显是有问题的。
此时,我们可以利用 KEDA 来实现多级快速扩容:
Deploy A 可根据自身负载或网关记录的 QPS 等指标扩缩容。
Deploy BDeploy C 可根据 Deploy A 副本数扩缩容(各级服务副本数保持一定比例)。

任务执行(生产者与消费者)

对于需要长时间执行的计算任务,如数据分析、ETL、机器学习等场景,从消息队列或数据库中获取任务进行执行,需要根据任务数量进行伸缩。使用 KEDA 可以根据排队中的任务数量对工作负载进行自动伸缩,并可以自动创建 Job 来消费任务。




周期性规律

如果业务具有周期性的波峰波谷特征,可以使用 KEDA 配置定时伸缩。在波峰到来之前提前扩容,波峰结束后缓慢缩容,以适应业务的周期性变化。


帮助和支持

本页内容是否解决了您的问题?

填写满意度调查问卷,共创更好文档体验。

文档反馈