当前位置：首页 > 其他 > 正文内容

全球最大分类广告商的Karpenter实践：减负运维、削减中止、每月省21万（上）

邻居的猫1个月前 (12-09)其他2030

原文链接：

https://medium.com/adevinta-tech-blog/the-karpenter-effect-redefining-our-kubernetes-operations-80c7ba90a599

编译：CloudPilot AI

Adevinta 是国际最大的在线分类广告商之一，其事务遍及全球9个国家及区域，每个月招引超越 1.2 亿用户和 100 万家企业，2023 财年总营业额达 18 亿欧元。本文将介绍 Adevinta 搬迁至 Karpenter 的落地实践。

在 Adevinta 内部，现已对 Karpenter 的特性和它处理要害运维难题的潜力感到振奋已久。现在，Adevinta 现已完结了从 Amazon EKS 保管节点组到 Karpenter 的全面搬迁，现在正是总结这段进程并共享其间经历的最佳时机。

问题概述

办理一个由 2,000 多个 Kubernetes 节点、30 个集群组成的巨大体系，并服务于 25 个不同的商场，这绝非易事。尽管一开端运用 Kubernetes Cluster Autoscaler 和 Amazon EKS 保管节点组体现杰出，但跟着时刻推移，Adevinta 逐渐遇到了阻止功率和扩展性的运维难题。

集群晋级的杂乱性、实例类型挑选的局限性，以及用例灵敏性缺少等问题，越来越成为 Adevinta 的担负。团队迫切需求一个可以正面处理这些应战的处理方案。

引进 Karpenter

Karpenter 是一款开源的高功用 Kubernetes 主动扩缩容东西，现在已捐献给 CNCF。与传统的主动扩缩不同，Karpenter 可以动态地在实时环境中为集群作业负载供给所需的核算资源。它经过调查未调度 pod 的资源恳求总量，智能决议计划并发动精准匹配需求的新节点。

Karpenter 项目地址：

https://github.com/kubernetes-sigs/karpenter

集群晋级与保护变得轻松自如

曩昔，晋级 Kubernetes 集群是一件令人头疼的事，尤其是在运用 EKS 保管节点组并经过 AWS CDK 进行资源装备时。操控平面与节点组晋级之间的严密耦合，使整个进程简略报错。任何问题，比方装备过错或实例资源缺少，都会导致晋级失利并堕入回滚的循环。

关于大型集群，这一应战愈加艰巨。晋级数百个节点一起将影响降到最低或许需求好几天，工程师有必要全程亲近监控。这不只消耗时刻和资源，而且常常因为实例可用性等外部要素导致失利，使晋级进程愈加杂乱。

更新节点组时的硬依靠会导致整个晋级回滚并卡住

失利原因不行控

为缓解这些危险，Adevinta 曾在履行 Kubernetes 晋级前施行容量预留。但是，这种办法功率低下且缺少可扩展性。

引进 Karpenter 后，晋级流程变得愈加简略。操控平面与节点池晋级完结了解耦，使操控平面的晋级变得愈加简略，大多数晋级可在 15 到 30 分钟内完结。Karpenter 异步办理作业节点的晋级，当操控平面版别更新时，它会检测到 AMI（Amazon Machine Image）的改变，并经过标记为“漂移”的办法辨认需求晋级的节点。

{"level":"INFO","EC2NodeClass":{"name":"default"},"parameter":"/aws/service/eks/optimized-ami/1.30/amazon-linux-2-arm64/recommended/image_id","value":"ami-0d494a2874a2e7ec1"}
{"level":"INFO","EC2NodeClass":{"name":"default"},"namespace":"","name":"default","reconcileID":"b99dbc2a-5112-4121-ab64-7e512bb0399f","parameter":"/aws/service/eks/optimized-ami/1.30/amazon-linux-2-gpu/recommended/image_id","value":"ami-01389330bfd276054"}

一旦检测到新的 AMI，Karpenter 就会将现有版别标记为漂移，并开端主动晋级。

漂移的节点会逐渐被新版别替换，无需人工干涉。这种别离极大地下降了晋级所需的作业量，而且不再需求继续监控。

对中止的精细化操控

Karpenter 对 Pod 中止预算（PDB）的严厉恪守，为 Adevinta 的运维带来了明显改善。此前，即便启用了序列化选项（serialised option），Cluster Autoscaler 仍会在短时刻超时后强制移除节点，导致服务频频中止。而现在，Karpenter 能在设定的中止范围内从容应对，极大地削减了服务影响。

