Kubernetes 포드 주의: 1개 노드에서 볼륨 노드 선호도 충돌이 발생했습니다.

Kubernetes 포드 주의: 1개 노드에서 볼륨 노드 선호도 충돌이 발생했습니다.

Kubernetes 클러스터를 설치하려고 합니다.Persistent Volume, Persistent Volume Claim 및 Storage 클래스를 모두 설정하고 실행하고 있지만 배포에서 포드를 생성하려는 경우 포드가 생성되지만 Pending 상태로 중단됩니다.설명 후 "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: {}

"볼륨 노드 선호도 충돌" 오류는 포드가 사용 중인 영구 볼륨 주장이 한 영역이 아닌 다른 영역에서 예약되어 있으므로 다른 영역의 볼륨에 연결할 수 없으므로 실제 포드를 예약할 수 없는 경우에 발생합니다.이를 확인하려면 모든 Persistent Volume(영구 볼륨)의 세부 정보를 확인할 수 있습니다.이를 확인하려면 먼저 PVC를 구입합니다.

$ kubectl get pvc -n <namespace>

그런 다음 볼륨 클레임이 아닌 영구 볼륨에 대한 세부 정보를 가져옵니다.

$  kubectl get pv

PVC에 해당하는 PV를 찾아 설명합니다.

$  kubectl describe pv <pv1> <pv2>

Source를 확인할 수 있습니다.각 PV의 볼륨 ID는 서로 다른 가용성 영역일 가능성이 크므로 포드에서 선호도 오류가 발생합니다.이 문제를 해결하려면 단일 영역에 대한 스토리지 클래스를 생성하고 PVC에서 해당 스토리지 클래스를 사용합니다.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: region1storageclass
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  encrypted: "true" # if encryption required
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: failure-domain.beta.kubernetes.io/zone
    values:
    - eu-west-2b # this is the availability zone, will depend on your cloud provider
    # multi-az can be added, but that defeats the purpose in our scenario

0. 다른 대답에서 해결책을 찾지 못했다면...

우리의 경우 Pulumi로 새로 프로비저닝된 AWS EKS 클러스터에서 오류가 발생했습니다(전체 출처 참조).그 실수는 저를 미치게 했습니다. 저는 아무것도 바꾸지 않았기 때문에, 단지 그것을 만들었을 뿐입니다.PersistentVolumeClaim Buildpacks Tekton 문서에 설명된 바와 같이:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: buildpacks-source-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi

EKS /도 .PersistentVolume아니면StorageClass(사실 저는 그것을 어떻게 하는지도 몰랐습니다.)기본 EKS 설정이 2개의 노드에 의존하는 것 같아 오류가 발생했습니다.

0/2 nodes are available: 2 node(s) had volume node affinity conflict.

Sownak Roy의 답변을 읽고 나는 무엇을 해야할지 첫번째 접착제를 얻었지만 어떻게 해야할지 몰랐습니다.여기에 관심있는 분들을 위해 오류를 해결하기 위한 저의 모든 조치가 있습니다.

1. EKS 확인failure-domain.beta.kubernetes.io

와 같이 Statefull applications 이 게시물에서는 두 노드가 다른 AWS 가용성 영역에 PV(Persistent Volume)로 프로비저닝되며, 이는 우리의 PV를 적용하여 생성됩니다.PersistendVolumeClaim

/를 .kubectl get nodes:

$ kubectl get nodes
NAME                                             STATUS   ROLES    AGE     VERSION
ip-172-31-10-186.eu-central-1.compute.internal   Ready    <none>   2d16h   v1.21.5-eks-bc4871b
ip-172-31-20-83.eu-central-1.compute.internal    Ready    <none>   2d16h   v1.21.5-eks-bc4871b

한 번 보세요.Labelkubectl describe node <node-name>:

