节点池 - NodePool II

资源限制

在上节中,我们在NodePool 中添加了一个限制,即"cpu=10”。我们将看一下应用程序在 NodePool 限制之外扩展的情况。

  limits:
    cpu: "10"

扩展副本

让我们将应用程序增加到 12 个副本。12 个副本超过了 nodepool 的限制。

kubectl scale deployment inflate --replicas 12

在kube ops view中看到先将7个pod部署到原来的c6a.2x节点上,还有五个pending pod:

image-20240803161814971

Karpenter 会再拉起一个新节点,但由于 nodepool 限制,仍有一些 pod 处于pending状态。

image-20240803162001397

我们也可以使用以下命令检查pending pod

kubectl  get pods| grep Pending
kongpingfan:~/environment/karpenter $ kubectl  get pods| grep Pending
inflate-846b659bf9-5wdss            0/1     Pending   0          3m17s
inflate-846b659bf9-nrclw            0/1     Pending   0          3m17s
inflate-846b659bf9-v9qd7            0/1     Pending   0          3m17s
inflate-846b659bf9-xbv9m            0/1     Pending   0          3m17s

上过的过程总结如下:

  1. Karpenter 将 2 个新的应用程序 pod 调度到现有的 karpenter 节点 c6a.2xlarge(拥有 8 个 vCPU)
  2. 然后,它启动了新的节点 c6a.large(拥有 2 个 vCPU),并在那里添加了一个应用程序 pod。
  3. 现在,12 个应用程序 pod 中有 8 个已部署。
  4. 由于 NodePool 的限制为"10”,我们已经用这两个节点(8vCPU + 2vCPU)耗尽了该限制。
  5. 因此,剩余的 4 个 pod 将处于pending状态,因为 Karpenter 将无法再创建任何其他节点。

检查 Karpenter 的日志:

kubectl -n karpenter logs -l app.kubernetes.io/name=karpenter

我们应该看到 launched new instance 消息以及 Could not schedule pod, all available instance types exceed nodepool limits 消息

image-20240803162329179

检查 Karpenter 创建的节点。

kubectl get nodes -l eks-immersion-team=my-team

image-20240803162414241

disruption


Karpenter 使用 NodePool 中的 consolidateAfter 字段来终止节点。consolidateAfter 字段指定节点在被终止之前保持空闲的时间。当 Karpenter 认为一个节点为空时,意味着所有 pod 已成功移出该节点,Karpenter 会等待指定的 consolidateAfter 时间后才会终止该节点。我们添加了如下的 consolidateAfter

spec:                     
  disruption:
    consolidateAfter: 30s
    consolidationPolicy: WhenEmpty
    expireAfter: Never

将 pod 数量缩减到零,看看 Karpenter 是否能在 30 秒后清空节点。

kubectl scale deployment inflate --replicas 0

kube ops view会立即检查到pod数量的减少:

image-20240803162717630

过一会后,之前添加的两个节点在 Karpenter 发现这些节点没有工作负载后被删除了。我们只剩下下面两个来自 EKS 集群初始设置的节点。

image-20240803162747784

检查 Karpenter 的日志:

kubectl -n karpenter logs -l app.kubernetes.io/name=karpenter

我们应该在日志中看到 disrupting via emptiness delete 消息: image-20240803162833318