Adevinta 曾在运用保管节点组时遇到问题，例如重命名节点组或调整副本最小数量，这些操作常常引发比预期更严峻的中止。这种状况让晋级进程变得“鸡犬不宁”，还常常引发毛病，影响了客户的正常运用。这种不行猜测性让 Adevinta 对晋级望而生畏，因为它们一般会导致计划外的停机并增加额定的作业担负。

更多节点一起中止，导致运用程序停机

因为多种原因，受办理的节点群遭到的搅扰或许比咱们预期的要大

经过 Karpenter，Adevinta 在节点中止办理方面获得了更大的掌控力，尤其是在晋级进程中。其中心优势之一是可以灵敏装备中止预算（Disruption Budget），精准操控节点更新的频率。例如，可以设置每 15 分钟仅更新一个节点的战略，大幅下降对运转服务的影响。这种渐进、可控的办法保证了服务安稳性，将晋级进程中的停机时刻降到最低，处理了曩昔的一大难题。

Karpenter 的另一大优势在于其在不同节点池类型间装备中止预算的灵敏性。Adevinta 现在可以依据作业负载的重要性分配不同等级的牢靠性要求。关于要害任务作业负载，严厉约束节点中止；而关于非要害任务作业负载，则采纳更宽松的约束，然后在集群内完结资源的最优办理与服务的高牢靠性。

中止预算装备答应在 15 分钟窗口期内最多中止一个实例

Karpenter 的中止预算与用户装备的 Pod 中止预算（PDB）严密配合，保证晋级进程中的高牢靠性。例如，在设定的 15 分钟窗口内，假如 PDB 要求不答应任何节点中止，Karpenter 将越过该窗口，保证服务的继续安稳。这种机制在多租户场景下尤为重要，因为它可以彻底满意用户对牢靠性的严厉要求，保证服务一直处于高可用状况。

一个节点每 15 分钟中止一次，但假如 PDB 所需的时刻超越 15 分钟，Karpenter 会等候下一个窗口再进行测验。

此外，在 v1 版别中，Karpenter 支撑针对不同类型的中止原因（如节点兼并、节点过期或规范改变）指定不同的时刻窗口。这种精细化办理使 Adevinta 能在坚持高可用性的一起，顺利完结必要的保护作业，然后在安稳性与保护功率之间完结了杰出的平衡。

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
 name: default
spec:
 template:
   spec:
     expireAfter: 720h # 30 * 24h = 720h
 disruption:
   consolidationPolicy: WhenEmptyOrUnderutilized
   budgets:
   - nodes: "20%"
     reasons:
     - "Empty"
     - "Drifted"
   - nodes: "5"
   - nodes: "0"
     schedule: "@daily"
     duration: 10m
     reasons:
     - "Underutilized"

Karpenter 还支撑一种名为“双跳”（double jump）的晋级战略。在“双跳”进程中，Adevinta 可以接连晋级 EKS 操控平面两个版别，只需进行一次集群重建。详细做法是，将 Karpenter 装备为在操控平面晋级期间答应节点数为零，待操控平面接连晋级两个版别后，再移除装备。这种办法有用简化了晋级流程，大幅提高了晋级功率，一起削减了中止危险。

disruption:
 budgets:
 {{- if has .Values.clusterName .Values.featureFlags.blockDisruption }}
 - nodes: "0"
 {{- end }}

当 Karpenter 检测到 Kubernetes 新版别时，它会主动将一切节点标记为漂移状况。因而，假如某个节点被标记为漂移节点，替换的节点将运用 Karpenter 在发动时发现的最新 AMI。例如，版别为 1.28 的节点将被晋级到 1.30 版别的 AMI。

这一简略的功用大大节约了运维时刻，因为一般进行一次全面集群晋级需求几周的规划和履行。经过“双跳”战略，即便在严厉的约束条件下，咱们也能防止不必要的全体节点重建。尽或许防止中止 Pod，削减对用户的搅扰，一直是最佳挑选。

灵敏挑选实例类型，处理资源瓶颈

曩昔，挑选实例类型是一个繁琐的进程。每个节点组都需求清晰指定实例类型，而且有必要严厉满意资源需求。尽管运用云服务供给商意味着可以动态调度机器，但并不代表一直具有无限的资源，尤其是在较小的区域，当呈现实例资源耗尽的状况时，晋级操作往往会失利。

