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

Question

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

Для постоянного тома я использую 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 (его может использовать только одно). Вы также используете 'standard' в качестве класса хранения, и в URL, который вы указали, есть быстрый и медленный, поэтому вы, вероятно, также создали свой класс хранения.

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

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

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

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

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

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

Заметки:

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

шаги:

• чтобы это работало, сначала нужно установить 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
    ...