CoStar 如何使用 Karpenter 来优化他们的亚马逊 EKS 资源

简介

众所周知，CoStar是商业房地产数据的市场领导者，但他们也经营着主要的房屋、租赁和公寓网站，包括ap artments.com ，许多人都曾看到杰夫·戈德 布鲁姆在做广告。CoStar的传统商业房地产客户是消息灵通的用户，他们使用大型复杂的数据来做出关键的业务决策。CoStar成功地帮助客户分析和决定拥有1,300亿平方英尺空间的600万处房产中的哪一处可供出租，这使CoStar成为数据和分析技术领域的领导者。当CoStar开始构建下一代公寓和房屋网站时，很明显，用户资料和客户需求与长期经营的商业房地产客户存在重要差异。CoStar需要为其新客户群提供相同的决策价值，但要提供更多的客户和数据。这促使CoStar从其传统数据中心迁移到 亚马逊云科技 ，以获得 为访问数亿个资产的数百万用户提供相同价值所需的速度和弹性。

挑战

CoStar面临的最大挑战一直是从数百个来源收集数据，用重要的见解来丰富这些数据，并在一个有意义且用户友好的系统中提供这些数据。CoStar Suite的商业地产、公寓和房屋都有不同的数据源，这些数据源在不同的时间更新，数据量也不同。支持这种数据采集和数据源更新的系统必须快速、准确，并且能够向上和向下扩展以使其负担得起。这些系统中有许多正在从传统数据中心迁移到CoStar的亚马逊云科技环境中，因此必须在并行和可互操作的系统上运行它们，以避免工程支持的大量重复。这些需求都指向在本地和亚马逊云科技中运行Kubernetes，并具有容器集群的扩展能力，以应对使用量的增加和减少。经过数月的成功测试和生产，CoStar 决定进一步优化其工程堆栈，同时尽可能多地保持并行本地 Kubernetes 管理。

在 Kubernetes 集群架构中，控制平面及其组件负责管理集群操作（即调度容器、管理应用程序可用性以及存储集群数据以及其他关键任务）和工作节点，以托管运行容器化应用程序工作负载的 Pod。亚马逊弹性 Kubernetes 服务（ 亚马逊 EKS ）是 亚马逊云科技 上的一项托管 Kubernetes 服务，用于管理 Kubernetes 控制平面的可用性和可扩展性。 对于工作节点，客户可以选择在预配置的亚马逊弹性计算云 ( Amazon EC2 ) 和 亚马逊云科技 Fargate 的任意组合上调度 Kubernetes 容器工作负载。 在这篇文章中，我们将重点介绍 CoStar 如何使用 Karpenter 自动扩展解决方案为工作节点预置 Amazon EC2 实例。

预置工作节点的默认方法是利用 Amazon EKS 管理的节点组，这些节点组使用 Amazon EC2 Auto Scaling 组自动配置和生命周期管理底层 Amazon EC2 实例。为了动态调整 Amazon EC2 实例，可以将 Amazon EKS 管理的节点组功能与集群自动扩缩器解决方案配对。这种自动扩展解决方案会监视等待计算容量的待处理 Pod 以及任何未充分利用的工作节点。当容器由于资源不足而处于待定状态时，集群自动扩缩器会增加 Amazon EC2 Auto Scaling 组中所需的实例数量，该组会预置新的工作节点，从而允许调度和运行这些容器。集群自动扩缩器会根据某些因素终止未充分利用或未使用的节点。

对于在 Amazon EKS 上运行的 CoStar 工作负载，目标是最大限度地提高可用性和性能，同时成为一种高效的资源。尽管 Cluster Autoscaler 解决方案提供了一定程度的动态计算配置和成本效益，但仍有许多注意事项和限制，使其难以使用，甚至受到限制。也就是说，给定节点组的 Amazon EC2 实例类型必须具有相似的中央处理器 (CPU)、内存和图形处理单元 (GPU) 规格，以最大限度地减少不良行为。这是因为它使用节点组策略中指定的第一个实例类型来模拟 Pod 的调度。如果该策略有其他规格更高的实例类型，则在扩展后可能会浪费节点资源，因为它只会根据第一个实例类型的大小来调度 Pod。如果该策略有其他规格较低的实例类型，则由于节点资源限制，Pod 可能无法在这些节点上调度。为了使实例大小多样化以适应 CoStar 不同的 Pod 资源需求，他们需要使用相似的指定实例类型创建多个节点组。此外，Cluster Autoscaler 仅取消配置未充分利用的节点，但没有根据工作负载的变化将其替换为更便宜的实例类型。此外，对于 CoStar 的无状态工作负载，使用节点组实现比按需更高的折扣更高的 Spot 计算容量非常麻烦。

解决方案概述

为什么选择 Karpenter

CoStar 需要一种更有效的方法来配置节点，以满足其不同的工作负载需求，而无需承担管理多个节点组的开销。这个问题已使用开源 Karpenter 节点配置解决方案得到解决。Karpenter 是一款灵活的高性能 Kubernetes 集群自动扩缩器，可为工作节点容量提供动态的无组配置，以响应计划外的 Pod。由于 Karpenter 的无组设计，CoStar 不再局限于使用类似指定的实例类型。Karpenter 持续评估待处理 Pod 的总资源需求和其他调度限制（例如节点选择器、亲和性、容忍度和拓扑分布约束），并预置配置预置器自定义资源定义 (CRD) 中定义的最佳实例计算容量。有了这种额外的灵活性，CoStar中的不同团队可以根据自己的应用程序和扩展需求使用自己的Provisioner配置。此外，Karpenter 直接使用 Amazon EC2 队列应用程序编程接口 (API) 配置节点，无需节点和 Amazon EC2 自动扩展组，这可以缩短配置和重试时间（即毫秒对分钟），从而增强 CoStar 的性能服务水平协议 (SLA)。此外，CoStar团队选择在亚马逊云科技 Fargate上运行Karpenter控制器，这完全消除了对托管节点组的需求。

