Блочное хранилище Rook ceph на голом железе - как экспортировать файл из пода?

Я пытаюсь понять, как передать файл из хранилища блоков ceph, например. резервная копия базы данных.

Я следовал примеру здесь: https://github.com/rook/rook/blob/master/Documentation/ceph-block.md, чтобы у меня были Wordpress и mysql, работающие над rook-ceph-block.

Как мне потом передать файл из запущенных модулей. Например, если бы я хотел загрузить резервную копию базы данных на другой хост?


kubernetes ceph rook-storage
person colebod209    schedule 19.12.2020    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Есть несколько подходов, которые могут сработать. Если вы знаете, в каком конкретном контейнере есть файл, тогда всегда можно настроить порт узла, ssh в контейнер с файлом, установить и запустить sshd, а затем использовать scp с целевой машины, используя выделенный вами порт узла.

Другой подход - создать простой HTTP-сервер в новом модуле, который монтирует ту же файловую систему. Это может открыть доступ к файлу с помощью HTTP-команды get. Вы можете сделать это довольно легко с помощью nodejs, express и fs в нескольких строках кода. Это лучше, чем первое решение, потому что вам не нужно знать, в каком контейнере находится файл (что может быть сложно обнаружить).

Однако вы, вероятно, поступаете неправильно. Правильным решением является настройка ладьи для этого за вас с помощью моментального снимка тома.

person Software Engineer    schedule 19.12.2020

arrow_upward
0
arrow_downward

Просто не используйте блочное хранилище.

На данный момент я использую NFS с Ubuntu + Autofs (за пределами Kubernetes) с относительно новым Локальное хранилище Kubernetes. Смотрите внизу. Одно преимущество по сравнению, например, с по умолчанию Longhorn - это RWX вместо RWO.

С sudo mc вы можете легко копировать материал туда и обратно.

Вы также можете легко скопировать вещи из GlusterFS, но в версии 7, которую я тестировал несколько недель назад, она еще не подходит для баз данных или Redis с множеством небольших операций записи.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: <PV_NAME>
spec:
  capacity:
    storage: 20Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: <AUTO_FS_PATH>
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - <VM_NAME>
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: <PVC_NAME>
spec:
  accessModes:
  - ReadWriteMany
  storageClassName: local-storage
  resources:
    requests:
      storage: 20Gi
person qräbnö    schedule 19.12.2020
comment
Возможно, мне что-то не хватает, но разве это не привязывает хранилище базы данных к одному узлу и, следовательно, не обеспечивает высокую доступность? - person colebod209; 20.12.2020
comment
Вы знаете, что означает N в NFS? Он включен на все мои узлы. Тем не менее, вы, конечно, правы, что NFS может быть единственной точкой отказа. Но на то и есть бэкапы. Мой ответ предназначен только для того, чтобы показать удобную альтернативу. - person qräbnö; 20.12.2020
comment
Конечно, я просто проверял, не упустил ли что-то в вашем решении. Так я настраивал раньше, пытался уйти от единой точки отказа - person colebod209; 20.12.2020
comment
Почему бы тебе не написать это в своем вопросе? ;) - person qräbnö; 20.12.2020