У Kubernetes проблемы с StatefulSet и 3 постоянными томами

Question

Я нахожусь в процессе создания StatefulSet на основе этого yaml , который будет иметь 3 реплики. Я хочу, чтобы каждый из трех модулей был подключен к отдельному постоянному объему.

Для постоянного тома я использую 3 объекта, которые выглядят следующим образом, только с измененным именем (pvvolume, pvvolume2, pvvolume3) :

kind: PersistentVolume
apiVersion: v1
metadata:
  name: pvvolume
  labels:
    type: local
spec:
  storageClassName: standard
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/nfs"
  claimRef:
    kind: PersistentVolumeClaim
    namespace: default
    name: mongo-persistent-storage-mongo-0

Первый из 3 модулей в StatefulSet, похоже, создан без проблем.

Второй сбой с ошибкой pod has unbound PersistentVolumeClaims Back-off restarting failed container.

Тем не менее, если я перейду к вкладке, в которой отображается PersistentVolumeClaims, второй созданный файл будет успешным.

Если он был успешным, почему модуль думает, что он потерпел неудачу?

Answer 1

Я хочу, чтобы каждый из 3-х модулей подключался к другому PersistentVolume.

• Для правильной работы вам потребуется:

  • инициатора (в размещенной вами ссылке приведен пример настройки поставщика на aws, azure, googlecloud и minicube) или
  • том, который можно монтировать несколько раз (например, том NFS). Однако обратите внимание, что в таком случае все ваши модули читают / пишут в одну и ту же папку, и это может привести к проблемам, когда они не предназначены для одновременной блокировки / записи в одни и те же данные. Обычный вариант использования для этого - папка загрузки, в которую сохраняются модули, которая позже используется только для чтения, и такие варианты использования. С другой стороны, базы данных SQL (такие как mysql) не предназначены для записи в такую ​​общую папку.

• Вместо одного из упомянутых требований в манифесте заявки вы используете hostPath (указывающий на / nfs) и задаете для него значение ReadWriteOnce (его может использовать только одно). Вы также используете «стандартный» в качестве класса хранения, и в URL, который вы указали, есть быстрый и медленный, поэтому вы, вероятно, также создали свой класс хранения.

Второй сбой с ошибкой модуль имеет несвязанные PersistentVolumeClaims Откат перезапуска не удался, контейнер

• Это связано с тем, что первый модуль уже принял свое требование (один раз прочитать запись, путь к хосту), а второй модуль не может повторно использовать тот же, если не настроен соответствующий поставщик или доступ.

Если это было успешно, почему модуль думает, что это не удалось?

• Все ПВХ были успешно привязаны к сопровождающему ПВ. Но вы никогда не привязываете второй и третий PVC ко вторым или третьим капсулам. Вы повторяете попытку с первым утверждением на втором модуле, и первое утверждение уже привязано (к первому модулю) в режиме ReadWriteOnce, а также не может быть связано с вторым модулем, и вы получаете ошибку ...

Предлагаемый подход

Поскольку вы ссылаетесь на / nfs как путь к хосту, можно с уверенностью предположить, что вы используете какую-то файловую систему с NFS-поддержкой, поэтому вот одна из альтернативных настроек, которая позволяет вам монтировать динамически подготовленные постоянные тома поверх nfs для столько стручков в наборе состояний, сколько вы хотите

Примечания:

• Это только отвечает на первоначальный вопрос о монтировании постоянных томов на реплицированные модули с сохранением состояния с предположением совместного использования nfs.
• NFS не рекомендуется для динамических данных, таких как база данных. Обычный вариант использования - папка для загрузки или умеренная папка для ведения журнала / резервного копирования. База данных (sql или no sql), как правило, запрещена для nfs.
• Для критически важных приложений / приложений, требующих времени, вам может потребоваться время / стресс-тестирование, прежде чем применять этот подход в производстве, так как и k8s, и внешний pv добавляют промежуточные уровни задержки / задержки. Хотя для некоторых приложений этого может быть достаточно, будьте осторожны.
• Вы имеете ограниченный контроль над именем для pv, который создается динамически (k8s добавляет суффикс к вновь созданному и повторно использует доступные старые, если это будет сказано), но k8s сохранит их после завершения работы pod и назначит первый доступный для новый модуль, так что вы не потеряете состояние / данные. Это то, что вы можете контролировать с помощью политик.

Шаги:

• , чтобы это работало, вам сначала нужно установить nfs Provider отсюда:

  • https://github.com/kubernetes-incubator/external-storage/tree/master/nfs. Имейте в виду, что установка не сложна, но имеет несколько шагов, где вы должны тщательно подходить (разрешения, настройка общих ресурсов nfs и т. Д.), Чтобы это было не просто развертывание по принципу «забей и забудь». Не торопитесь с правильной установкой NFS провайдера. После правильной настройки вы можете продолжить с предложенными ниже манифестами:

• Манифест класса хранения:

  kind: StorageClass
  apiVersion: storage.k8s.io/v1beta1
  metadata:
    name: sc-nfs-persistent-volume
  # if you changed this during provisioner installation, update also here
  provisioner: example.com/nfs 
  

• Набор с сохранением состояния (только важная выдержка):

  apiVersion: apps/v1
  kind: StatefulSet
  metadata:
    name: ss-my-app
  spec:
    replicas: 3
    ...
    selector:
      matchLabels:
        app: my-app
        tier: my-mongo-db
    ...
    template:
      metadata:
        labels:
          app: my-app
          tier: my-mongo-db
      spec:
        ...
        containers:
          - image: ...
            ...
            volumeMounts:
              - name: persistent-storage-mount
                mountPath: /wherever/on/container/you/want/it/mounted
        ...
    ...
    volumeClaimTemplates:
    - metadata:
        name: persistent-storage-mount
    spec:
      storageClassName: sc-nfs-persistent-volume
      accessModes: [ ReadWriteOnce ]
      resources:
        requests:
          storage: 10Gi
    ...