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

时间:2020-11-07 14:39:37

标签: kubernetes kubernetes-pod kubernetes-deployment

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

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

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

2 个答案:

答案 0 :(得分:1)

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

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

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

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

答案 1 :(得分:0)

首次设置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。