实例耗尽的报错提示

在 AutoScalingGroup 中，存在辅佐实例类型（secondary instance types）的概念，答运用户供给代替实例类型的列表以及节点组规范。但是，这个进程依然是手动的，简略犯错且具有许多约束。例如，代替实例类型有必要与主实例类型在 CPU 和内存上坚持共同。跟着规划的扩展，办理这一进程简直成了一场噩梦。

增加辅佐实例类型

Karpenter 经过让用户界说实例需求而非指定实例类型，成功笼统化了这种杂乱性。Karpenter 会主动挑选最适宜且最经济的实例类型。这种灵敏性不只简化了办理作业，还有用下降了实例资源耗尽的危险，这关于 Adevinta 这样的规划来说尤为重要。

CloudPilot AI 的智能节点挑选功用可以进一步优化 Karpenter 的动态实例挑选，智能匹配超越750种实例类型，为用户的作业负载主动匹配多样化的实例类型，以削减资源糟蹋，提高核算功用，增强运用安稳性。

另一个额定的优点是，当有更好、更廉价或功用更强的实例类型可用时，Adevinta 不再需求时刻监控或进行 2000 多台机器的全体重建。Karpenter 会主动、渐进地完结这一进程，保证资源的继续优化。

针对不同作业负载定制节点池

在 Adevinta 的环境中，Karpenter 最重要的优势之一便是可以创立定制化的节点池，以满意不同作业负载的需求。关于办理一个多样化的运用生态体系来说，每个运用都有共同的资源需求和操作特性，这种灵敏性至关重要。

经过 Kubernetes CRD 简化节点池创立

Karpenter 运用 Kubernetes 自界说资源界说（CRD）来界说资源调度行为，使节点池的创立变得愈加简略，尤其是关于了解 Kubernetes 的用户。经过界说 Provisioner CRD，Adevinta 可以指定约束条件和优先级，例如：

实例类型与系列： 挑选广泛的 EC2 实例类型或系列，以匹配不同作业负载的需求。
节点标签与污点： 为节点分配标签和污点，以操控 Pod 调度，保证作业负载布置到适宜的节点。
Kubelet 装备： 自界说 kubelet 参数，以优化节点功用，满意特定运用的需求。

这种办法使 Adevinta 能以声明的办法办理节点装备，削减了保护多个 Auto Scaling Groups 或保管节点组的杂乱性，尤其是在处理不同作业负载时。

满意特定作业负载需求

以下是 Adevinta 怎么运用 Karpenter 来习惯不同作业负载的几个实践示例：

1. GPU 密集型机器学习任务

Adevinta 的数据科学团队常常运转需求 GPU 加快的机器学习模型。曩昔，Adevinta 需求保护专门的 GPU 节点组，但这些节点组往往未得到充分运用且本钱较高。凭借 Karpenter，Adevinta 可以界说一个 Provisioner，设置如下规范：

资源需求：节点有必要具有 GPU 才能（例如，NVIDIA Tesla V100）。
实例类型：优先挑选 g4dn 实例系列。
污点与标签：运用污点，保证只要 GPU 作业负载被调度到这些节点上。

当有 Pod 恳求 GPU 资源，而且该 Pod 满意咱们指定的污点忍受条件时，Karpenter 会动态地为其装备一个 GPU 支撑的节点。一旦作业负载完结，假如不再需求该节点，该节点可以被开释。这种动态扩展办法优化了资源的运用率，下降了本钱，一起，经过污点和标签的装备，保证作业负载可以被调度到与所需资源匹配的节点类型上。

2. 专用节点用于监控和日志搜集

Adevinta 的监控栈，包含 Prometheus 和日志搜集器，获益于与其他作业负载的阻隔，以防止资源争用、Pod 替换频频和或许呈现的“街坊噪声”效应（即当同一物理服务器上的其他用户忽然占用更多的资源，如CPU、内存或I/O，或许会导致整个服务器功用下降，然后影响到一切用户）。经过运用 Karpenter，Adevinta 可以设置一个 Provisioner，详细装备如下：

核算优化：挑选针对内存密集型作业负载优化的实例类型（例如，r5 系列）。
运用特定标签和污点：保证只要监控和日志搜集的 Pod 被调度到这些节点。
自界说 kubelet 装备：主动调整设置，例如 kubelet 最大 Pod 数量和驱赶战略。