$ kubectl describe node ip-172-77-88-99.eu-central-1.compute.internal
Name:               ip-172-77-88-99.eu-central-1.compute.internal
Roles:              <none>
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/instance-type=t2.medium
                    beta.kubernetes.io/os=linux
                    failure-domain.beta.kubernetes.io/region=eu-central-1
                    failure-domain.beta.kubernetes.io/zone=eu-central-1b
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=ip-172-77-88-99.eu-central-1.compute.internal
                    kubernetes.io/os=linux
                    node.kubernetes.io/instance-type=t2.medium
                    topology.kubernetes.io/region=eu-central-1
                    topology.kubernetes.io/zone=eu-central-1b
Annotations:        node.alpha.kubernetes.io/ttl: 0
...

가 ip-172-77-88-99.eu-central-1.compute.internal가지다failure-domain.beta.kubernetes.io/regioneu-central-1와의 아즈고 아즈.failure-domain.beta.kubernetes.io/zone.eu-central-1b.

그리고 다른 노드는 다음과 같이 정의합니다.failure-domain.beta.kubernetes.io/zone아즈eu-central-1a:

$ kubectl describe nodes ip-172-31-10-186.eu-central-1.compute.internal
Name:               ip-172-31-10-186.eu-central-1.compute.internal
Roles:              <none>
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/instance-type=t2.medium
                    beta.kubernetes.io/os=linux
                    failure-domain.beta.kubernetes.io/region=eu-central-1
                    failure-domain.beta.kubernetes.io/zone=eu-central-1a
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=ip-172-31-10-186.eu-central-1.compute.internal
                    kubernetes.io/os=linux
                    node.kubernetes.io/instance-type=t2.medium
                    topology.kubernetes.io/region=eu-central-1
                    topology.kubernetes.io/zone=eu-central-1a
Annotations:        node.alpha.kubernetes.io/ttl: 0
...

.PersistentVolume의topology.kubernetes.io

우리는 .PersistentVolume다를 한 후 .PersistentVolumeClaim.사용하다kubectl get pv:

$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                           STORAGECLASS   REASON   AGE
pvc-93650993-6154-4bd0-bd1c-6260e7df49d3   1Gi        RWO            Delete           Bound    default/buildpacks-source-pvc   gp2                     21d

를 이어 kubectl describe pv <pv-name>

$ kubectl describe pv pvc-93650993-6154-4bd0-bd1c-6260e7df49d3
Name:              pvc-93650993-6154-4bd0-bd1c-6260e7df49d3
Labels:            topology.kubernetes.io/region=eu-central-1
                   topology.kubernetes.io/zone=eu-central-1c
Annotations:       kubernetes.io/createdby: aws-ebs-dynamic-provisioner
...

PersistentVolume되었습니다.topology.kubernetes.io/zone아즈로eu-central-1c, 이 때문에 우리 포드들이 볼륨을 찾지 못하는 것에 대해 불평하게 됩니다. 완전히 다른 az에 있기 때문입니다!

을 더합니다.allowedTopologies.StorageClass

Kubernetes 문서에 명시된 바와 같이 문제에 대한 한가지 해결책은 다음을 추가하는 것입니다.allowedTopologiesStorageClass된 . EKS 를 StorageClass와 함께

kubectl get storageclasses gp2 -o yaml

합니다라는 합니다.storage-class.yml가 추가됩니다.allowedTopologiesfailure-domain.beta.kubernetes.io다음과 같은 레이블:

allowedTopologies:
- matchLabelExpressions:
  - key: failure-domain.beta.kubernetes.io/zone
    values:
    - eu-central-1a
    - eu-central-1b

allowedTopologies합니다.failure-domain.beta.kubernetes.io/zonePersistentVolume 중 .eu-central-1a아니면eu-central-1b --eu-central-1c!

storage-class.yml다음과 같습니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp2
parameters:
  fsType: ext4
  type: gp2
provisioner: kubernetes.io/aws-ebs
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: failure-domain.beta.kubernetes.io/zone
    values:
    - eu-central-1a
    - eu-central-1b

된 적용StorageClassEKS성을 :

kubectl apply -f storage-class.yml

4.PersistentVolumeClaim,더하다storageClassName: gp2를 다시 적용하고y

진행되려면 해야 합니다.PersistentVolumeClaim,째

