1000+节点、200+集群，Slack如何利用Karpenter降本增效？

原文首发于云妙算

Slack 是一款 AI 工作管理和协作平台。随着业务需求的增长，Slack 对其内部计算编排平台进行了重大改造，以增强可扩展性、提高服从并低落成本。该内部平台的代号为“Bedrock”，基于 Amazon EKS 和 Karpnter 构建。
通过利用 Bedrock，Slack 将容器摆设和管理简化为单个 YAML 文件，从而简化了内部开发职员的工作流程。借助 Jenkins、Nebula overlay 网络和 FQDN 服务发现等工具，Slack 凌驾 80% 的应用步调现在都在 Bedrock 上运行，从而提高了测试准确度和基础架构管理水平。然而，随着业务范围的扩大，Slack 在管理可扩展性和资源利用率方面面对挑战，因此采用了开源集群自动扩缩容工具 Karpenter。
在本篇文章中，我们将深入探讨 Slack 在亚马逊 EKS 上对其容器平台进行现代化改造的过程，以及他们如何通过利用 Karpenter 来节约成本并提高运维服从。
采用 Karpenter 之前：Slack 面对的挑战

在集成 Karpenter 之前，Slack 依靠管理多个自动扩展组 (ASG) 来处理其 EKS 计算资源。虽然这种方法最初很有用，但在工作负载和复杂性不断增加的情况下，开始出现瓶颈：
1. 可扩展性问题： 随着实例类型和应用需求的增加，管理多个 ASG 变得非常具有挑战性。
2. 升级瓶颈： 对拥有数千个工作节点的 EKS 集群进行频仍更新会低落摆设速率。
3. 架构限定： 单副本架构带来了漏洞，而跨区管理差别的实例需求又造成了服从低下。
这些限定因素促使 Slack 寻求一种更具弹性、更高效、更动态的弹性伸缩办理方案。
两步走战略：渐渐推广 Karpenter

Karpenter 能够根据工作负载需求动态调理和扩展节点，是满意 Slack 需求的抱负办理方案。通过与亚马逊 EC2 的 Fleet API 直接交互，Karpenter 可以评估 pod 的资源需求，并为工作选择最佳实例类型。Slack 采用了缜密的两阶段推广策略，以确保平稳过渡：
第 1 阶段：验证

最初，Karpenter 与核心应用步调一起摆设在托管节点组中。在这一阶段，Karpenter 的整合功能（通过重新分配工作负载来优化节点利用率）被禁用，重点是验证其在特定工作负载中的功能。这一阶段还包括大量测试，以识别和办理 pod 配置错误，确保工作负载得到优化，从而实现高效调理。
第 2 阶段：全面推广

Slack 将 Karpenter 控制器工作负载转移到专用的 ASG，确保 Karpenter 不会在其管理的节点上运行。经过严格测试后，Slack 最终在凌驾 200 个 EKS 集群（运行着数千个工作节点）的环境中全面摆设了 Karpenter。在此阶段启用了整合功能，使 Slack 能够最大限度地提高资源利用率并显著节约成本。
由于 Karpenter 是分阶段采用的， 因此可以控制哪些集群启用了 Karpenter。这使 Slack 能够在 Karpenter 中验证工作负载的性能，并在收到问题报告时快速回滚。
当工作负载没有得当的 request/limits 时，Karpenter 会分配较小的实例或仅分配大型实例的一小部分，从而导致负载增加时频仍的 pod churn（指 Pod 和容器的创建、烧毁和随后重新创建的循环）。Slack 通过 Karpenter 发现了这一问题，进而改进其平台，以确保 Pod 的设置符合要求，并将其分配到得当的节点上。对于需要特定实例类型的工作负载，Slack 能够调整 NodePool 自定义资源，并使用 Karpenter 标签将 pod 固定在相干实例类型上。
如下图所示，Slack 的 Bedrock EKS 集群在架构上的优势是其弹性和服从。Bedrock 和 Karpenter 对 Slack EKS 架构的综合影响显而易见。

采用 Karpenter 之后：Slack 取得的成果

Slack 采用 Karpenter 后，在多个方面都取得了明显改善：
1、资源优化

Karpenter 根据 pod 需求动态选择实例类型（从 8xlarge 到 32xlarge），对于无需特定实例类型的工作负载可以高效地使用所有可用资源，大大提高了集群利用率。利用整合功能通过重新分配工作负载消除了闲置实例，减少了对跨可用区（AZ）最小 ASG 规模的需求。
云妙算的智能节点选择功能可以进一步优化 Karpenter 的动态实例选择，智能匹配凌驾750种实例类型，为用户的工作负载自动匹配多样化的实例类型，以减少资源浪费，提升计算性能，增强应用稳定性。

2、成本优化

通过自动扩展节点和利用更丰富的实例系列，Slack 的计算成本低落了 12%。动态实例分配还减轻了基础设施团队的负担，他们以前的任务是维护多套 ASG 配置。
3、提升性能

由于 Karpenter 可以即时做出节点自动扩缩决议，加速了节点配置，缩短了 pod 的启动时间，从而在工作负载高峰期实现更快的扩展。此外，Slack 在运行 Karpenter 时采用了自定义超额配置，为突发的流量高峰提供缓冲。
Karpenter 与 Amazon EC2 的直接 API 交互与重试（retry）机制提高了规复本领，确保在可用区（AZ）发生故障时更快地规复。
4、简化操纵

通过移除 Terraform 配置中的硬编码实例类型，有助于更快地启动 pod，进而缓解了对 Slack 系统升级的担忧，由于可以在升级过程中迅速驱逐和轮换节点。自定义的 Helm Chart 配置使 Slack 能够在 200 多个 EKS 集群中使用单个 NodePool 和 EC2NodeClass。
由于 Karpenter 提供的实例系列中有多种实例类型可供选择，在使用动态调理约束时，从一种实例类型切换到另一种实例类型很有帮助。这减轻了基础设施团队的负担，并低落了实例类型更改的风险。

未来规划

Slack 成功摆设 Karpenter 标志着其进一步优化之旅的开始。Slack 目前正在积极简化当前的 Karpenter 配置，以进一步改善运维操纵并节省更多成本：

• 自定义 Kubelet 配置： Slack 筹划绕过基础设施即代码 (IaC) 办理方案，通过 Karpenter 的 EC2NodeClass 直接配置 kubelet flag，从而缩短实例启动时间。
  
• 用于快速扩展的 Warmpool：  Slack 正在探索如何让 Karpenter 从 warm pool 中挑选实例，而不是调用亚马逊 EC2 Fleet API，从而缩短启动时间。
  
• 制止控制： 加强制止控制，最大限度地减少整合对应用步调可用性的影响，确保即使在高并发期间应用也能顺利运行。
  

总  结

在这篇文章中，我们讨论了 Slack 的 Bedrock 通过从基于 ASG 的自动扩展过渡到 Karpenter，改善 Amazon EKS 集群的运行，提高了可扩展性。我们还讨论了 Slack 如何利用 Karpenter 作为 EKS 集群的弹性伸缩工具来精简基础设施并且低落成本。展望未来，Slack 将更加专注于通过贡献和利用新功能来进一步优化 Karpenter 环境，从而构建一个稳健且强大的平台。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。