Предупреждение модуля Kubernetes: 1 узел (а) имел конфликт привязки узла тома

почти такая же проблема, описанная здесь ... https://github.com/kubernetes/kubernetes/issues/61620

"Если вы используете локальные тома, и узел выходит из строя, ваш модуль не может быть перенесен на другой узел. Он должен быть запланирован на тот же узел. Это предостережение при использовании локального хранилища, ваш модуль навсегда привязан к одному конкретному узлу. узел."

Есть несколько причин, которые могут вызвать эту ошибку:

1. Узел не помечен должным образом. У меня была эта проблема на AWS, когда у моего рабочего узла не было соответствующих меток (хотя они были у мастера), например:

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

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

   После исправления узла с помощью меток ошибка «1 узел (а) имел конфликт сродства узла тома» исчезла, поэтому PV, PVC с модулем были успешно развернуты. Значение этих меток зависит от поставщика облачных услуг. По сути, это задача поставщика облака (с параметром —cloud-provider, определенным в cube-controller, API-server, kubelet), чтобы установить эти метки. Если соответствующие ярлыки не установлены, проверьте правильность интеграции с CloudProvider. Я использовал kubeadm, поэтому его громоздко настраивать, но с другими инструментами, например, kops, он сразу работает.

2. Основываясь на вашем определении PV и использовании поля nodeAffinity, вы пытаетесь использовать локальный том (читайте здесь ссылка на описание локального тома, официальные документы), затем убедитесь, что вы установили «поле NodeAffinity» таким образом (в моем случае это работало на AWS):

   nodeAffinity:

        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. Определение StorageClass (с именем local-storage, которое здесь не публикуется) должно быть создано с параметром volumeBindingMode, установленным в WaitForFirstConsumer, чтобы локальное хранилище работало правильно. Обратитесь к примеру здесь локальное описание класса хранения, официальный документ, чтобы понять причину этого.

Ошибка «конфликт сродства узла тома» возникает, когда постоянный том утверждает, что модуль использует запланированные в разных зонах, а не в одной зоне, и поэтому фактический модуль не удалось запланировать, потому что он не может подключиться к тому из другая зона. Чтобы проверить это, вы можете просмотреть подробную информацию обо всех постоянных томах. Чтобы проверить это, сначала получите ваши PVC:

$ kubectl get pvc -n <namespace>

Затем получите подробную информацию о постоянных объемах (не о заявках на объем).

$  kubectl get pv

Найдите PV, которые соответствуют вашим PVC, и опишите их

$  kubectl describe pv <pv1> <pv2>

Вы можете проверить Source.VolumeID для каждого PV, скорее всего, это будут разные зоны доступности, поэтому ваш модуль выдает ошибку сродства. Чтобы исправить это, создайте класс хранения для одной зоны и используйте этот класс хранения в своем 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

Ошибка "1 узел (а) имел конфликт сходства узлов тома" создается планировщиком, потому что он не может запланировать для вашего модуля узел, который соответствует полю persistenvolume.spec.nodeAffinity в вашем PersistentVolume (PV).

Другими словами, вы говорите в своем PV, что модуль, использующий этот PV, должен быть запланирован для узла с меткой kubernetes.io/cvl-gtv-42.corp.globaltelemetrics.eu = master, но по какой-то причине это невозможно.

Могут быть разные причины, по которым ваш модуль не может быть назначен на такой узел:

• У пода есть сходства узлов, сродства подов и т. д., Которые конфликтуют с целевым узлом.
• Целевой узел испорчен
• Целевой узел достиг предельного количества пакетов на узел.
• Нет узла с данной меткой

Место для начала поиска причины - это определение узла и модуля.

В моем случае основная причина заключалась в том, что постоянный том находится в us-west-2c, а новые рабочие узлы перезапускаются в us-west-2a и us-west-2b. Решение состоит в том, чтобы либо иметь больше рабочих узлов, чтобы они находились в большем количестве зон, либо удалить / расширить привязку узлов для приложения, чтобы большее количество рабочих узлов соответствовало требованиям для привязки к постоянному тому.

Другой случай от GCP GKE. Предположим, вы используете региональный кластер и создали два PVC. Оба были созданы в разных зонах (вы не заметили).

На следующем шаге вы пытаетесь запустить модуль, в котором оба 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 не сможет запланировать pod, потому что тома находятся в разных зонах.

Отличный ответ Сонака Роя. У меня был такой же случай, когда PV создавался в другой зоне по сравнению с узлом, который должен был его использовать. Решение, которое я применил, было основано на ответе Сонака, только в моем случае было достаточно указать класс хранилища без списка «allowedTopologies», например:

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

Скорее всего, вы просто сократили количество узлов в кластере кубернетов, и некоторые «регионы» больше не доступны ...

Кое-что стоит упомянуть ... если ваш под будет находиться в зоне, отличной от зоны постоянного тома, тогда:

• время доступа к вашему диску значительно снизится (ваше локальное постоянное хранилище больше не является локальным - даже с гипербыстрыми оптоволоконными соединениями Amazon / Google он все еще проходит через центры обработки данных)
• вы будете платить за «межрегиональную сеть» (в вашем счете AWS это что-то, что входит в «EC2-other», и только после детализации счета Aws вы можете это заметить)