Могу ли я использовать существующий постоянный диск GCE в volumeClaimTemplate из Kubernetes Statefulset

Я использую Google Container Engine для запуска StatefulSet для набора реплик MongoDB (3 модуля реплик).

Это отлично работает с динамическим предоставлением постоянного хранилища - то есть новое хранилище предоставляется для каждого модуля при создании набора с отслеживанием состояния.

Но если я перезапущу StatefulSet, мне кажется, что я не смогу повторно привязать старые постоянные тома, потому что новое хранилище будет предоставлено снова. Это означает, что данные потеряны. В идеале постоянное хранилище должно пережить удаление самого кластера Kubernetes, с сохранением данных и готовностью к повторному использованию в новом кластере.

Есть ли способ создать постоянные диски GCE и использовать их в заявке на постоянный том StatefulSet?

[Обновлено 20 сентября 2017 г.]

Нашел ответ: это решение (кредит @RahulKrishnan R A)

  1. создать класс хранилища, указав базовый тип диска и зону

  2. Создайте PersistentVolume, который указывает созданный выше класс хранилища, и укажите постоянный диск, который вы хотите смонтировать.

  3. Создайте PersistentVolumeClaim. Важно назвать PVC <pvc template name>-<statefulset name>-<ordinal number>. (Уловка правильное имя!) Укажите volumeName как PV, созданный выше, и класс хранилища.
  4. Создайте столько PV и PVC, сколько у вас есть реплик с правильным именем.
  5. Создайте statefulSet с шаблоном PVC.

kubernetes mongodb persistent-volume-claims statefulset
person conundrum    schedule 04.09.2017    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Метод 1: динамический

Вы можете добавить шаблон требования о том, как показано ниже, в файле statefulset.yaml вместе с определением развертывания

volumeClaimTemplates:
- метаданные:
имя: хранилище
аннотации:
volume.beta.kubernetes.io/storage-class: slow
spec:
accessModes : [ReadWriteOnce]
ресурсы:
запросы:
хранилище: 10 Ги

Создайте файл класса хранилища storage.yaml

вид: StorageClass
apiVersion: storage.k8s.io/v1beta1
метаданные:
имя: медленный
поставщик: kubernetes.io/gce-pd
параметры:
Тип: pd-standard
зона: asia-east1-a

Метод 2: статическая PV:

https://github.com/rahulkrishnanfs/percona-xtradb-statefulset-cluster-k8s/blob/master/percona.yml.

Примечание. persistentVolumeReclaimPolicy: Retain используйте, если вы хотите сохранить объем

Постоянные тома могут быть предоставлены администратором статически или динамически на основе ресурса StorageClass.

person RahulKrishnan R A    schedule 17.09.2017
comment
Как это обеспечить с существующего постоянного диска без указания имени диска? Похоже, он по-прежнему будет выполнять динамическую подготовку? - person conundrum; 18.09.2017
comment
Вы хотите прикрепить PV вручную? Это для динамической подготовки для приложения с отслеживанием состояния. Для ручной подготовки см. github.com/rahulkrishnanfs/ - person RahulKrishnan R A; 19.09.2017
comment
Я перешел по ссылке на Github для percona.yaml. Это было похоже на простую динамическую инициализацию в PVC. Не могли бы вы объяснить, как этот PVC ссылается на существующий диск PD и использует его? - person conundrum; 19.09.2017
comment
Требование постоянного тома должно называться ‹имя шаблона pvc› - ‹имя набора состояний› - ‹порядковый номер› В примере Percona используется статический метод, потому что мы создали диск вручную, но в случае динамического диска он будет создан динамически с помощью storageclass объект - person RahulKrishnan R A; 20.09.2017
comment
базовые постоянные тома затем могут быть восстановлены и переработаны для использования в будущем. - person RahulKrishnan R A; 20.09.2017
comment
@conundrum приятно слышать и ценить вашу преданность делу. Мы упомянули как статическое, так и динамическое обеспечение для других в качестве справочного материала. Я думаю, мы можем оставить и то, и другое в этом посте - person RahulKrishnan R A; 21.09.2017

arrow_upward
0
arrow_downward

Похоже, что использование нового кубернетеса (1.12) поддерживает существующие тома, что может быть удобно, если у вас уже есть диски с данными. Например, у моего приложения нет высокой нагрузки на базу данных, и я доволен запуском реплик с 3 экземплярами (PSA). Для каждого из них я создал набор состояний с одной репликой и использовал существующий gcePersistentDisk для ПЕРВИЧНОГО и ВТОРИЧНОГО. Ниже представлена ​​конфигурация второго узла:

apiVersion: v1
kind: Service
metadata:
  name: mongo-svc-b
spec:
  ports:
    - port: 27017
      targetPort: 27017
  clusterIP: None
  selector:
    app: si
    tier: db
    node: b
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mongo-b
spec:
  replicas: 1
  selector:
    matchLabels:
      app: si
      tier: db
      node: b
  serviceName: mongo-b
  template:
    metadata:
      labels:
        app: si
        tier: db
        node: b
    spec:
      containers:
        - name: mongo
          image: mongo:3.2
          command: ["mongod"]
          args: ["-replSet", "si"]
          ports:
            - containerPort: 27017
            - containerPort: 28017
          volumeMounts:
            - name: mongo-persistent-storage
              mountPath: /data/db
      volumes:
        - name: mongo-persistent-storage
          gcePersistentDisk:
            pdName: mongo-disk-b-green
            fsType: ext4
person dimka    schedule 20.05.2019