原文链接：
https://medium.com/adevinta-tech-blog/the-karpenter-effect-redefining-our-kubernetes-operations-80c7ba90a599
编译：CloudPilot AI

在上一篇文章中，咱们介绍了 Adevinta 搬迁至 Karpenter 后怎么运用这一开源东西为运维团队减负、增强运用稳定性以及完本钱钱优化（月省21万）。点击下方链接检查文章概况：

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

本文将介绍 Adevinta 在搬迁之路上踩过的坑以及他们是怎么处理的。

以防没看过前文的你不了解本文的“主角”，以下是关于Adevinta的介绍：

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

面对的应战

没有一段旅程是没有应战的，Adevinta 的搬迁之路也不破例。

正确装备 Pod Disruption Budget (PDB) 的重要性

虽然 Karpenter 经过遵从 Pod Disruption Budgets（PDBs）增强了可靠性，但这一优势的发挥依靠于客户正确设置 PDB。假如装备不妥，或许会带来以下危险：

危险 1：未设置 PDB 时的中止添加

假如客户没有设置 PDB，Karpenter 在节点兼并等操作期间或许会一起中止多个 Pod。因为 Karpenter 常常进行优化，这或许导致更多的服务中止。

危险 2：过于严厉的 PDB 阻挠保护

相反，假如客户设置了过于严厉的 PDB（例如，指定 maxUnavailable: 0），则会阻挠任何自愿的 Pod 驱赶，包含必要的节点排空以进行保护。这会影响必要的操作，并下降集群健康状况。

缓解战略

为了平衡可靠性与操作灵敏性，Adevinta 施行了以下战略：

设置合理的默许 PDB

Adevinta 为短少 PDB 装备的运用供给默许 PDB 装备，保证在不约束过多的状况下，保护运用免受中止。这有助于在保护期间避免意外的服务影响，一起在必要时答应进行必要的节点中止。

运用 Kyverno 强制履行战略

经过 Kyverno，Adevinta 强制履行战略，避免装备那些或许阻碍集群保护的 PDB。

例如：

避免重复的 PDB Selector

制止在命名空间中创立或更新与现有 PDB 挑选器相同的 PDB。这样能够避免抵触，保证 PDB 的有用性。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: forbid-duplicate-pdb-selectors
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: check-duplicate-pdb
      match:
        any:
          - resources:
              kinds:
                - PodDisruptionBudget
              operations:
                - CREATE
                - UPDATE
      context:
        - name: existingPDBs
          apiCall:
            urlPath: /apis/policy/v1/namespaces/{{request.namespace}}/poddisruptionbudgets
            jmesPath: "items[?to_string(@.spec.selector.matchLabels) == to_string(`{{ request.object.spec.selector.matchLabels }}`) && @.metadata.name != '{{ request.object.metadata.name }}']"
      validate:
        message: "A PodDisruptionBudget with the same selector already exists."
        deny:
          conditions:
            any:
              - key: "{{ existingPDBs | length(@) }}"
                operator: GreaterThan
                value: 0

保证合理的 maxUnavailable 值

