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

У меня есть 3-х узловые kubernetes, имена хостов 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 локальных постоянных тома размером 100M, сопоставленных с локальным каталогом на каждом узле. Я использовал следующий дескриптор 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 для Statefulset:

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.

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

Источник

1 ответ

Решение

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

Источник

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

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

Источник
Другие вопросы по тегам