과 같이 하십시오.PersistentVolumeClaim와 같이StorageClass추가할 필요가 있습니다.storageClassName: gp2하십시오.pvc.yml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: buildpacks-source-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi
  storageClassName: gp2

마지막으로 다시 적용합니다.PersistentVolumeClaim와 함께kubectl apply -f pvc.yml 그러면 오류가 해결됩니다.

이 오류를 발생시킬 수 있는 몇 가지 사항이 있습니다.

1. 노드에 레이블이 제대로 지정되지 않았습니다.작업자 노드에 다음과 같은 적절한 레이블이 없을 때 AWS에서 이 문제가 발생했습니다(마스터에 레이블이 있음).

   failure-domain.beta.kubernetes.io/region=us-east-2

   failure-domain.beta.kubernetes.io/zone=us-east-2c

   레이블로 노드를 패치한 후 "1 노드에 볼륨 노드 선호도 충돌이 있었습니다"라는 오류가 사라졌으므로 포드가 포함된 PV, PVC가 성공적으로 배포되었습니다.이러한 레이블의 가치는 클라우드 공급자별로 다릅니다.기본적으로 이러한 레이블을 설정하는 것은 클라우드 제공자(cube-controller, API-server, kubelet에 정의된 클라우드 제공자 옵션 포함)의 일입니다.적절한 레이블이 설정되어 있지 않으면 CloudProvider 통합이 올바른지 확인합니다.쿠베뎀을 사용해서 설치가 번거롭지만 다른 도구, 예를 들어 캅스를 사용하면 바로 작동합니다.

2. PV 정의와 nodeAffinity 필드의 사용법에 따라 로컬 볼륨(local volume description link, 공식 문서 참조)을 사용하려고 한 다음 "NodeAffinity 필드"를 다음과 같이 설정해야 합니다(AWS에서 작동했습니다).

   node친화도:

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

리소스를 생성하고 실행 중인 리소스를 설명하면 다음과 같이 표시됩니다.

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

3. 로컬 스토리지가 제대로 작동하려면 volumeBindingMode가 WaitForFirstConsumer로 설정된 상태에서 StorageClass 정의(local-storage로 명명됨, 여기에 게시되지 않음)를 생성해야 합니다.여기에 있는 스토리지 클래스의 현지 설명, 공식 문서의 예를 참조하여 그 배경을 파악합니다.

"1개의 노드에 볼륨 노드 선호도 충돌이 있었습니다" 오류가 발생한 것은 스케줄러가 포드를 호환되는 노드로 스케줄링할 수 없기 때문입니다.persistenvolume.spec.nodeAffinityPV(Persistent Volume) 의 필드에 입력합니다.

에서 이 는 , PV 에서 PV 를 이 있는 되어야 한다고 .kubernetes.io/cvl-gtv-42.corp.globaltelemetrics.eu = master하지만

팟이 이러한 노드에 예약될 수 없는 다양한 이유가 있을 수 있습니다.

• 포드에 대상 노드와 충돌하는 노드 선호도, 포드 선호도 등이 있습니다.
• 대상 노드가 오염됨
• 대상 노드가 "노드당 최대 포드 수" 제한에 도달했습니다.
• 지정된 레이블을 가진 노드가 없습니다.

원인을 찾기 시작하는 곳은 노드와 포드의 정의입니다.

두통으로 인해 조사가 진행된 후 확인해야 할 몇 가지 사항이 있습니다.

애저:

• 클러스터에 둘 이상의 영역이 선택되었습니까? (영역 1, 2, 3)
• 기본 스토리지 클래스에 올바른 스토리지 공급자가 있습니까? (ZRS Zone-Redundant-Storage)

그렇지 않은 경우:

• 올바른 공급자를 사용하도록 저장소 클래스 변경
• PV 데이터 백업 생성
• PVC를 사용하는 배포를 중지합니다(복제본을 0으로 설정).
• PVC를 삭제하고 관련 PV가 삭제되었는지 확인합니다.
• PVC 구성 yaml을 다시 적용합니다(이전 저장소 클래스 이름을 참조하지 않음).
• PVC를 사용하는 배포 시작(레플리카를 1로 설정)
• 수동으로 백업 데이터 가져오기

