Karpenter 是一款高性能、灵活的开源 Kubernetes 集群自动扩展工具，目前已支持 AWS 和阿里云。它可以根据不断变化的应用负载，快速启动大小合适的计算资源，进而提升应用的可用性。
相较于 Cluster Autoscaler，Karpenter 的灵活、易用、细粒度控制和高度自动化是一项重大升级，可帮助您更快速地调整资源、高效扩展和持续优化。
今年年中，Karpenter 发布了 1.0 版本，意味着该项目已 GA。因此现在是一个采用 Karpenter 的绝佳时机。
平均仅需 20 分钟即可完成迁移
通过 EKS 托管的节点组和 Fargate 迁移至 Karpenter 十分简单，并且由于它与现有的 Kubernetes 集群兼容，并能利用标准的 Kubernetes 资源，因此可将中断降至最低。
关于迁移的细节，我们将在后续的文章中详细说明。欢迎关注**「CloudPilot AI」**。
Karpenter 配置的最佳实践
CloudPilot AI 构建在 Karpenter 之上，研发团队的核心成员是 Karpenter 项目的首批开发者，因此我们对 Karpenter 颇为了解。以下是关于 Karpenter 配置的最佳实践：
使用 Fargate 或专门的节点组
在 EKS Fargate 或专门的节点组上运行 Karpenter 控制器可以避免管理冲突和资源竞争。如果控制器运行在它所管理的节点上，可能会不小心缩减这些节点，从而导致系统不稳定。通过使用 EKS Fargate，控制器与托管节点保持独立，确保了稳定的可用性和性能。另一种选择是使用专用节点组，将控制器与应用程序工作负载隔离，进一步防止资源竞争，从而提高可靠性。
使用 Pod 中断预算（PDB）
Karpenter 会在其正常操作过程中请求调度器销毁节点。确保服务可靠性的唯一方法是向调度器告知每个 Deployment 或 StatefulSet 的需求。
中断预算对于在更新或扩展操作期间维持应用程序可用性至关重要，它通过限制任何时刻可以中断的 pod 数量来实现。这有助于通过避免同时终止过多 pod 来防止服务停机。此外，中断预算帮助平衡运维和稳定性，确保在进行必要更新的同时，至少有部分 pod 继续运行，从而确保 Kubernetes 环境的可靠性和稳定性。
避免使用自定义启动模板
Karpenter 的指导手册建议避免使用自定义启动模板，因为它们不支持节点的自动升级、跨架构支持或安全组发现。
与其使用启动模板，您可以在 AWS 节点模板中使用自定义用户数据，或者直接添加自定义 AMI。
在节点池中配置节点过期
使用 Karpenter，您可以设置在指定时间后自动使节点过期，而不会导致任何停机。这样可以确保所有节点始终运行最新的安全补丁，提升系统的安全性和稳定性。
根据工作负载类型设置节点池
有状态工作负载对节点变动的容忍度较低，因此建议为这类工作负载设置仅使用按需实例的配置器。而对于无状态且容错性强的工作负载，可以设置一个仅使用 Spot 实例的节点池。
为 GPU 工作负载或通用计算创建特定的节点池
为 GPU 工作负载或通用计算创建专门的节点池，可以更好地分配和优化资源。对于 GPU 密集型任务，配置了 GPU 实例的节点池可以确保这些专用资源的可用性和高效利用。
有趣的是，GPU 实例有时比通用计算实例更便宜。这种成本优势意味着，只要正确配置节点池和工作负载，您也可以将 GPU 实例用于常规工作负载。这样的灵活性不仅能降低成本，还能确保工作负载与适当的硬件匹配，避免资源竞争，并通过为不同类型的工作负载提供独立的扩展策略和配置，简化管理。
为您的 Deployment/Pod 指定资源
Karpenter 会根据 Pod 的资源请求进行计算，因此必须为 Deployment/Pod 指定资源。如果不指定资源，可能会导致集群扩展时出现问题。
将 Pod 分布在多个节点和可用区
将 Pod 分布在多个节点和可用区可以增强 Kubernetes 应用的韧性和可用性。通过分散 Pod 的位置，可以最小化单点故障对服务的影响，因为如果某个节点或可用区出现故障，工作负载仍可以在其他节点或可用区继续运行。
Karpenter 通过动态地在不同的可用区配置节点来自动化这种分布，确保负载均衡和资源使用的优化。通过结合 Pod 拓扑约束，Karpenter 确保 Pod 按照指定规则进行部署，避免资源争抢，提升性能和可靠性，即使在节点或可用区发生故障时，也能保持服务不中断。
优先使用 Savings Plans 或预留实例
通过为特定的节点池配置较高的权重并设置实例限制，Karpenter 可以在切换到按需实例或其他实例类型之前，优先使用这些更具成本效益的资源。这种策略帮助您最大化预留容量并节省成本，同时保持扩展的灵活性。
在按需实例和 Spot 实例之间进行分配
此配置允许您创建一个混合实例设置，其中一定比例的 EKS 节点使用按需实例，其余部分使用 Spot 实例。这种设置非常适合那些能容忍中断并且能够从 Spot 实例的成本优势中受益的工作负载。
实现这一配置的方法是，您为 Spot 实例和按需实例分别创建节点池，并为一个名为 capacity-spread 的新标签分配不同的值。然后，通过设置该标签的值来配置比例。如果您希望按 20/80 的比例分配，可以为 Spot 节点池设置值 ["2"、"3"、"4"、"5"]，而为按需节点池设置值 ["1"]。
在中断（合并）过程中保护批处理任务
此功能是为了保护长时间运行的批处理作业，防止它们在 Karpenter 管理的节点合并过程中被中断。合并（Consolidation）是 Karpenter 识别低利用率节点并将其移除或替换，以降低集群成本的过程。然而，这一过程可能会中断正在运行的 Pod，包括关键的批处理任务。
通过使用 karpenter.sh/do-not-disrupt: "true" 注解，您可以保护这些 Pod 免受迁移或中断，直到它们的任务完成，确保它们顺利执行并完成。
或者，您也可以配置 disruption 字段，将 consolidationPolicy 与 consolidateAfter 结合使用。
通过设置 disruption，您可以告诉 Karpenter 哪些类型的节点需要考虑合并。您还可以通过设置字符串值"Never"完全禁用合并。
高级最佳实践
使用 Drift 更新节点
Karpenter 的 "drift" 机制会在节点的配置与 NodePool 或 nodeClassRef 中的期望状态不匹配时，将节点标记为"Drift"。漂移可能由多种原因引起，例如 NodePool 配置的变化或基础设施更新（如 AMI 版本变更）。通过使用 Karpenter 的漂移功能，用户可以高效地管理工作节点的升级，确保它们与最新的控制平面版本和基础设施保持一致。
通过自定义用户数据自动化配置节点
通过在 EC2NodeClass 中使用 userData 字段，用户可以在启动工作节点时自动执行额外的配置，而无需偏离标准的 AWS EKS 优化 AMI。这些配置任务包括修改 Kubernetes 设置、挂载卷或运行特定的启动脚本等。
提前超配容量以提高响应速度
这种策略旨在通过预先超配额外的计算资源，确保在需要时能够立即获得计算能力。这对于那些您预知将需要同时启动大量 Pod 的场景尤为有效，比如处理数据流水线。通过提前超配容量，您可以显著减少工作负载启动所需的时间，从而提高整体响应速度和性能。
对于关键生产环境，合理的超配比例可能在 10-20% 之间。
CloudPilot AI 助您轻松使用 Karpenter
CloudPilot AI 基于 Karpenter 构建，在 Karpenter 现有特性的基础之上优化用户的使用体验，包括：
1、简化安装部署流程
对于普通用户来说，安装部署 Karpenter 需要 1～2 周 的时间，并且需要工程师手动运维。而 CloudPilot AI 仅需5分钟 即可完成安装部署，而且全托管服务，无需运维。
此外，当 Karpenter 推出新版本时，CloudPilot AI 可以帮助用户自动、丝滑升级。升级时间可从数天缩短至几小时。
2、Spot 实例智能运维：提前120分钟预测中断、自动回退
使用 Karpenter 的大部分用户都会用到 Spot 实例来降低云成本。但 Spot 实例的中断事件常让工程师措手不及。Karpenter 本身不具备预测中断的能力，只有接到中断通知后才开始处理节点。对于大规模集群而言，风险极大。
CloudPilot AI 通过机器学习算法可以预测超过7500个实例的中断事件，并且提前 120 分钟通知用户。并且还能将相应的应用自动迁移到中断率更低、更稳定的实例上。保障服务稳定性，同时解放运维团队的时间。
3、更智能的节点选型
Karpenter 仅能根据价格因素选择节点，因此有可能选出价格差异不大，但性能差异巨大的节点，最终导致成本只有微小的下降，但性能却发生巨大的损耗。
CloudPilot AI 在此基础上对节点选择功能进行智能化升级。在选取实例的过程中，除了价格因素外，还将网络带宽、磁盘 I/O、芯片类型等因素纳入考虑范围内，通过智能算法选出兼顾成本和性能的实例类型，以减少资源浪费，增强应用稳定性。
推荐阅读