我们看到 GKE kubernetes 调度程序无法或不愿意在 Auto Scaling 节点池中的节点上调度 Daemonset pod 的问题。
我们在集群中有三个节点池,但是该pool-x
池用于排他地调度由 HPA 支持的单个部署,节点在此池中应用了污点“node-use=pool-x:NoSchedule”。我们还部署了一个 filebeat Daemonset,我们在其上设置了一个非常宽松的容忍规范operator: Exists
(希望这是正确的),以确保在集群中的每个节点上调度 Daemonset。
我们的假设是,在pool-x
自动扩展的情况下,filebeat Daemonset 将在调度分配给该节点的任何 pod 之前在该节点上调度。但是,我们注意到随着新节点添加到池中,filebeat pod 未能放置在节点上并且处于永久“待处理”状态。这是一个 filebeat Daemonset 的描述输出(截断)的示例:
Number of Nodes Scheduled with Up-to-date Pods: 108
Number of Nodes Scheduled with Available Pods: 103
Number of Nodes Misscheduled: 0
Pods Status: 103 Running / 5 Waiting / 0 Succeeded / 0 Failed
以及其中一个“待处理”filebeat pod 的事件:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 18m (x96 over 68m) default-scheduler 0/106 nodes are available: 105 node(s) didn't match node selector, 5 Insufficient cpu.
Normal NotTriggerScaleUp 3m56s (x594 over 119m) cluster-autoscaler pod didn't trigger scale-up (it wouldn't fit if a new node is added): 6 node(s) didn't match node selector
Warning FailedScheduling 3m14s (x23 over 15m) default-scheduler 0/108 nodes are available: 107 node(s) didn't match node selector, 5 Insufficient cpu.
可以看到,节点没有足够的资源来调度 filebeat pod CPU 请求由于节点上运行的其他 pod 而耗尽。但是,为什么在调度任何其他 pod 之前没有将 Daemonset pod 放置在节点上。似乎 Daemonset 的定义需要优先级调度。
另外值得注意的是,如果由于无法满足 CPU 请求而删除 filebeat 处于“待定”调度的节点上的 pod,则会立即在该节点上调度 filebeat,这表明观察到了一些调度优先级。
最终,我们只想确保 filebeat Daemonset 能够在集群中的每个节点上调度一个 pod,并让该优先级与我们的集群自动缩放和 HPA 很好地配合使用。关于我们如何实现这一目标的任何想法?
我们希望避免使用Pod Priority,因为它显然是 GKE 中的一个 alpha 功能,我们目前无法使用它。