Kubernetes игнорирует PV C RWO ACCESS MODE и развертывает поды на разных узлах - PullRequest
Новая
       70

Kubernetes игнорирует PV C RWO ACCESS MODE и развертывает поды на разных узлах

3 голосов
/ 06 мая 2020

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

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

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

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

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

Ответы [ 3 ]

4 голосов
/ 14 мая 2020

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

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

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

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

1 голос
/ 11 мая 2020

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

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

0 голосов
/ 14 мая 2020
• 1000 * Теперь, как провайдер хранения узнает, на каком узле или в какой зоне доступности ему нужно создать постоянный том? Вот почему заявки на постоянные тома имеют режим привязки томов, который в этом случае установлен на 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
...