下图说明了 Karpenter 如何观察非定时 Pod 的聚合资源请求，从而做出启动新节点的决定，并终止这些节点以降低基础设施成本：

为了使 CoStar 的无状态工作负载和较低环境实现成本效益，CoStar 团队将 Karpenter Provisioner 配置为首选 Spot 容量，仅在没有可用竞价容量的情况下才配置按需容量。Karpenter 使用价格容量优化的现货容量分配策略，该策略平衡了成本并降低了短期内中断的可能性。对于生产集群中的有状态工作负载，Karpenter Provisioner 定义了一系列按需运行的计算和存储优化实例系列，其中大部分由计算储蓄计划和预留实例承保以获得折扣。为了进一步优化，CoStar启用了整合功能，这使Karpenter能够通过监控节点的利用率并检查现有工作负载是否可以在其他节点上运行或被更便宜的变体所取代来主动降低集群成本。通过评估多个因素，例如正在运行的 Pod 的数量、配置的节点过期时间、优先级较低的 Pod 的使用以及现有的 Pod 中断预算 (PDB)，整合操作以最大限度地减少工作负载中断。

先决条件

要执行本文中的示例，你需要设置以下内容：

• 在 亚马逊云科技 中预置 Kubernetes 集群
• 安装 Karpenter 以实现集群自动扩展
• 安装亚马逊弹性 Kubernetes 服务 (亚马逊 EKS) 节点查看器

演练

在本节中，我们将简单演示替换机制，这是 Karpenter 整合能力的一部分。以下 Karpenter Provisioner 和节点模板配置代码限制为多种容量类型为按需计算的实例类型：

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: consolidation-replace
spec:
  providerRef:
    name: consolidation-enabled
  requirements:
    - key: "karpenter.sh/capacity-type" 
      operator: In
      values: ["on-demand"]
    - key: "karpenter.k8s.aws/instance-family"
      operator: In
      values: ["c4", "c5", "c5a", "c5n", "c6a", "c6i", "c6in"]
  consolidation:
    enabled: true
  labels:
    type: karpenter-node  
---
apiVersion: karpenter.k8s.aws/v1alpha1
kind: AWSNodeTemplate
metadata:
  name: consolidation-enabled
spec:
  subnetSelector:
    karpenter.sh/discovery: consolidation-subnet-example
  securityGroupSelector:
    karpenter.sh/discovery: consolidation-sg-example
  tags:
    app.kubernetes.io/created-by: consolidation-replace-example

以下是我们用来演示整合行为的应用程序部署清单：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: consolidation-replace-deployment
  namespace: default
spec:
  replicas: 60
  selector:
    matchLabels:
      app: consolidation-replace-deployment
  template:
    metadata:
      labels:
        app: consolidation-replace-deployment
    spec:
      nodeSelector:
        type: karpenter-node
      containers:
        - name: consolidation-replace-container
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.8
          resources:
            requests:
              memory: "128Mi"
              cpu: "500m"

使用 eks-node-viewer 工具来可视化节点使用情况，我们发现 Karpenter 根据其资源请求需求（以及四个守护程序 pod）配置的 c6a.8xlarge 实例类型是运行部署的最佳类型：

让我们假设在非工作时间内的交通负荷较低。你可以使用 水平容器自动扩缩器 根据资源利用率动态扩展 Pod 的数量。在我们的示例中，我们使用 kubectl 将副本数量缩减到 30 个，以模拟流量负载的减少：

kubectl scale deployment consolidation-test --replicas 30

有 30 个副本，总体资源需求要低得多。Karpenter 使用更便宜的变体（在本例中为 c6a.4xlarge）预置替换节点，并封锁原始节点，如以下屏幕截图所示。

在替换节点上重新调度 Pod 后，先前的节点将终止。

从我们的示例中可以看出，随着非工作时间资源需求的减少，Karpenter 通过配置 c6a.4xlarge，让 CoStar 能够高效扩展和优化成本。

正在清理

为避免产生额外的运营成本，请记住销毁您为本文中的示例创建的所有基础架构。

结论

在评估我们的容器解决方案时，亚马逊云科技 上有许多用例和选项。对于 CoStar，Karpenter 整合了他们在开发和测试环境中运行的 Amazon EC2 Spot 容量，并将工作负载转移到成本最低的实例类型，同时仍能有效运行其工作负载。专注于在迁移期间保持平等、继续使用对 Kubernetes 进行深入而有效的投资并寻求经过验证的解决方案来专注于成本优化的客户应考虑使用 Amazon EKS 和 Karpenter。对于已经在使用 Amazon EK S 的用户，可以使用 EKS 节点查看器 工具来评估节点效率以及您是否会从 Karpenter 的功能中受益。希望实现将 Pod 整合到更少的节点上并使用最有效的实例类型的客户应开始探索 Karpenter 并使用 文档 开始使用。