Question

在我们的暂存环境中，报告了一个缺陷。 kubernetes更新后，某些Pods状态变为'MatchNodeSelector'。

但是我不知道为什么某些Pod为何以及如何变成'MatchNodeSelector'。因此，我进行了一些研究（如果Pod的字段为“ nodeSelector”，并且没有任何节点具有此标签）。这些Pod将成为“ MatchNodeSelector”。

但是我无法复制它。 Pods状态始终变为“待处理”，而不是“ MatchNodeSelector”。所以我的问题是，如何使Pod状态变为“ MatchNodeSelector”？

Answer 1

我能够通过以下方式重现此内容：

对于没有提供节点亲缘关系的任何运行的pod，请使用kubectl get po -o json --export导出其yaml或json。请注意运行它的节点
删除窗格。
向与运行该节点的先前节点不同的节点明确提供节点亲和力。将其添加到规范中，如下所示：

 "spec": {
     "affinity": {
        "nodeAffinity": {
          "requiredDuringSchedulingIgnoredDuringExecution": {
            "nodeSelectorTerms": [
              {
                "matchExpressions": [
                  {
                    "key": "kubernetes.io/hostname",
                    "operator": "In",
                    "values": [
                      "new node name"
                    ]
                  }
                ]
              }
            ]
          }
        }
      }
    }

使用kubectl create -f pod.json
Pod状态现在为MatchNodeSelector。

这是因为同一规范中也有一个node选项，也需要更改。它不会被--export选项删除，并且在该字段中仍具有较旧的节点名称。

我想如果它与您在亲和力中指定的任何节点名称相冲突，它将导致此状态。

这些是版本： `客户端版本：version.Info {主要：“ 1”，次要：“ 10”，GitVersion：“ v1.10.3”，GitCommit：“ 2bba0127d85d5a46ab4b778548be28623b32d0b0”，GitTreeState：“ clean”，BuildDate：“ 2018-05-21T09：17 ：39Z“，GoVersion：” go1.9.3“，编译器：” gc“，平台：” darwin / amd64“}

服务器版本：version.Info {主要：“ 1”，次要：“ 13”，GitVersion：“ v1.13.1”，GitCommit：“ eec55b9ba98609a46fee712359c7b5b365bdd920”，GitTreeState：“ clean”，BuildDate：“ 2018-12-13T10 ：31：33Z“，GoVersion：” go1.11.2“，编译器：” gc“，平台：” linux / amd64“}`

Answer 2

MatchNodeSelector是工作节点重新启动后观察到的Pod状态。它出现在使用.spec.nodeSelector节的pod上。会发生什么：

kubelet启动并从命令行加载标签，例如/usr/bin/kubelet ... --node-labels=node-kind.foo.io/master=
在启动期间，kubelet要求etcd提供以下信息：
- 过去通过API创建的其他节点标签的列表
- 要在节点上运行的Pod列表
有时在节点上应用全套标签之前，它会开始调出吊舱
应该将您的Pod在此节点上启动，并且其.spec.NodeSelector使用的是etcd / API中的标签，而不是命令行中的标签，则kubelet会看到Pod的期望值不匹配以及应用于此节点的标签（因为尚未处理来自etcd的完全刷新）
通常在合并全套标签（从cmd行和etcd）并很快启动下一个容器之后不久

参考：here和here

Pod状态如何变为MatchNodeSelector

2 个答案: