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

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

0 голосов
/ 06 сентября 2018

У меня есть 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 репликой и сопоставление томов с помощью тома Statefulset 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.

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

1 Ответ

0 голосов
/ 06 сентября 2018

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

...