Kubernetes Pod警告：1个节点存在卷节点亲和性冲突。

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

接下来，您尝试运行将两个 PVC 挂载到同一 pod 上的 pod。您必须将该 pod 调度到特定区域的特定节点上，但由于您的卷位于不同的区域，因此 k8s 将无法调度该 pod，您将收到以下问题：

例如：区域性群集上的两个简单 PVC（多个节点分布在不同的区域）：

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

下一个简单的 Pod：

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。

这里描述的问题几乎相同... https://github.com/kubernetes/kubernetes/issues/61620

"如果您正在使用本地卷，并且节点崩溃，则无法将您的 Pod 重新调度到其他节点。它必须被调度到同一节点。这是使用本地存储的一个警告，您的 Pod 将永远绑定在一个特定的节点上。"

其中一个原因是当你有如下定义（以Kafka Zookeeper为例），使用多个pvcs用于一个容器。如果它们落在不同的节点上，你将会得到类似以下的错误：..volume node affinity conflict。解决方案是使用一个pvc定义，并在volumeMount上使用subPath。

问题

      ...
      volumeMounts:
        - mountPath: /data
          name: kafka-zoo-data
        - mountPath: /datalog
          name: kafka-zoo-datalog
  restartPolicy: Always
  volumes:
    - name: kafka-zoo-data
      persistentVolumeClaim:
        claimName: "zookeeper-data"
    - name: kafka-zoo-datalog
      persistentVolumeClaim:
        claimName: "zookeeper-datalog"

已解决

      ...
      volumeMounts:
        - mountPath: /data
          subPath: data
          name: kafka-zoo-data
        - mountPath: /datalog
          subPath: datalog
          name: kafka-zoo-data
  restartPolicy: Always
  volumes:
    - name: kafka-zoo-data
      persistentVolumeClaim:
        claimName: "zookeeper-data"

在我的情况下，我正在使用Windows上的Docker Desktop中的minikube，并且我的示例只使用docker-desktop值作为节点名称。所以设置非常重要。
因为我使用的是单个节点，所以我添加了minikube。如果添加了其他节点，例如minikube-m02，则可能会有更多节点。

spec:
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - minikube

kubectl get node 应该足以提供节点名称。

最可能的情况是您在kubernetes集群中减少了节点数量，因此一些“区域”不再可用...
值得一提的是...如果您的pod位于不同的区域，则：
- 您的磁盘访问时间将显著下降（您的本地持久存储不再是本地的 - 即使使用亚马逊/谷歌的光纤超快速链接，仍会跨数据中心传输） - 您将支付“跨区域网络”费用（在您的AWS账单上，它属于“EC2-other”，只有在深入挖掘Aws账单后才能发现）

此错误发生的另一个原因是如果您的节点混合使用了taints。在某些版本中，EBS CSI驱动程序的DaemonSet组件默认情况下不能容忍所有的taints；如果您尝试将一个Pod调度到具有taint的节点上，并且由于该taint导致它没有运行ebs-csi-node Pod，您会遇到此错误。

在我的情况下，我只是删除了与冲突的Pod相关联的PersistentVolumeClaim，然后重新创建了该pod。

我在AWS上运行k8s集群，在我的情况下，PV被描述为

│ Node Affinity:                                                                           │
│   Required Terms:                                                                        │
│     Term 0:        topology.kubernetes.io/zone in [ap-southeast-1a]                      │
│                    topology.kubernetes.io/region in [ap-southeast-1]

但是当我添加了

topology.ebs.csi.aws.com/zone=ap-southeast-1a
topology.ebs.csi.aws.com/region=ap-southeast-1

将标签添加到我的节点，容器开始创建。如果您正在使用AWS，则应该适用于您。

我的情况是posthog（自托管）。