AKS의 스토리지 클래스 예:

allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: zone-redundant-storage
parameters:
  skuname: StandardSSD_ZRS
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

GKE:

• 클러스터에 둘 이상의 영역이 선택되었습니까?(존 A, B, C)
• 기본 스토리지 클래스에 복제 유형 매개 변수가 있습니까?(replic 유형: regional-pd)

그렇지 않은 경우:

• 올바른 매개 변수를 사용하도록 저장소 클래스 변경
• PV 데이터 백업 생성
• PVC를 사용하는 배포를 중지합니다(복제본을 0으로 설정).
• PVC를 삭제하고 관련 PV가 삭제되었는지 확인합니다.
• PVC 구성 yaml을 다시 적용합니다(이전 저장소 클래스 이름을 참조하지 않음).
• PVC를 사용하는 배포 시작(레플리카를 1로 설정)
• 수동으로 백업 데이터 가져오기

GKE의 스토리지 클래스 예:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: standard-regional-pd-storage
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-standard
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer

그 후 PV는 선택한 구역 전체에 걸쳐 중복성을 갖게 되어 포드가 다른 구역의 다른 노드에서 PV에 액세스할 수 있게 됩니다.

Sownak Roy의 멋진 답변.PV를 사용하기로 되어 있던 노드와 비교하여 다른 영역에서 PV를 생성하는 경우는 동일했습니다.제가 적용한 솔루션은 Sownak의 답변을 기반으로 한 것으로, 다음과 같이 "허용되는 토폴로지" 목록 없이 스토리지 클래스를 지정하기에 충분했습니다.

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

AWS EKS에서는 Kubernetes 클러스터를 1.22에서 1.23으로 업그레이드하기 전에 aws-ebs-csi-driver EKS addon을 설치하지 않은 경우에도 이 문제가 발생할 수 있습니다.

업그레이드 후 추가 기능을 설치할 수도 있습니다(일부 서비스 중단이 있을 경우도 있습니다).

이에 대한 AWS FAQ 확인: https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi-migration-faq.html

저는 k8s v1.25로 업그레이드 후 GKE에서 발생한 일입니다.저의 경우에는 위의 내용 중 아무 것도 효과가 없어서 데이터를 잃고 싶지 않아서 볼륨 복제에 대해 알아봤습니다.

이 게시물을 통해 Compute Engine 영구 디스크 CSI Driver를 활성화할 수 있었습니다. CSI Driver를 활성화하면 문제가 해결됩니다.

저의 경우, 근본 원인은 지속 볼륨이 us-west-2c에 있고 새로운 워커 노드가 us-west-2a 및 us-west-2b에 재출시되기 때문이었습니다.해결책은 더 많은 구역에 있도록 더 많은 워커 노드를 보유하거나 더 많은 워커 노드가 영구 볼륨에 국한되도록 애플리케이션에 대한 노드 선호도를 제거/확대하는 것입니다.

1. Kubernetes 노드에 필요한 레이블이 있는지 확인합니다.다음을 사용하여 노드 레이블을 확인할 수 있습니다.

kubectl get nodes --show-labels

kubernetes 노드 중 하나에 영구 볼륨의 이름/라벨이 표시되고 포드가 동일한 노드에서 예약되어야 합니다.

2. 를 합니다 합니다.PersistentVolumeClaim다의 합니다.PersistentVolume . resources.requests.storage인에PersistentVolumeClaim아니면 오래된 것을 삭제합니다.PersistentVolume정확한 크기의 새 제품을 만듭니다.

---

확인 단계:

1. 지속적인 볼륨을 설명합니다.

kubectl describe pv postgres-br-proxy-pv-0

출력:

...
Node Affinity:
  Required Terms:
    Term 0:        postgres-br-proxy in [postgres-br-proxy-pv-0]
...

2. 노드 레이블 표시:

