11月
30

发表于

Karpenter是一个AWS提供的节点生命周期管理器，它会观察传入的pod并根据情况启动正确的节点。节点选择决策基于策略并由传入的pod的规范驱动，包括资源请求和调度约束。

img

它的主要作用：

  • 为不可调度的Pod启动节点
  • 替换现有的节点提高资源利用率
  • 如果超时或者不需要，则终止节点
  • 在抢占前优雅终止节点

优点

Karpenter观察未调度的Pod的聚合资源请求，并做出启动和终止节点的决定，以最大限度地减少调度延迟和基础设施成本。

优势

  1. 更快：Karpenter在AWS上直接与EC2队列API通信，可以根据pod的规格直接选择正确的实例类型，以实现快速自动扩展
  2. 更省钱：Karpenter根据工作负载要求提供节点，可以将pod打包成最小数量的适当大小节点，并节省成本
  3. 更灵活：使用karpenter无需创建数十个节点即可实现灵活性和多样性
  4. 对比原生的Cluster-Autoscaler，规避其原生的一些缺陷：例如在集群中添加或删除的容量限制、不能在Auto Scaling组中使用混合大小的集群…
  5. Karpenter自动检测存储依赖，例如如果原来节点拉取在A区，Pod第一次拉起时有创建PV（Persistent Volume），后续节点启动决策时会自动创建在A区（因为EBS是单可用区的，如果手动创建跨AZ可能会导致访问不通）

使用方法

前置准备

  1. 需要部署Metrics Server, 采集pod和node的指标用于资源约束
  2. 安装Karpenter controller， 这是Karpenter的核心控制器
  3. 安装Karpenter dashboard， 用于查看Karpenter管理的节点以及性能指标

Getting Started | Karpenter

karpenter provisioner 的模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  providerRef:
    name: default

  taints:
    - key: example.com/special-taint
      effect: NoSchedule

  startupTaints:
    - key: example.com/another-taint
      effect: NoSchedule

  labels:
    billing-team: my-team

  # Requirements that constrain the parameters of provisioned nodes.
  # These requirements are combined with pod.spec.affinity.nodeAffinity rules.
  # Operators { In, NotIn } are supported to enable including or excluding values
  requirements:
    - key: "karpenter.k8s.aws/instance-category"
      operator: In
      values: ["c", "m", "r"]
    - key: "karpenter.k8s.aws/instance-cpu"
      operator: In
      values: ["4", "8", "16", "32"]
    - key: "karpenter.k8s.aws/instance-hypervisor"
      operator: In
      values: ["nitro"]
    - key: "topology.kubernetes.io/zone"
      operator: In
      values: ["us-west-2a", "us-west-2b"]
    - key: "kubernetes.io/arch"
      operator: In
      values: ["arm64", "amd64"]
    - key: "karpenter.sh/capacity-type" # If not included, the webhook for the AWS cloud provider will default to on-demand
      operator: In
      values: ["spot", "on-demand"]

  kubeletConfiguration:
    clusterDNS: ["10.0.1.100"]
    containerRuntime: containerd
    systemReserved:
      cpu: 100m
      memory: 100Mi
      ephemeral-storage: 1Gi
    kubeReserved:
      cpu: 200m
      memory: 100Mi
      ephemeral-storage: 3Gi
    evictionHard:
      memory.available: 5%
      nodefs.available: 10%
      nodefs.inodesFree: 10%
    evictionSoft:
      memory.available: 500Mi
      nodefs.available: 15%
      nodefs.inodesFree: 15%
    evictionSoftGracePeriod:
      memory.available: 1m
      nodefs.available: 1m30s
      nodefs.inodesFree: 2m
    evictionMaxPodGracePeriod: 3m
    podsPerCore: 2
    maxPods: 20

  limits:
    resources:
      cpu: "1000"
      memory: 1000Gi

  consolidation:
    enabled: true

  ttlSecondsUntilExpired: 2592000 # 30 Days = 60 * 60 * 24 * 30 Seconds;

  ttlSecondsAfterEmpty: 30
  weight: 10

同时需要配置node template 模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  providerRef:
    name: default

  taints:
    - key: example.com/special-taint
      effect: NoSchedule

  startupTaints:
    - key: example.com/another-taint
      effect: NoSchedule

  labels:
    billing-team: my-team

  # Requirements that constrain the parameters of provisioned nodes.
  # These requirements are combined with pod.spec.affinity.nodeAffinity rules.
  # Operators { In, NotIn } are supported to enable including or excluding values
  requirements:
    - key: "karpenter.k8s.aws/instance-category"
      operator: In
      values: ["c", "m", "r"]
    - key: "karpenter.k8s.aws/instance-cpu"
      operator: In
      values: ["4", "8", "16", "32"]
    - key: "karpenter.k8s.aws/instance-hypervisor"
      operator: In
      values: ["nitro"]
    - key: "topology.kubernetes.io/zone"
      operator: In
      values: ["us-west-2a", "us-west-2b"]
    - key: "kubernetes.io/arch"
      operator: In
      values: ["arm64", "amd64"]
    - key: "karpenter.sh/capacity-type" # If not included, the webhook for the AWS cloud provider will default to on-demand
      operator: In
      values: ["spot", "on-demand"]

  kubeletConfiguration:
    clusterDNS: ["10.0.1.100"]
    containerRuntime: containerd
    systemReserved:
      cpu: 100m
      memory: 100Mi
      ephemeral-storage: 1Gi
    kubeReserved:
      cpu: 200m
      memory: 100Mi
      ephemeral-storage: 3Gi
    evictionHard:
      memory.available: 5%
      nodefs.available: 10%
      nodefs.inodesFree: 10%
    evictionSoft:
      memory.available: 500Mi
      nodefs.available: 15%
      nodefs.inodesFree: 15%
    evictionSoftGracePeriod:
      memory.available: 1m
      nodefs.available: 1m30s
      nodefs.inodesFree: 2m
    evictionMaxPodGracePeriod: 3m
    podsPerCore: 2
    maxPods: 20

  limits:
    resources:
      cpu: "1000"
      memory: 1000Gi

  consolidation:
    enabled: true

  ttlSecondsUntilExpired: 2592000 # 30 Days = 60 * 60 * 24 * 30 Seconds;

  ttlSecondsAfterEmpty: 30
  weight: 10

