Kubernetes不会在工作节点上调度pod

Question

我有以下创建pod的代码。我有两个节点，一个是master节点，另一个是worker节点，我正在创建两个pod，我需要在master节点上调度一个pod，在worker节点上调度另一个pod。我没有指定在工作节点上调度pod second testing1，因为默认情况下，pod是在工作节点上调度的。但是第二个pod testing1也被调度在主节点上。

Yaml文件：

apiVersion: v1
kind: Pod
metadata:
   name: test
   labels:
      app: test
spec:
   containers:
     - name: test
       image: test:latest
       command: ["sleep"]
       args: ["infinity"]
       imagePullPolicy: Never
       ports:
         - containerPort: 8080
    nodeSelector:
      node_type: master_node
    tolerations:
     - key: node-role.kubernetes.io/master
       effect: NoSchedule

kind: Pod
metadata:
   name: testing1
   labels:
      app: testing1
spec:
   containers:
     - name: testing1
       image: testing1:latest
       command: ["sleep"]
       args: ["infinity"]
       imagePullPolicy: Never

非常感谢您在解决这个问题上的帮助。

非常感谢您的帮助。谢谢

Answer 1

你可以使用nodeAffinity / antiAffinity来解决这个问题。

为什么要将pod分配给主节点？

主节点是您的k8s集群的控制平面，如果您在主节点上调度的pod消耗太多资源，可能会产生负面影响。

如果您真的想将nodeAffinity分配给主节点，我建议您清除1个主节点并删除NoSchedule污染，然后为这个主节点分配一个pod，除非您确实需要在所有主节点上运行此操作。

Answer 2

第一次设置Kubernetes集群时，会在主节点上设置一个污点。这会自动阻止在此节点上调度任何pod。您已经在主服务器上启用了调度pod -因为您将其标记为使pod test在主服务器上运行。因此kube-scheduler会在调度其他pods时考虑主节点。对于每个新创建的pod或其他未调度的pod，kube-scheduler会为它们选择一个运行的最佳节点，如果没有设置NotSchedule，还会选择主节点。阅读有关node-selection的更多信息。

这意味着您还必须配置工作节点和pod testing1，以便可以在特定工作节点上部署此pod。

在除NodeSelector之外的特定节点上调度pod的不同选项

1. 而不是nodeSelector，您可以在spec:部分下添加affinity: ：

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        matchExpressions:
        ...

将nodeSelector添加到pod：

apiVersion: extensions/v1beta1
kind: Pod
...
spec:
...
      annotations:
        scheduler.alpha.kubernetes.io/tolerations: |
          [
            {
              ...
            }
          ]
    spec:
      nodeSelector:
        ...
    […]

1. 而不是nodeSelector，您可以添加如下所示的注释：

scheduler.alpha.kubernetes.io/affinity: >
  {
    "nodeAffinity": {
      "requiredDuringSchedulingIgnoredDuringExecution": {
        "nodeSelectorTerms": [
          {
            "matchExpressions": [
              {
               ...
              }
            ]
          }
        ]
      }
    }
  }

看一下：pod-deployment-on-master。

请记住，NoSchedule不会驱逐已调度的pods。因此，如果您想要测试和进行更改，首先删除部署/pod，然后在标记/污染等之后重新部署它们。

未来的笔记：

如果您允许运行在主节点上的流氓pod访问/劫持非主节点上的pod通常无法访问的Kubernetes功能，则总有可能有人黑客访问pod/容器，从而获得对主节点的访问权限。如果您在主节点上运行一个可中断主组件的流氓pod，则可能会破坏整个集群的稳定性。显然，这是生产部署的一个问题，但如果您希望最大化开发/实验环境中少量节点的利用率，那么在主服务器上运行两个额外的pod就可以了。