Kubernetes 集群伸缩组件 - Karpenter

Kubernetes 具有非常丰富的动态伸缩能力,这体现在多个层面:

  1. Workloads 的伸缩:通过 Horizontal Pod Autoscaler(HPA)和 Vertical Pod Autoscaler(VPA)等资源,可以根据资源使用情况自动调整 Pod 的数量和资源配置。
  2. Nodes 的伸缩:根据集群的负载情况,可以自动增加或减少 Nodes 的数量,以适应负载的变化。
    • 相关项目:
      • kubernetes/autoscaler: 目前最流行的 Node 伸缩方案,支持绝大多数云厂商。
      • karpenter: AWS 捐给 CNCF 的一个新兴 Node 伸缩方案,目前仅支持 AWS/Azure,但基于其核心库可以很容易地扩展支持其他云厂商。

本文主要介绍新兴 Node 伸缩与管理方案 Karpenter 的优势、应用场景及使用方法。

Karpenter 项目由 AWS 于 2020 年创建,其目标是解决 AWS 用户在 EKS 上使用 Cluster Autoscaler 做集群伸缩时遇到的一些问题。在经历了几年发展后,Karnepnter 于 2023 年底被捐献给 CNCF(kubernetes/org#4258),成为目前 (2024/07/10)唯二的官方 Node 伸缩方案之一。

我于 2022 年 4 月在做 Spark 离线计算平台改造的时候尝试了 Karpenter v0.8.2,发现它的确比 Cluster Autoscaler 更好用,并在随后的两年中逐渐将它推广到了更多的项目中。目前我司在 AWS 云平台上所有的离线计算任务与大部分在线服务都是使用 Karpenter 进行的集群伸缩。另外我还为 karpenter 适配了 K3s 与 DigitalOcean 云平台用于一些特殊业务,体验良好。

Karpenter 官方目前只有 AWS 与 Azure 两个云平台的实现,也就是说只有在这两个平台上 karpenter 才能开箱即用。但考虑到它在易用性与成本方面的优势以及在可拓展性、标准化方面的努力,我对它的未来发展持乐观态度。

Cluster Autoscaler 是目前社区最流行的 Node 伸缩方案,基本所有云厂商的 Kubernetes 服务默认都会集成它。

Karpenter 与 Cluster Autoscaler 的设计理念与实现方式有很大的不同。

Cluster Autoscaler 是 Kubernetes 平台上早期的集群伸缩方案,也是目前最流行的方案。但它做的事情比较有限,最大的问题是它本身并不直接管理集群的节点,而是借助云厂商的伸缩组 (AutoScaling Group)或节点池(Node Pool)来间接地控制节点(云服务器)的数量。这样的设计导致了一些问题:

  1. 部署与维护比较繁琐:需要先在云厂商的控制台上创建好伸缩组或节点池,然后再在 Kubernetes 集群上部署 Cluster Autoscaler,并将伸缩组或节点池的名称等信息填写到 Cluster Autoscaler 的配置文件中。增删节点池时也需要走一遍这个流程。
  2. 能力受限于云厂商的伸缩组或节点池服务:如果云厂商的伸缩组或节点池服务不支持某些功能,那么 Cluster Autoscaler 也无法使用这些功能。
    • 举例来说,AWS EKS 的 Node Group 功能非常难用,毛病一大堆。但如果要用 Cluster Autoscaler,你就没得选,Node Group 再难用也只能忍着。

而 Karpenter 则完全从零开始实现了一套节点管理系统,它直接管理所有节点(云服务器,如 AWS EC2),负责节点的创建、删除、修改等操作。

相较 Cluster Autoscaler, Karpenter 的优势主要体现在以下几个方面:

  1. 声明式地定义节点池: Karpenter 提供了一套 CRD 来定义节点池,用户只需要编写好 Yaml 配置部署到集群中,Karpenter 就会根据配置自动申请与管理节点。这比 Cluster Autoscaler 的配置要方便得多。
    • 以 AWS 为例,你简单地改几行 Yaml 配置,就可以修改掉节点池的实例类型、AMI 镜像、数量上下限、磁盘大小、节点 Labels 跟 Taints、EC2 Tags 等信息。
    • 借助 Flux 或 ArgoCD 等 GitOps 工具,你还可以实现自动化的节点池管理以及配置的版本控制。
  2. 成本感知的节点管理:Karpenter 不仅负责节点数量的伸缩,它还能根据节点的规格、负载情况、成本等因素来选择最优的节点类型,以达成成本、性能、稳定性之间的平衡。 - 具体而言,Karpenter 在成本优化方面具有这些 Cluster Autoscaler 不具备的功能:
    • Spot/On-Demand 实例调整: 在 AWS 上,Karpenter 可以设置为优先使用 Spot 实例,并在申请不到 Spot 实例时自动切换到 On-Demand 实例,从而大大降低成本。
    • 多节点类型支持: Karpenter 支持在同一个集群中使用多种不同规格的节点,并且支持控制不同实例类型的优先级、数量或占比,以满足不同的业务需求。
    • 节点替换策略:Karpenter 支持灵活的节点替换策略,可以通过 Yaml 控制每个节点池的节点替换条件、频率、比例等参数,以避免因节点替换导致的服务不可用。
    • 节点的生命周期管理:Karpenter 支持定义节点的生命周期策略,可以根据节点的年龄、负载、成本等因素来决定节点的续租、下线、销毁等操作。而 Cluster Autoscaler 只能控制节点的数量,它不直接管理节点,也就做不到此类节点的精细管理。
    • 主动优化:Karpenter 支持主动根据负载情况使用不同实例类型的节点替换高风险节点,或合并低负载节点,以节省成本。
    • Pod 精细化调度:Karpeneter 本身也是一个调度器,它能根据 Pod 的资源需求、优先级、Node Affinity、Topology Spread Constraints 等因素来申请节点并主动将 Pod 调度到该节点上。而 Cluster Autoscaler 只能控制节点的数量,并无调度能力。
  3. 快速、高效:因为 Karpenter 直接创建、删除节点,并且主动调度 Pod,所以它的伸缩速度与效率要比 Cluster Autoscaler 高很多。这是因为 Karpneter 能快速获知节点创建、删除、加入集群是否成功,而 Cluster Autoscaler 只能被动地等待云厂商的伸缩组或节点池服务完成这些操作,它无法主动感知节点的状态。

总之,个人的使用体验上,Karpenter 吊打了 Cluster Autoscaler.

这部分建议直接阅读官方文档Karpenter - Just-in-time Nodes for Any Kubernetes Cluster.

如果你使用的是 Proxmox VE, Aliyun 等其他云平台,或者使用的是 K3s, Kubeadm 等非托管 Kubernetes 发行版,那么你就需要自己适配 Karpenter 了。

Karpenter 官方目前并未提供详细的适配文档,社区建议以用于测试的Kwok Provider 为参考,自行实现。Kwok 是一个极简的 Karpenter Provider 实现,更复杂的功能也可以参考 AWS 与 Azure 的实现。

对于个人 Homelab 玩家来说,使用 Proxmox VE + K3s 这个组合的用户应该会比较多。我个人目前正在尝试为这个组合适配 Karpenter,希望能够在未来的文章中分享一些经验。项目地址如下:

Cluster API (CAPI) 是 Kubernetes 社区提供的一个用于管理多集群的项目,从介绍上看,它跟 Karpenter 好像没啥交集。但如果你有真正了解使用过 CAPI 的话,你会发现 Karpenter 与 CAPI 有一些功能上的重叠:

  1. CAPI 的 Infrastructure Provider 专门负责处理云厂商相关逻辑的组件。Karpenter 的标准实现内也包含了 cloud provider 相关代码,还提供了 NodeClass 这个 CRD 用于设定云服务器相关的参数。
  2. Cluster API Bootstrap Provider (CABP) 负责将云服务器初始化为 Kubernetes Node,实际上就是生成对应的 cloud-init user data. Karpenter 的 NodeClass 实现中同样也包含了 user data 的生成逻辑。

Cluster API 的目标是多集群管理,并且它的设计上将 Bootstrap, ControlPlane 跟 Infrastructure 三个部分分离出来了,好处是方便各云厂商、各 Kubernetes 发行版的接入,但也导致了它的架构比较复杂、出问题排查起来会比较麻烦。

历史案例:Istio 曾经就采用了微服务架构,结果因为性能差、维护难度高被不少人喷,后来才改成了单体结构。

而 Karpenter 则是一个单体应用,它的核心功能被以 Go Library 的形式发布,用户需要基于这个库来实现自己的云平台适配。这样的设计使得 Karpenter 的架构简单、易于维护。但这也意味着 Karpenter 的可扩展性、通用性不如 Cluster API.

从结果来看,现在 Cluster API 的生态相当丰富,从Provider Implementations - Cluster API Docs 能看到已经有了很多云厂商、发行版的适配. 而 Karpenter 2023 年底才捐给 CNCF,目前只有 AWS 与 Azure 的实现,未来发展还有待观察。

那么有没有可能结合两者的优势呢?Kubernetes 社区其实就有类似的尝试:

上面这个实验性质的项目尝试使用 Karpenter 作为 Cluster API 的 Node Autoscaler,取代掉现在的 Cluster Autoscaler.

我目前对 Cluster API 有些兴趣,但感觉它还是复杂了点。我更想试试在 Karpenter 的实现中复用 Cluster API 各个 Provider 的代码,快速适配其他云厂商与 Kubernetes 发行版。

相关内容