Docker Kubernetes Pod警告：1个节点存在卷节点关联冲突

我尝试建立Kubernetes集群。我已经设置并运行了持久卷、持久卷声明和存储类，但当我想从部署中创建pod时，pod已创建，但它挂起在挂起状态。在描述之后，我只收到此警告“1个节点有卷节点关联冲突”。有人能告诉我卷配置中缺少什么吗

apiVersion: v1
kind: PersistentVolume
metadata:
  creationTimestamp: null
  labels:
    io.kompose.service: mariadb-pv0
  name: mariadb-pv0
spec:
  volumeMode: Filesystem
  storageClassName: local-storage
  local:
    path: "/home/gtcontainer/applications/data/db/mariadb"
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 2Gi
  claimRef:
    namespace: default
    name: mariadb-claim0
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/cvl-gtv-42.corp.globaltelemetrics.eu
            operator: In
            values:
            - master

status: {}

---

这里描述的问题几乎相同。。。

---

“如果您使用的是本地卷，并且节点崩溃，您的pod将无法重新调度到其他节点。必须将其调度到同一节点。这是使用本地存储的警告，您的pod将永远绑定到一个特定节点。”

有几件事可能导致此错误：

节点未正确标记。我在AWS上遇到了这个问题，当时我的worker节点没有合适的标签（master有这样的标签）：

故障域.beta.kubernetes.io/region=us-east-2

故障域.beta.kubernetes.io/zone=us-east-2c

使用标签修补节点后，“1个节点具有卷节点亲缘关系冲突”错误消失，因此成功部署了带有pod的PV、PVC。 这些标签的值是特定于云提供商的。基本上，设置这些标签是云提供者的工作（在cube controller、API server、kubelet中定义了-cloud provider选项）。如果未设置适当的标签，请检查CloudProvider集成是否正确。我使用了kubeadm，因此设置起来很麻烦，但是使用其他工具，例如kops，它可以立即工作

根据您的PV定义和nodeAffinity字段的使用情况，您正在尝试使用本地卷（请阅读此处），然后确保您将“nodeAffinity字段”设置为这样（在我的AWS案例中它起作用）：

节点相关性：

     required:
      nodeSelectorTerms:
       - matchExpressions:
         - key: kubernetes.io/hostname
           operator: In
           values:
           - my-node  # it must be the name of your node(kubectl get nodes)

因此，在创建资源并在其上运行descripe之后，它将显示在那里，如下所示：

         Required Terms:  
                    Term 0:  kubernetes.io/hostname in [your node name]

必须将volumeBindingMode设置为WaitForFirstConsumer来创建StorageClass定义（名为local storage，未在此处发布），本地存储才能正常工作。请参阅此处的示例以了解其背后的原因 当持久性卷声明pod正在使用的是在不同区域而不是在一个区域上调度的，因此实际pod无法调度，因为它无法从另一个区域连接到卷时，会发生错误“卷节点关联冲突”。要检查这一点，您可以查看所有持久卷的详细信息。 要检查这一点，请首先获取您的PVC：

$ kubectl get pvc -n <namespace>

找到与您的PVC相对应的PVs并描述它们

$  kubectl describe pv <pv1> <pv2>

“1个节点具有卷节点关联冲突”错误由计划程序创建，因为它无法将pod计划到符合PersistentVolume（PV）中的

persistenvolume.spec.nodeAffinity

字段的节点

换句话说，您在PV中说，使用此PV的pod必须调度到标签为

kubernetes.io/cvl-gtv-42.corp.globaltelemetrics.eu=master

的节点，但由于某些原因，这是不可能的

您的pod无法调度到此类节点可能有多种原因：

• pod具有与目标节点冲突的节点亲缘关系、pod亲缘关系等
• 目标节点已被污染
• 目标节点已达到其“每个节点的最大吊舱数”限制
• 不存在具有给定标签的节点

---

开始查找原因的地方是节点和pod的定义。

在我的例子中，根本原因是持久卷位于us-west-2c，新的工作节点重新启动，位于us-west-2a和us-west-2b。解决方案是要么拥有更多的工作节点，使其位于更多的区域中，要么删除/扩大应用程序的节点关联性，使更多的工作节点符合绑定到持久卷的条件。

与GCP GKE的情况不同。假设您正在使用regional cluster并创建了两个PVC。两者都是在不同的区域创建的（您没有注意到）

在下一步中，您将尝试运行将两个PVC安装到同一个pod上的pod。您必须将该pod调度到特定区域中的特定节点，但由于卷位于不同区域，k8s将无法调度该pod，您将遇到以下问题

例如，区域集群上的两个简单PVC（不同区域中的节点）：

下一个简单吊舱：

apiVersion: v1
kind: Pod
metadata:
  name: debug
spec:
  containers:
    - name: debug
      image: pnowy/docker-tools:latest
      command: [ "sleep" ]
      args: [ "infinity" ]
      volumeMounts:
        - name: disk-a
          mountPath: /disk-a
        - name: disk-b
          mountPath: /disk-b
  volumes:
    - name: disk-a
      persistentVolumeClaim:
        claimName: disk-a
    - name: disk-b
      persistentVolumeClaim:
        claimName: disk-b

---

最后，k8s可能无法安排pod，因为卷位于不同的区域。

索纳克·罗伊的回答很好。我遇到过同样的情况，一个PV被创建在一个不同的区域，而不是应该使用它的节点。我应用的解决方案是基于Sownak的答案的，仅在我的情况下，在没有“AllowedTopologys”列表的情况下指定存储类就足够了，如下所示：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cloud-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
volumeBindingMode: WaitForFirstConsumer

---

很可能您只是减少了kubernetes集群中的节点数量，而一些“区域”不再可用

值得一提的是。。。如果您的pod将位于与持久卷不同的区域，则：

• 您的磁盘访问时间将显著减少（您的本地持久性存储不再是本地存储—即使使用亚马逊/谷歌的光纤超高速链接，数据中心的流量仍然很大）
• 您将支付“跨区域网络”（在您的AWS账单上，它是进入“EC2其他”的内容，只有在深入了解AWS账单后，您才能发现）

---

感谢您的建议（2）最近在我的windows计算机上升级/重新安装后，我的Kubernetes节点的默认名称已悄悄地从“桌面docker”更改为“docker desktop”，我用于nodeAffinity只有主机名，而不是

kubectl get nodes

中描述的完全限定主机名-这是我的错误。谢谢！有没有办法让另一个区域的卷连接起来

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: disk-a
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: disk-b
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

apiVersion: v1
kind: Pod
metadata:
  name: debug
spec:
  containers:
    - name: debug
      image: pnowy/docker-tools:latest
      command: [ "sleep" ]
      args: [ "infinity" ]
      volumeMounts:
        - name: disk-a
          mountPath: /disk-a
        - name: disk-b
          mountPath: /disk-b
  volumes:
    - name: disk-a
      persistentVolumeClaim:
        claimName: disk-a
    - name: disk-b
      persistentVolumeClaim:
        claimName: disk-b

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cloud-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
volumeBindingMode: WaitForFirstConsumer