Kubernetes игнорирует РЕЖИМ ДОСТУПА PVC RWO и развертывает поды на разных узлах

У меня есть кластер Kubernetes v1.17.0 с несколькими узлами. Я создал PVC с режимом доступа RWO. Из документации Kubernetes:

ReadWriteOnce - том может быть смонтирован как чтение-запись одним узлом

Я использую плагин Cinder volume, который не поддерживает ReadWriteMany.

Когда я создаю два разных развертывания, которые монтируют один и тот же PVC, Kubernetes иногда развертывает их на двух разных узлах, что приводит к сбою подов.

Это желаемое поведение или проблема в моей конфигурации?


kubernetes kubernetes-deployment kubernetes-pvc
person Lukas    schedule 06.05.2020    source источник
comment
какая ошибка возникает при развертывании модуля?   -  person Arghya Sadhu    schedule 06.05.2020
comment
Ошибка множественного присоединения для тома [имя тома pv] Том уже используется модулями [список модулей]   -  person Lukas    schedule 07.05.2020
comment
Рассматривали ли вы возможность использования nodeAffinity для развертывания модулей? только в нужном узле, который умеет монтировать том?   -  person Mr.KoopaKiller    schedule 08.05.2020
comment
В настоящее время я использую правила сходства, иначе оба развертывания завершатся ошибкой. Я бы предпочел, чтобы Kubernetes решил, какой узел лучше всего подходит для обоих развертываний.   -  person Lukas    schedule 11.05.2020
comment
@Lukas, Если я понял, вы уже используете правила Affinity, но вы хотите удалить правило affinity и оставить Kubernetes решать, где запускать поды?   -  person Mr.KoopaKiller    schedule 13.05.2020
comment
@KoopaKiller Да. Поскольку я создал ReadWriteOnce, Kubernetes уже знает, что развертывания, монтирующие том, не могут выполняться на разных узлах. Зачем нужно указывать правила привязки?   -  person Lukas    schedule 13.05.2020

Ответы (3)


arrow_upward
4
arrow_downward

Как я понял из ваших ответов на комментарии, вы не хотите использовать правила привязки, но хотите, чтобы планировщик выполнял эту работу за вас.

Кажется, что эта проблема известна по крайней мере с 2016 года, но еще не решена, поскольку расписание считается работающим должным образом: https://github.com/kubernetes/kubernetes/issues/26567

Вы можете прочитать подробности в выпуске, но основная проблема, похоже, заключается в том, что в определении Kubernetes том ReadWriteOnce никогда не может быть доступен двум модулям одновременно. По определению. Что нужно будет реализовать, так это флаг, говорящий «нормально, если к этому тому RWO могут обращаться одновременно два модуля, даже если это RWO». Но этот функционал пока не реализован.

На практике эту проблему обычно можно обойти, используя Повторное развертывание. Стратегия: .spec.strategy.type: Recreate. В качестве альтернативы используйте правила сродства, как описано в других ответах.

person Simon    schedule 14.05.2020

arrow_upward
1
arrow_downward

Предоставление PV / PVC и развертывание новых модулей на одном узле можно выполнить только с помощью привязка узла. Однако, если вы хотите, чтобы Kubernetes решал это за вас, вам придется использовать сходство между пакетами.

Однако, чтобы убедиться, что вы все делаете правильно, обратитесь к это.

person redzack    schedule 11.05.2020

arrow_upward
0
arrow_downward

Постоянные тома в Kubernetes могут быть привязаны к узлу или зоне доступности из-за базового оборудования: диск хранения на сервере, SAN в одном центре обработки данных не могут быть перемещены поставщиком хранилища.

Теперь, как поставщик хранилища узнает, на каком узле или в какой зоне доступности ему нужно создать постоянный том? Вот почему заявки на постоянные тома имеют режим привязки тома, который в этом случае установлен на WaitForFirstConsumer. Это означает, что подготовка происходит после того, как был запланирован первый модуль, который монтирует постоянный том. Дополнительные сведения см. здесь.

Когда запланирован второй модуль, он может работать на другом узле или в другой зоне доступности, если вы не укажете планировщику запускать модуль на том же узле или в той же зоне доступности, что и первый модуль, используя сходство между модулями:

    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          # adjust the labels so that they identify your pod
          matchExpressions:
          - key: app.kubernetes.io/name
            operator: In
            values:
            - myapp
        # make pod run on the same node
        topologyKey: kubernetes.io/hostname
person Hendrik M Halkow    schedule 14.05.2020