在上节中,我们在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:
Karpenter 会再拉起一个新节点,但由于 nodepool 限制,仍有一些 pod 处于pending状态。
我们也可以使用以下命令检查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
上过的过程总结如下:
检查 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
消息
检查 Karpenter 创建的节点。
kubectl get nodes -l eks-immersion-team=my-team
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数量的减少:
过一会后,之前添加的两个节点在 Karpenter 发现这些节点没有工作负载后被删除了。我们只剩下下面两个来自 EKS 集群初始设置的节点。
检查 Karpenter 的日志:
kubectl -n karpenter logs -l app.kubernetes.io/name=karpenter
我们应该在日志中看到 disrupting via emptiness delete
消息: