新手攻略！手把手教你安装配置 Karpenter

起初，Karpenter 是专为 AWS 环境设计的 Kubernetes 集群节点扩展工具。随着开源社区的繁荣发展，Karpenter 对阿里云和 Azure 提供了支持。

针对阿里云的支持，由 CloudPilot AI 和阿里云容器服务和弹性计算团队联合开发贡献，详情请参阅：

CloudPilot AI携手阿里云发布Karpenter阿里云 Provider，优化ACK集群自动扩展

多年来，Kubernetes 节点的扩展解决方案一直是 Cluster Autoscaler（支持多个云厂商)。而在 AWS 上，这意味着通过调整 Auto Scaling Group 的实例数量来实现扩缩容，极大限制了扩缩容的速度。

这种方法存在一些问题：

1.Autoscale Group 的更改需要一定时间，因为 ASG 需要评估条件并调用 API 来启动或终止实例，所以当一个新的 Pod 因容量问题无法调度时，它必须等待 ASG 生效并启动一个新实例。

通常，从请求更新到实际启动 EC2 实例之间会有 30 到 60 秒的延迟。

2.默认情况下，在节点的资源使用率低于 50% 且持续时间超过 10 分钟时，Cluster Autoscaler 才将该节点评估为“低利用率”。这可能导致实例长时间处于利用率不足或闲置状态，从而增加开支。

3.Cluster Autoscaler 通常会为每个 Pod 请求一个节点，因此，如果有几个 Pod 请求容量，它就会启动几个节点来满足要求，这同样会造成利用率不足和支出问题。

4.在创建 ASG 时，会通过设置最大值来限制其规模，如果达到最大值，Cluster Autoscaler 就无法进一步增加规模，从而导致集群出现容量问题。

5.Cluster Autoscaler只能根据节点的规格来评估调度情况，因此 Autoscale Group 中的所有实例的 CPU 和内存必须相同，否则会干扰计算并影响 Cluster Autoscaler 的功能——这会导致我们的集群只能使用1 种节点类型（例如，4 核 CPU 和 32GB 内存），因为没有足够多符合该规格的的实例可供选择。

6.区域感知——Cluster Autoscaler 无法均匀地在多个可用区 (AZ) 启动实例，这通常会导致选择单个区域来部署 Spot 实例，并可能导致容量问题，我们通过为每个 AZ 创建 ASG 来解决这个问题。

Karpenter

Karpenter 是一款开源产品，可根据模板驱动实例创建（就像 ASG 根据模板驱动实例创建一样），但跳过了 ASG，从而实现了超快速的实例启动。节点几乎可以立即加入集群，但需要注意的是，节点准备就绪通常需要 60 秒左右。

01/Karpenter 如何工作？

Karpenter 会评估处于待调度状态的 Pod 数量，并立即将可以调度的 Pod 其调度到可用的容量。对于其余的 Pod，Karpenter 会根据用户提供的约束条件计算最佳的机器类型，并启动一台或几台能满足工作负载的机器。由于每台机器只需拉取一次镜像，因此 Pod 的启动速度会更快。

当 Karpenter 发现某个节点上没有运行任何 Pod 时，它就会缩小该 EC2 实例的规模。

02/Karpenter的优点

Karpenter 可以灵活组合不同规格 EC2 实例以适配工作负载，使 Spot 实例的利用效率和容错性大大提高。

Karpenter 的"consolidate"功能可主动检查节点利用率，并将工作负载整合到现有或新的节点中。

与 Cluster Autoscaler 相比，Karpenter 可以在一个节点上安装更多 Pod，从而节省成本。Karpenter 强制要求我们确保集群节点具备容错能力并能够恢复，这有助于提高集群的稳定性。

Karpenter 可以设置节点自动回收和更新最新 AMI 补丁的到期时间（TTL），从而减少故障影响范围。

Karpenter 对节点进行管理的方式是，当节点被删除时，它会首先将该节点标记为不可调度（Cordon），并停止向其调度更多的节点，然后将节点排空（Drain），将 Pod 迁移到其他节点上。

这种方式使得升级过程更加可控，并且如果操作得当（不是所有节点同时删除，并且设置了 Pod 中断预算），可以实现零停机时间。

节约成本

在 Karpenter 中节省的成本取决于您当前的工作负载和您在 Cluster Autoscaler 上使用的 EC2 实例类型。

下面是一个从R5.Large实例切换到一系列实例类型时每月成本节约的示例：

如何设置 Karpenter