Блог

Главная - Вопросы по программированию - Какая польза от использования идентификатора ТОМА при создании PV?

Какая польза от использования идентификатора ТОМА при создании PV?

#amazon-web-services #kubernetes #amazon-eks #persistent-volumes

#amazon-web-services #kubernetes #amazon-eks #постоянные тома

Вопрос:

Наблюдал два вида синтаксиса для создания PV и PVC в AWS EKS.

1) Использование идентификатора тома при создании как PV, так и PVC (создайте том вручную, используя этот идентификатор) 2) Без использования идентификатора тома (динамическое предоставление PV)

пример-1:

 - apiVersion: "v1"
  kind: "PersistentVolume"
  metadata:
    name: "pv-aws"
  spec:
    capacity:
      storage: 10G
    accessModes:
      - ReadWriteMany
    persistentVolumeReclaimPolicy: Retain
    storageClassName: gp2
    awsElasticBlockStore:
      volumeID: vol-xxxxxxxx
      fsType: ext4

В этом случае я создаю том вручную и использую его для создания PV и PVC

пример-2:

 apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: gp2
  resources:
    requests:
      storage: 20Gi

В этом случае, просто создав PVC, вы создаете том в серверной части (AWS) и PV.

В чем разница и в том, что использовать в каких сценариях? Плюсы и минусы?

Ответ №1:

Это должно основываться на ваших требованиях. Статическое предоставление, как правило, не масштабируется. Вы должны создавать тома вне контекста k8s. Монтирование существующих томов было бы полезно в сценариях аварийного восстановления.

Использование классов хранения или динамической подготовки, как правило, предпочтительнее из-за удобства. Вы можете создавать роли и квоты ресурсов, чтобы контролировать и ограничивать использование хранилища и снижать операционные издержки.

Комментарии:

1. Что подходит для наборов состояний? например, я использую sts для репликации mongodb (3 модуля, первичный (vol1), вторичный (vol2) и второй вторичный (vol3)) в этом случае я хочу подключить один и тот же том к соответствующему модулю независимо от жизненного цикла для обеспечения согласованности данных.

2. Это не должно иметь значения для StatefulSets, если вы не удаляете утверждения и не создаете их заново. При каждом повторном создании создавался бы новый диск. Это то, что я имел в виду под сценарием аварийного восстановления. В этом случае вы можете создать резервную копию своих конфигураций и восстановить их с помощью sth, такого как Velero.