Привязка набора с сохранением состояния к локальным постоянным томам - ошибка конфликта сходства узла тома

У меня кубернеты с 3 узлами, имена хостов - host_1, host_2, host_3.

$ kubectl get nodes
NAME       STATUS    ROLES     AGE       VERSION
host_1     Ready     master    134d      v1.10.1
host_2     Ready     <none>    134d      v1.10.1
host_3     Ready     <none>    134d      v1.10.1

Я определил 3 локальных постоянных тома размером 100 МБ, сопоставленных с локальным каталогом на каждом узле. Я использовал следующий дескриптор 3 раза, где <hostname> - одно из: host_1, host_2, host_3:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: test-volume-<hostname>
spec:
  capacity:
    storage: 100M
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: /opt/jnetx/volumes/test-volume
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - <hostname>

После применения трех таких ямлов у меня получается следующее:

$ kubectl get pv
NAME                 CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM    STORAGECLASS    REASON    AGE
test-volume-host_1   100M       RWO            Delete           Available            local-storage             58m
test-volume-host_2   100M       RWO            Delete           Available            local-storage             58m
test-volume-host_3   100M       RWO            Delete           Available            local-storage             58m

Теперь у меня есть очень простой контейнер, который записывает в файл. Файл должен находиться на локальном постоянном томе. Я развертываю его как набор состояний с 1 репликой и сопоставлением томов через volumeClaimTemplates набора состояний:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: filewriter
spec:
  serviceName: filewriter
  ...
  replicas: 1
  template:
    spec:
      containers:
        - name: filewriter
          ...
          volumeMounts:
          - mountPath: /test/data
            name: fw-pv-claim
  volumeClaimTemplates:
  - metadata:
      name: fw-pv-claim
    spec:
      accessModes:
      - ReadWriteOnce
      storageClassName: local-storage
      resources:
        requests:
          storage: 100M

Заявление о томе, похоже, было создано нормально и привязано к pv на первом хосте:

$ kubectl get pv
NAME                 CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                              STORAGECLASS    REASON    AGE
test-volume-host_1   100M       RWO            Delete           Bound       default/fw-pv-claim-filewriter-0   local-storage             1m
test-volume-host_2   100M       RWO            Delete           Available                                      local-storage             1h
test-volume-host_3   100M       RWO            Delete           Available                                      local-storage             1h

Но модуль зависает в состоянии ожидания:

$ kubectl get pods
NAME                         READY     STATUS    RESTARTS   AGE
filewriter-0                 0/1       Pending   0          4s

Если описать, то увидим следующие ошибки:

$ kubectl describe pod filewriter-0
Name:           filewriter-0
...
Events:
  Type     Reason            Age              From               Message
  ----     ------            ----             ----               -------
  Warning  FailedScheduling  2s (x8 over 1m)  default-scheduler  0/3 nodes are available: 1 node(s) had taints that the pod didn't tolerate, 2 node(s) had volume node affinity conflict.

Можете ли вы помочь мне понять, что не так? Почему он не может просто создать контейнер?


kubernetes persistent-volumes
person Gena L    schedule 06.09.2018    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Кажется, что один узел, на котором доступен PV, имеет изъян, к которому ваш StatefulSet не допускает.

person Radek 'Goblin' Pieczonka    schedule 06.09.2018
comment
Да, оказалось, что первый узел (мастер) запрещал запускать на нем пользовательские контейнеры, но первый PVC был привязан к этому первому узлу. То, что вы сказали, было очевидно из сообщения об ошибке, но ваш ответ заставил меня просто прочитать о kubernetes taints :))) - person Gena L; 07.09.2018
comment
@GenaL, расскажите, пожалуйста, в чем была проблема? Здесь я тоже сталкиваюсь с аналогичной проблемой. - person Abhijit; 29.10.2018
comment
Как я упоминал выше, в моем случае проблема заключалась в том, что настраиваемые модули не могли быть запланированы для главного узла. Это вариант установки k8s по умолчанию. Вы можете проверить через kubectl describe node ‹master node›. Здесь описано, как это изменить: stackoverflow.com/questions/43147941/ - person Gena L; 31.10.2018

arrow_upward
0
arrow_downward

У меня был случай, очень похожий на описанный выше, и я наблюдал тот же симптом (конфликт сродства узлов). В моем случае проблема заключалась в том, что у меня было 2 тома, подключенных к 2 разным узлам, но я пытался использовать их в пределах 1 модуля.

Я обнаружил это, используя kubectl describe pvc name-of-pvc и отметив аннотацию selected-node. Как только я настроил модуль на использование томов, которые находились на одном узле, у меня больше не было проблем.

person Alex Moore-Niemi    schedule 10.11.2020