Karpenter上的调度

如果pod启动没有任何要求，Karpenter会从所有cloud provider的节点中选择一种来部署pod。

当然可以在上面添加限制，来选择启动Node的AZ及机型。Karpenter会先考虑这些限制，然后再来调度pod。

Karpenter的分层调度逻辑如下：

  • 第一层：Cloud Provider层面，所有可用的实例类型、架构(arm / amd64)、AZ和购买类型等

  • 第二层： NodePool中定义的可添加节点

  • 第三层： 应用 pod 的specifications中请求的约束,具体类型下面部分会接着介绍

image-20231028090803719

resources Request：Pod上可以设置所需的CPU 、Memory、GPU大小。假如我们将provioner限制最多10个CPU，而pod需要的更多，则provisioner开不出新的机器。

nodeSelector ：通过它来设置 label， 这样pod则会跑在同样设置该label的node上

node Affinity ：节点亲和性。将pod跑在特定亲和性的节点上

taints / tolerations ：对应Provisioner中的taints

topology Spread: 通过使用k8s的topologySpreadConstraints，您可以要求Provisioner将 Pod 相互散开到不同节点，以限制中断的影响范围。

Pod affinity / anti-affinity： 根据其他 Pod 的调度，决定本pod的调度

Pod disruption bucket: Karpenter根据PDB来使用指数回退的驱逐策略

参考：https://karpenter.sh/docs/concepts/scheduling/