Adevinta 强制要求，假如 PDB 指定了 maxUnavailable，则有必要大于零。将其设置为零会阻挠一切自愿的驱赶，然后阻碍保护使命的履行。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: pdb-maxunavailable
  annotations:
    policies.kyverno.io/title: PodDisruptionBudget maxUnavailable Non-Zero
    policies.kyverno.io/subject: PodDisruptionBudget
    policies.kyverno.io/description: >-
      A PodDisruptionBudget which sets its maxUnavailable value to zero prevents
      all voluntary evictions including Node drains which may impact maintenance tasks.
      This policy enforces that if a PodDisruptionBudget specifies the maxUnavailable field
      it must be greater than zero.
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: pdb-maxunavailable
      match:
        any:
          - resources:
              kinds:
                - PodDisruptionBudget
      preconditions:
        any:
          - key: '{{ regex_match(''^[0-9]+$'', ''{{ request.object.spec.maxUnavailable || ''''}}'') }}'
            operator: Equals
            value: true
      validate:
        message: "The maxUnavailable field, when specified as an integer, must be greater than zero."
        pattern:
          spec:
            =(maxUnavailable): ">0"

约束 karpenter.sh/do-not-disrupt 注解的运用

Adevinta 阻挠用户在没有充沛理由的状况下，向作业负载添加 karpenter.sh/do-not-disrupt 注解，因为过度运用该注解或许会阻碍必要的保护作业。

经过施行这些办法，Adevinta 在保证运用可靠性的一起，坚持了履行要害集群操作的才能。

过度装备和调度推迟

虽然 Karpenter 显着提高了资源运用率和本钱效益，Adevinta 仍是遇到了一些与调度推迟相关的应战，特别是在快速扩展的阶段。Karpenter 对节点的优化和密布化（densification）意味着资源得到更高效的运用，但这也或许在某些状况下无意中导致扩展呼应时刻的推迟，影响客户体会。

调度推迟的应战

在 Adevinta 高并发环境中，常常会遇到需求快速扩展 Pods 的突发状况。因为 Karpenter 对节点进行了密布优化，任何时刻可用的闲暇资源相对较少。当突发需求出现时，或许没有当即满足的容量来调度新的 Pods，导致 Pods 进入待处理状况，直到 Karpenter 完结额定节点的装备。

此外，运用 startupTaints 进一步加重了这一推迟。当 Karpenter 发动一个新节点时，会运用一个污点，避免 Pods 在该节点上调度，直到咱们内部的 Kubernetes Operator 验证节点状况并移除污点。这个验证过程关于保证节点健康和契合操作战略至关重要，但也因而添加了额定的推迟。

终究，Adevinta 观察到 Pod 调度时刻的服务等级目标（SLI）有所添加，且客户投诉了因为推迟扩展而带来的功用影响。

施行低优先级 Pod 的超量预留战略

为了缓解调度推迟，Adevinta 选用了一种超量预留战略，与 codecentric 提出的 Cluster Overprovisioner 和 Karpenter Overprovisioning Blueprint 中的计划相似。

以下是详细的施行方法：

1. 创立低优先级类

界说一个自界说的 Kubernetes PriorityClass，优先级低于一切规范作业负载。这一 PriorityClass 专用于调度占位 Pod，能够在需求时被更高优先级的 Pod 抢占。

2. 布置占位 Pod

运用低优先级类布置一组占位 Pod，这些 Pod 恳求的资源很少，但足以保证节点的供应和安排妥当。它们能够缓冲作业负载，占用容量但不会耗费很多资源。

3. 为高优先级 Pod 供给即时调度才能

当新的高优先级 Pod 需求调度时，它们会抢占这些低优先级的占位 Pod。调度器会驱赶占位 Pod，从现有节点上开释资源，而无需等候新的节点发动，然后显着削减调度推迟。

4. 动态节点预留

Karpenter 继续监控集群状况，当检测到占位 Pod 被驱赶导致缓冲容量削减时，会主动创立新的节点，以坚持超量预留状况，并将新的占位 Pod 调度到新节点上。

经过这种战略，Adevinta 完结了在突发负载时的快速呼应，显着缩短了调度时刻，一起保证资源运用的高效性与体系的稳定性。

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
 name: overprovisioning
value: -1
globalDefault: false
description: "Priority class for overprovisioning pods."
apiVersion: apps/v1
kind: Deployment
metadata:
 name: overprovisioning-placeholder
spec:
 replicas: 10
 selector:
   matchLabels:
     app: overprovisioning-placeholder
 template:
   metadata:
     labels:
       app: overprovisioning-placeholder
   spec:
     priorityClassName: overprovisioning
     containers:
     - name: pause
       image: k8s.gcr.io/pause:3.2
       resources:
         requests:
           cpu: X
           memory: X

未来改善方向

Adevinta 正在积极探索进一步优化当时战略的方法，包含以下两方面：

1. 超量预留容量的动态调整

计划引进主动化机制，依据前史运用形式和猜测性扩容需求动态调整占位 Pod 的数量，然后进一步优化资源运用率。当时计划在集群规划较小时或许显得本钱过高，因而动态调整将有助于下降小规划集群中的开支。

2. 社区协作

Adevinta 正积极重视 Karpenter 社区中的相关议题，评论怎么经过 Karpenter 原生支撑超量预留功用。经过参加社区协作，Adevinta 期望推进这一功用的完善，为职业供给更高效的处理计划。

这些改善不只有助于提高资源运用功率，还能增强体系在不同场景下的弹性和稳定性。

“最低价格优先”圈套

虽然 Karpenter 的本钱优化功用一般能带来显着效益，但在某些状况下并不彻底抱负。例如，Adevinta 发现 m5a 实例与 m6a 实例在价格上略有差异，但功用距离显着：

• m5a.4xlarge（eu-west-1 区域）：$0.7680/小时

• m6a.4xlarge（eu-west-1 区域）：$0.7704/小时

虽然价格仅相差 $0.0024/小时，m6a 实例的功用却显着优于 m5a。因为 Karpenter 默许挑选最廉价的实例，这导致某些 CPU 密布型运用的功用未能到达最佳水平，反而因扩展更多副本而添加了全体本钱。

某客户投诉称，自从搬迁到 Karpenter 后，即便未进行任何代码更改，其 CPU 密布型运用的副本数量显着添加。这一现象标明，简略的“最低价格优先”战略在某些场景下或许拔苗助长。

同一运用程序的副本数量因根据 CPU 功用的主动扩展而激增

不只仅是副本数量的激增成为问题，服务的推迟也显着添加，虽然代码并未进行任何更改。这标明，挑选功用较低的实例不只会导致资源耗费上升，还会对服务质量形成严重影响，尤其是在对推迟灵敏的运用中。

即便不修正代码，推迟也会大幅添加

经过查询发现，因为 m5a 实例价格更低，它逐步成为 Karpenter 的首选，替代了此前运用的 m6a 实例。这一主动化挑选虽然节省了本钱，却导致了功用的下降，然后影响了全体服务质量。

搬迁后，实例类型开端从 m6a 转移到 m5a

为了处理这一问题，团队经过界说新的节点池并赋予更高权重（优先级），优先挑选第六代实例，一起将第五代实例降级为备用选项。这种战略保证了功用和本钱之间的平衡，有用提高了服务质量。

- key: karpenter.k8s.aws/instance-generation
 operator: Gt
 values:
 - "5"
weight: 15
- key: karpenter.k8s.aws/instance-generation
 operator: Gt
 values:
 - "4"
weight: 10

这一调整不只保证了功用和本钱的最佳平衡，还在第六代实例资源耗尽时，供给了备用节点池来承载作业负载。

此外，团队已与保护者展开评论，评论在 Karpenter 中原生支撑相似场景处理计划的可行性。

v1 晋级中的兼容性处理

从 Karpenter v0.37.x 晋级到 v1 时，团队遇到了一些兼容性问题。晋级过程中的切换和向后兼容性并不如预期顺利，这导致了一些困惑。虽然这些问题终究都得以处理，但它们也提示团队在选用新版本时有必要坚持慎重，尤其是在运用 ArgoCD 办理 Karpenter 装置时，需求进行充沛的测验和验证。

Karpenter 晋级是社区的常驻问题。根据这一现状，CloudPilot AI 推出 Karpenter 主动晋级功用，将本来需求一周的晋级时刻缩短至3小时，并且为客户处理兼容性问题。

展望未来

Karpenter 的运用之旅远未完毕，团队正在积极探索以下范畴：

将 Karpenter 操控器搬迁出保管节点组

现在，Karpenter 操控器运行在专用于操控平面组件的保管节点组上。但是，团队正在考虑将其搬迁至 AWS Fargate，这一做法已被部分职业团队实践。经过这一搬迁，团队能够脱节对保管节点组的依靠，然后进一步简化基础设施办理。

增强超量预置才能

团队亲近重视 Karpenter 社区关于引进容量预留和超量预置功用的评论。一起，也在投入精力优化现有的超量预置东西，使其愈加灵敏，并削减对硬编码装备的依靠，以习惯多变的资源需求。

总 结

搬迁到 Karpenter 对 Adevinta 来说是一次严重的改动。经过运用 Karpenter，Adevinta 不只完结了更顺利的集群晋级，还在实例挑选上获得了更大的灵敏性，提高了作业负载阻隔才能，完结了主动化的安全更新，并节省了很多本钱。虽然依然面对一些应战，但全体收益远超这些问题。

关于需求大规划办理 Kubernetes 的团队来说，Karpenter 供给了许多实实在在的优点，能够简化运维，削减办理担负。

引荐阅览

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

Karpenter v1.0.0对K8s弹性弹性意味着什么？

Grafana怎么运用Karpenter消除50%的云资源糟蹋？｜落地事例