Kubernetes不会在工作节点上安排Pod

如何解决Kubernetes不会在工作节点上安排Pod

我具有以下用于吊舱创建的代码。我有两个节点，一个主节点，另一个节点是工作节点，我要创建两个Pod，我需要在主节点上安排一个Pod，在工作节点上安排另一个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

非常感谢您在解决此问题方面的帮助。

我们非常感谢您的帮助。谢谢

解决方法

您可以使用nodeAffinity / antiAffinity解决此问题。

您为什么要将吊舱分配给主节点？

主节点是k8s集群的控制平面，如果您在主节点上调度的pod占用过多资源，可能会造成负面影响。

如果您真的想将Pod分配给主节点，我建议您取消污染1个主节点并删除NoSchedule异味，然后将nodeAffinity分配给该单个主节点，除非确实需要在所有主节点上运行它。

,

首次设置Kubernetes集群时，将在主节点上设置Taint。这会自动阻止在此节点上安排任何Pod。您已在主服务器上启用了计划Pod，因为您已对其进行标记以使Pod test在主服务器上运行。因此，kube-scheduler在调度其他Pod时将考虑主节点。 对于每个新创建的Pod或其他未计划的Pod，kube-scheduler选择一个最佳节点供其运行，如果未设置NotSchedule，则还选择主节点。详细了解node-selection。

这意味着您还必须配置工作程序节点和容器testing1，才能在特定的工作程序节点上部署此容器。

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

1. 您可以在nodeSelector部分下添加affinity: 来代替spec:：

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

将nodeSelector添加到您的广告连播中：

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不会驱逐已安排的Pod。因此，如果要测试和更改，请首先删除部署/吊舱，然后在标记/污染等之后重新部署它们。

未来注意事项：

如果您允许在主节点上运行的恶意Pod访问/劫持非Master节点上的Pod通常无法访问的Kubernetes功能，则总是有可能有人侵入对Pod /容器的访问权限，从而获得对Master的访问权限节点。 如果在主节点上运行流氓Pod破坏主组件，则它可能会破坏整个集群的稳定性。显然，这是生产部署所关心的问题，但是如果您希望最大程度地利用开发/试验环境中的少量节点，则可以在主服务器上运行几个额外的Pod。