我们看到GKE kubernetes调度程序无法或不愿意在自动伸缩节点池中的节点上调度Daemonset Pod的问题。
我们在群集中有三个节点池，但是pool-x池用于排他地安排由HPA支持的单个部署，节点的污染点为“ node-use = pool-x：NoSchedule”应用于他们在这个水池。我们还部署了filebeat守护程序集，我们在该文件集上设置了非常宽松的容忍规范operator: Exists（希望这是正确的），以确保在群集中的每个节点上调度该守护程序。
我们的假设是，随着pool-x的自动扩展，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
以及“待定”文件拍子之一的事件：
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容器CPU请求已耗尽，原因是该节点上正在运行其他容器。但是，为什么在调度任何其他Pod之前未将Daemonset Pod放置在节点上。好像非常定义Daemonset一样，必须进行优先级调度。
还要注意，如果我由于无法满足CPU请求而删除了文件信号为“待处理”调度的节点上的Pod，则会立即在该节点上调度文件信号，这表明观察到了一些调度优先级。
最终，我们只想确保filebeat Daemonset能够在集群中的每个节点上安排一个Pod，并使该优先级与我们的集群自动伸缩和HPA很好地配合使用。关于我们如何实现这一目标的任何想法？
我们希望避免使用Pod Priority，因为它显然是GKE中的alpha功能，因此我们暂时无法使用。
答案 0 :(得分：0)
在kubernetes 1.12守护程序集由他自己的控制器调度之前，在该版本之后，部署守护程序集由默认调度程序管理，希望优先级，先占权和宽容度涵盖所有情况。 如果要由守护程序调度程序管理守护程序的调度，请检查 ScheduleDaemonSetPods功能。
https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/
答案 1 :(得分：0)
您期望的DaemonSet Pod首先在节点上调度的行为不再是现实(since 1.12)。从1.12开始，DaemonSet Pod由默认调度程序处理，并依靠pod priority来确定Pod的调度顺序。您可能需要考虑为value相对较高的DaemonSet创建特定的priorityCLass，以确保它们排在大多数其他pod之前。