您可能应该使用Daemonsets，它正是为此目的而设计的，即为每个节点调度一个pod，并在群集自动扩展的情况下自动添加到新节点。

概念

将Pod分配给节点时有两件重要的事情-"关联"和"反关联"。

• 亲和性将基本上基于给定的标准进行选择，而反亲和性将基于给定的标准进行避免。
• 在亲和性和反亲和性中，可以使用In、NotIn、Exist、DoesNotExist、Gt和Lt等操作符，当使用NotIn和DoesNotExist时，则变为反亲和性。

现在，在关联/反关联中，您有两个选择-节点关联/反关联和pod间关联/反关联

节点关联/反关联

Node affinity在概念上类似于nodeSelector--它允许您根据节点上的标签来约束您的pod有资格被调度到哪些节点上。

舱间亲和力/反亲和力

通过Pod间关联性和反关联性，您可以根据节点上已运行的Pod上的标签（而不是节点上的标签）来限制有资格计划Pod的节点。

您的解决方案

基本上，你需要的是"Antiaffinity"和"Pod antiaffinity"，而不是节点。所以，你的解决方案应该看起来像下面这样（请注意，因为我没有3节点集群，所以我不能测试这个，所以你可能要做轻微的代码调整的机会很小）：

affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        labelSelector:
          - matchExpressions:
            - key: worker
              operator: In
              values:
              - log-scraper

在这里阅读更多内容，特别是在这里阅读示例。

使用Pod拓扑扩散约束

另一种方法是使用Pod拓扑扩散约束。
您将像往常一样设置污点和容差，以控制可以在哪些节点上调度pod。然后向pod添加一些标签。我将在示例中使用pod标签id: foo-bar。然后，为了允许每个节点仅调度来自replicaSet、deployment或其他的一个pod，请在pod规范中添加以下内容。

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        id: foo-bar

topologyKey是节点的标签。kubernetes.io/hostname是每个节点的默认标签集。请将pod标签放在matchLabels内。创建资源后，kubesscheduler应使用每个节点的匹配标签调度单个pod。
要了解更多信息，请查看文档here和此excellent blog post。