基于KEDA和Karpenter的K8s弹性伸缩实践方案

本文通过对 Kubernetes 生态的 KEDA、Karpenter 的实践方案介绍，通过上述组件来帮助企业更好地基于 Kubernetes 平台的弹性能力优化 IT 成本、简化运维管理以及提升企业 IT 信息系统的稳定性。

点击上方卡片，关注「CloudPilot AI」

5分钟，降低50%云成本

KEDA (Kubernetes Event-Driven Autoscaling)[1]是 CNCF 毕业的开源项目，可以安装部署在任意 Kubernetes 集群（无供应商锁定）；KEDA扩展了HPA，Horizontal Pod Autoscaling[2] 的能力，使部署在 Kubernetes 集群的工作负载具备了基于事件驱动的弹性扩展能力。

KEDA 的架构图如下，更多关于 KEDA 的组件、工作原理、架构的介绍，可以参考KEDA Concepts[3]。

KEDA 使用了 Kubernetes Operator Model [4]模式，通过定义 Custom Resource Definitions，CRD [5]来让用户实现基于事件驱动的弹性伸缩，KEDA 可以实现当没有外部事件驱动时让 Deployment 缩容到0的特性（对于 Kubernetes 集群资源成本优化非常不错！）。

KEDA 的相关组件和一些关键常用参数可以参考Scaling Kubernetes：Intro to Kubernetes-based event-driven autoscaling (KEDA)[6];更多KEDA详细技术资料可以直接参考KEDA官网[7]。

传统的 Kubernetes Cluster Autoscaling[8] 在面对 Kubernetes 集群生产级的节点弹性伸缩会有一些限制：

• 依赖 Cloud Provider 的 launch template 和 Auto Scaling Group，因此 Auto Scaling Group 的最大值和最小值会限制弹性伸缩节点组的最大和最小节点数量；

• Cluster Autoscaler 处理错误的机制是基于超时，对于大规模节点集群（例如集群节点超过1000，每个节点部署超过30个 Pod）则没有官方的性能测试数据；

• Cluster Autocaler 中，Auto Scaling group 总会不断请求 Cloud Provider 来确认状态，在集群规模扩大以后，很可能碰到 API 调用限制，造成整个系统停止响应的后果。

Karpenter 取消了节点组的概念（使用EC2 Fleets)，仅在创建和删除节点时调用 Cloud Provider API，降低了调度的复杂度，能够支持更大的 API 吞吐量；同时 Karpenter 对调度也进行了优化，一旦做出容量扩容的决定，发出创建实例的请求，会立即获得实例ID，在实例创建完成之前就创建节点对象，将需要调度的pod绑定到节点。

Karpenter 不止增加节点，也负责终止节点。其有一个控制器专门负责终止节点，默认一个节点5分钟内没有 pod， Karpenter 就会终止它。

另外，当EC2实例由于某种原因处于 unhealthy 状态或 spot 实例即将被回收，它都会发送一个事件，Karpenter 会响应这些事件，新创建节点来重部署上面的 pod。另外 Karpenter 也可以为节点设置一个 TTL 值，比如配置节点生命周期是90天，这个功能在升级时非常有用，可以确保节点一直滚动升级。

Karpenter 也对节点的启动过程做了优化，节点启动的延迟被 Karpenter 减少到了15至50秒。

Karpenter 可以灵活配置中断预算（Disruption Budget），精准控制节点更新的频率，根据工作负载的重要性分配不同级别的可靠性要求，Karpenter 的中断预算与用户配置的Pod 中断预算（PDB）紧密配合，确保升级过程中的高可靠性，例如，在设定的 15 分钟窗口内，如果 PDB 要求不允许任何节点中断，Karpenter 将跳过该窗口，确保服务的持续稳定。这种机制在多租户场景下尤为重要，因为它能够完全满足用户对可靠性的严格要求，确保服务始终处于高可用状态。

Karpenter 的工作过程，如下图所示：当有一个 pending 状态的 pod 时，如果还有存在的容量，则由 kube scheduler 进行调度。如果没有容量造成 pod 不能被调度，则由 Karpenter 绕过 kube scheduler 将 pod 绑定到新建的预置节点。

架构

步骤说明

1. 发起新任务到调度平台(例如 Airflow 调度平台)

2. 调度平台对任务进行拆解，将子任务存储到 Amazon SQS Queue，当然如果在其他云平台（例如阿里云或者 Azure)，可以选择对应 AWS SQS 的托管消息队列产品

3. 引入 KEDA 组件，KEDA 组件监控到 Amazon SQS Queue 中有新的子任务，创建任务 Pod

4. Karpenter 创建新的 Node，任务 Pod 被分配到新的 Node

5. 任务 Pod 从 Amazon ECR 拉取镜像启动,当然如果在其他云平台（例如阿里云或者 Azure)，可以选择对应 AWS ECR 的托管容器镜像仓库产品

6. 任务 Pod 从 Amazon SQS Queue 中获取子任务并进行计算

优势

架构

说明

[1] KEDA (Kubernetes Event-Driven Autoscaling): https://keda.sh/

[2] HPA, Horizontal Pod Autoscaling: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

[3] KEDA Concepts: https://keda.sh/docs/2.16/concepts/#architecture

[4] Kubernetes Operator Model: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

[5] Custom Resource Definitions, CRD: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/

[6] Scaling Kubernetes: Intro to Kubernetes-based event-driven autoscaling (KEDA): https://opensource.microsoft.com/blog/2020/05/12/scaling-kubernetes-keda-intro-kubernetes-based-event-driven-autoscaling/

[7] KEDA官网: https://keda.sh/

[8] Kubernetes Cluster Autoscaling: https://kubernetes.io/docs/concepts/cluster-administration/cluster-autoscaling/

[9] Karpenter官网: https://karpenter.sh/

[10] GitHub仓库: https://github.com/mingyu110/Best-Practice/tree/main/goprometheuskeda