kubectl get nodes --show-labels

출력:

NAME    STATUS   ROLES    AGE   VERSION   LABELS
node3   Ready    <none>   19d   v1.17.6   postgres-br-proxy=postgres-br-proxy-pv-0

포드가 사용 중인 노드에서 영구 볼륨 레이블을 가져오지 않으면 포드가 예약되지 않습니다.

GCP GKE와는 다른 경우입니다. 지역 클러스터를 사용하고 있고 PVC를 2개 생성했다고 가정합니다.두 개 모두 다른 영역에서 작성되었습니다(여러분은 알지 못했습니다).

다음 단계에서 두 PVC를 동일한 포드에 장착한 포드를 실행하려고 합니다.해당 포드를 특정 영역의 특정 노드로 스케줄링해야 하지만 볼륨이 다른 영역에 있기 때문에 k8s에서는 이를 스케줄링할 수 없으며 다음과 같은 문제가 발생합니다.

예를 들어, 지역 클러스터(서로 다른 영역에 있는 노드)에 있는 두 개의 간단한 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

다음으로 간단한 포드:

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가 poding을 예약할 수 없게 될 수 있습니다.

여기 기술된 거의 같은 문제...https://github.com/kubernetes/kubernetes/issues/61620

"로컬 볼륨을 사용하는 경우 노드가 충돌하면 포드를 다른 노드로 다시 예약할 수 없습니다.동일한 노드에 예약해야 합니다.이것이 로컬 스토리지를 사용할 때 주의해야 할 사항입니다. 따라서 Pod는 하나의 특정 노드에 영원히 묶여 있게 됩니다."

쿠버네티스 클러스터의 노드 수를 줄였고 일부 "지역"은 더 이상 사용할 수 없게 되었습니다.

언급할 만한 것이...포드가 영구 볼륨과 다른 영역에 있을 경우:

• 디스크 액세스 시간이 크게 단축됩니다(로컬 영구 스토리지는 더 이상 로컬 스토리지가 아닙니다. Amazon/Google의 파이버 초고속 링크를 사용하더라도 데이터 센터 간에 트래픽이 계속 발생합니다.)
• "지역 간 네트워크"에 대한 비용을 지불하게 됩니다. (AWS 청구서에는 "EC2-other"에 들어가는 것이며 AWS 청구서를 드릴다운한 후에야 발견할 수 있습니다.)

이것의 한 가지 원인은 아래와 같은 정의(이 예제의 Kafka Zookeeper)가 있는 경우로, 하나의 컨테이너에 여러 개의 pvc를 사용합니다.다와 수 ..volume node affinity conflict하고 . 의 pvc 입니다를 입니다.subPathvolumeMount.

문제

      ...
      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"

저 같은 경우는 제가 함께 일을 하고 있었습니다.minikube위에Docker Desktop위에Windows 했습니다.docker-desktop값을 노드 이름으로 지정합니다. 이 상당히 그래서 설정이 상당히 중요합니다.

했습니다.minikube하나의 노드를 사용하고 있었기 때문에.추가 노드가 추가되면 더 많을 수 있습니다. 예가 있습니다.minikube-m02.

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

kubectl get node노드 이름을 지정하기에 충분해야 합니다.

이 오류가 발생하는 또 다른 이유는 얼룩을 사용하는 노드가 혼재되어 있는 경우입니다. 얼룩이 있는 하려고 할 때 해당 에서는 CSI가 없습니다. 만약 당신이 얼룩이 있는 노드에 포드를 예약하려고 할 때, 그것 때문에 그것은 다음을 허용하지 않습니다.ebs-csi-node포드가 작동하면 오류가 발생합니다.

제 했습니다를 했습니다.PersistentVolumeClaimPod그리고 포드를 다시 만들었습니다.

저는 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에서 일한다면 당신을 위해 일할 것입니다.

제 사건은 포스트호그 사건이었습니다.

언급URL : https://stackoverflow.com/questions/51946393/kubernetes-pod-warning-1-nodes-had-volume-node-affinity-conflict