原理

利用Karpenter的分层约束模型，pod运行受到三层约束

  • 需要在依赖的应用程序或存储可用的区域中运行
  • 需要特定种类的处理器或者硬件（需要有对应的Node）
  • 希望使用拓扑扩展等技术来确保高可用性

第一层由云服务器厂商对硬件的类型，区域进行限制；第三层由其他技术控制pod调度；Karpenter通过设置Provisioner对指定节点进行调度和决策，从而满足第二层的控制

通过Provisioner 可以做到的限制包括

  • 资源请求：请求一定数量的内存或CPU。
  • 节点选择：选择在具有特定标签(nodeSelector)的节点上运行。
  • 节点亲缘性： 绘制pod以在具有特定属性(亲缘性)的节点上运行。
  • 拓扑扩展： 使用拓扑扩展来确保应用程序的可用性。
    Pod亲和性/反亲和性： 根据其他Pod的调度将Pod引向或远离拓扑域。

Karpenter 控制节点上下线的方式包括以下几种，

  • 删除Provisioner：删除Provisioner就会优雅下线其所有的节点
  • Emptiness： 当节点上不存在非daemonset的工作负载，同时启动了ttlSecondsAfterEmpty时，会在时间结束后回收节点
  • Expiration： 当设置了ttlSecondsUntilExpired 后，节点到达过期时间就会自动下线
  • Consolidation： Karpenter基于积极的节约策略，主动删除或者将节点换成更便宜的节点
    • 具体策略：
    • 如果一个节点的所有pod都可以在集群中其他节点的空闲容量上运行，则可以删除节点。
    • 如果一个节点的所有pod都可以在集群中其他节点的空闲容量和一个更便宜的替换节点的组合上运行，那么它就可以被替换。
  • Interruption： 启动中断检测后karpenter会判断节点是否即将发生中断事件并主动下线节点
    Drift：karpenter会下线出现漂移的节点，同时也会主动检测，把实例上使用的AMI与AWSNodeTemplate设置的AMI不匹配的节点打上标记
  • 手动删除： 通过eksctl 主动删除节点，同样会被karpenter优雅下线处理

使用场景

在aws中可以代替固定节点组的创建，基于taint以及 亲和性反亲和性，指定更灵活的策略进行节点的调度与约束

阅读全文 »
07月
20

发表于

MapReduce作为至今仍为流行的大数据计算框架，虽然早已在各个场景下均有竞品，但是凭借大保有量和集群较高的升级成本，现在依然在行业上占有较大规模。然而，随着技术不断迭代，以及用户对数据降本越来越高的需求，即使上层计算不变，下层配套设施比如存储，比如容器都可能会往更弹性，更经济的方向演进，从而会让计算在异构环境下运行的情形越来越多。

阅读全文 »
05月
25

发表于

本想着电影刚上映香港时就去看的，结果因为各种缘由直到一个月后才去成..但总归来说行程还是比较顺利的

阅读全文 »
02月
24

发表于

周末和朋友去看了《第二十一条》。这片本来不在我的观影列表之内，之前大致了解过是老谋子拍的电影，题材是法律相关。要是换做几年前或许我还会抱有较高期待，但是近年老谋子拍的电影数量很多，但大多偏商业，内容参差不齐，这难免让我对他的新作会抱有更谨慎的态度。

不过说内容参差不齐还略有些不妥当，但确实就近几年他的作品质量总是会引发不小的讨论，例如之前春节档上映的《满江红》，虽然很多人批评这部片整体质量偏低，也有很多人认为这部片很好看，市场反馈也很不错。究竟是什么原因会导致老谋子的作品总是争议不断，我始终抱有这个疑问。不过这次看了《第二十一条》，心里大致也有了答案。

阅读全文 »
06月
02

发表于

刚开始玩stable diffusion, 但用的整合包，很多训练知识都只是一知半解，现学现用，倒也是能炼出一些自己想要的作品。但是最近了解到升级pyTorch 和xformer之后可以极大提高训练lora的速度，这不由得让我产生了想升级的念头（刚到手的4070怎能没有榨干它的冲动），于是，开始了踩坑之路——其实也就是标题。

阅读全文 »
05月
13

发表于

最近工作中架构升级，将原来的EMR集群迁移到基于开源的自建集群上，原来使用的一些组件自然也需要改造，其中就包括s3。在我们的自建集群中，选用的开源hadoop中s3a client（或者s3a connector，下面简写成s3a, 意义基本相同）来连接原有的s3存储。接下来我就会分享我在用s3a client时总结的一些经验

阅读全文 »