这种阻隔有用安稳了 Adevinta 的监控服务，并削减了“街坊噪声”效应，防止了资源密集型作业负载影响同一节点上其他作业负载的功用。例如，将 Prometheus 作业负载阻隔到专用节点上，不只提高了功用，还带来了额定的本钱节约。

增强安稳性的附加功用

像界说 startupTaints 这样的功用也十分名贵。它们让 Adevinta 在调度 Pod 之前，可以提早准备好节点上的要害组件——例如 IAM 署理。这大大削减了因为运用程序被调度到没有彻底发动的节点上而导致的间歇性毛病。经过保证节点在承受作业负载之前彻底准备好，Adevinta 提高了服务的全体安稳性和牢靠性。

经过 Kyverno 战略供给灵敏性

为了无缝地向客户供给这种灵敏性，Adevinta 运用了 Kyverno 战略。这些战略依据节点挑选器主动为 Pod 分配忍受性，简化了用户的操作，并最小化了装备过错的危险。

例如，考虑以下 Kyverno 战略：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-gpu-taint
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: enforce-gpu-t4-taint
      match:
        any:
          - resources:
              kinds:
                - Pod
      preconditions:
        all:
          - key: "{{ request.object.spec.nodeSelector.\"alpha.gpu.node.x.io/nvidia-gpu-name\" || '' }}"
            operator: Equals
            value: "t4"
      mutate:
        patchesJson6902: |-
          - path: "/spec/tolerations/-"
            op: add
            value:
              key: "alpha.gpu.node.schip.io/nvidia-gpu-name"
              operator: "Equal"
              value: "t4"
              effect: "NoSchedule"
    - name: enforce-gpu-a10g-taint
      match:
        any:
          - resources:
              kinds:
                - Pod
      preconditions:
        all:
          - key: "{{ request.object.spec.nodeSelector.\"alpha.gpu.node.x.io/nvidia-gpu-name\" || '' }}"
            operator: Equals
            value: "a10g"
      mutate:
        patchesJson6902: |-
          - path: "/spec/tolerations/-"
            op: add
            value:
              key: "alpha.gpu.node.schip.io/nvidia-gpu-name"
              operator: "Equal"
              value: "a10g"
              effect: "NoSchedule"
    - name: enforce-gpu-taint
      match:
        any:
          - resources:
              kinds:
                - Pod
      preconditions:
        all:
          - key: "{{ request.object.spec.nodeSelector.\"accelerator.node.x.io/gpu\" || '' }}"
            operator: Equals
            value: "true"
      mutate:
        patchesJson6902: |-
          - path: "/spec/tolerations/-"
            op: add
            value:
              key: "accelerator.node.schip.io/gpu"
              operator: "Exists"
              effect: "NoSchedule"

优势与应战

Kyverno 为 Adevinta 带来了明显的优势：

简化用户体会： 经过 Kyverno 主动依据节点挑选器分配忍受性，用户无需深化了解 Kubernetes 调度的杂乱性即可布置作业负载。用户只需指定需求，战略会主动处理剩下部分。
共同且正确的调度： 主动化忍受性分配保证 Pod 被调度到正确的节点，并具有相应的污点。这坚持了咱们已树立的阻隔和功用优化，削减了 Pod 被调度到不适当节点的危险。
下降装备过错危险： 经过主动处理忍受性，削减了人为过错的或许性，例如忘掉包含必要的忍受性，这或许导致 Pod 无法调度或被过错调度。

经过将 Kyverno 战略与 Karpenter 的资源装备才能结合，Adevinta 使客户可以轻松运用 Kubernetes 的高档功用。这种协同效果提高了用户体会，优化了资源运用，一起坚持了 Adevinta 的高功用和高牢靠性规范。

主动化安全更新

安全至关重要，而坚持咱们的 Amazon Machine Images（AMIs）更新曾是一个繁琐且耗时的手动进程。凭借 Karpenter，AMI 更新现在可以无缝处理。当新的 AMI 发布时，Karpenter 会辨认出漂移的节点并逐渐替换它们，一起恪守 PDB（Pod Disruption Budget）和中止战略。这一主动化进程保证了咱们的集群一直坚持最新的安全补丁，而无需人工干涉。

曩昔，因为无法继续查看更新，Adevinta 并未活跃更新 AMI。一起，之前的架构每次更新都需求进行全量集群重建，这会带来更多的中止。