Kubernetes不愿意在自动扩展的GKE节点池中的节点上调度守护程序吊舱

我们发现GKE kubernetes调度程序无法或不愿意在自动伸缩节点池中的节点上调度守护程序吊舱存在问题

我们在集群中有三个节点池，但是

pool-x

池用于专门安排由HPA支持的单个部署，节点在此池中应用了污点“node use=pool-x:NoSchedule”。我们还部署了一个filebeat守护程序集，在该守护程序集上我们设置了一个非常宽松的容忍规范

operator:Exists

（希望这是正确的）集，以确保在群集中的每个节点上调度守护程序

我们的假设是，随着

pool-x

的自动放大，filebeat守护程序将在调度分配给该节点上的任何POD之前在该节点上进行调度。但是，我们注意到，随着新节点添加到池中，filebeat pod无法放置在节点上，并且处于永久的“挂起”状态。下面是一个filebeat守护程序集的描述输出（截断）示例：

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播客的事件：

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之前没有将守护程序pod放置在节点上。似乎守护程序集的定义本身就需要优先级调度

同样值得注意的是，如果我删除某个节点上的一个pod，其中filebeat由于无法满足CPU请求而处于“挂起”调度状态，则filebeat将立即在该节点上调度，这表明存在某种调度优先级

最终，我们只想确保filebeat守护程序能够在集群中的每个节点上安排一个pod，并使该优先级与我们的集群自动缩放和HPA配合使用。关于我们如何实现这一目标，有什么想法吗

---

我们希望避免使用，因为它显然是GKE中的alpha功能，目前我们无法使用它。

在kubernetes 1.12守护程序由其自己的控制器调度之前，在该版本之后，部署守护程序由默认调度程序管理，希望优先级，先发制人和容忍涵盖所有情况。 如果希望守护程序计划程序管理守护程序的计划，请选中 ScheduleDaemonSetPods功能

---

您所期望的首先在节点上调度守护程序吊舱的行为已不再是现实。自1.12版以来，守护程序吊舱由默认调度程序处理，并依赖于来确定吊舱的调度顺序。您可能需要考虑创建一个优先级级别的类，它具有相对较高的<代码>值<代码>，以确保它们在大多数其他的POD之前被调度。

POD优先级在beta中为1.11，而GA为1.14。任何超过1.11的版本都会有一个相对稳定的功能版本。