GCE Kubernetes: требование постоянного диска и постоянного тома - PullRequest
Новая
       41

GCE Kubernetes: требование постоянного диска и постоянного тома

0 голосов
/ 15 января 2019

Подход 1 (том kubernetes подключен к постоянному диску Google, том kubernetes заявлен на том kubernetes) 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: volume-1
spec:
  storageClassName: ""
  capacity:
    storage: 50Gi
  accessModes:
    - ReadWriteOnce
  gcePersistentDisk:
    pdName: pd-test-1
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pv-claim-1
spec:
  storageClassName: ""
  volumeName: volume-1
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Подход 2 (Заявка на объем Kubernetes напрямую прикреплена к постоянному диску Google) 

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pv-claim-1
spec:
  volumeName: pd-test-1
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Подход 3 (модуль напрямую использует постоянный диск Google docs ) 

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    # This GCE PD must already exist.
    gcePersistentDisk:
      pdName: my-data-disk
      fsType: ext4

Я не уверен, какой метод следует использовать в каких сценариях.
В чем разница между тремя подходами и какой мне следует использовать, если я хочу хранить данные на постоянных дисках Google?

1 Ответ

0 голосов
/ 18 января 2019

В порядке наилучшего подхода:

  • Наилучший: подход 2 - обеспечение динамического объема
  • ОК: Подход 1 - Предварительно подготовленные тома через PersistentVolumeClaim
  • Наихудший: подход 3 - Прямая ссылка на диск через модуль без PersistentVolumeClaim

Подход 3 является худшим, потому что вы теряете мобильность. Если вы переместите ваш модуль в кластер Kubernetes, где GCE PD недоступен, вам придется модифицировать ваш модуль в соответствии с типом хранилища, доступным в новом кластере. Вы не должны использовать этот подход.

При подходах 1 и 2 ваши объекты Pod и PersistentVolumeClaim остаются переносимыми и не содержат в себе специфичных для кластера деталей.

Используйте подход 1 (вручную создавая PersistentVolumeClaim и PersistentVolume), если у вас уже есть существующий диск, который вы хотите использовать с Kubernetes. Сначала вы создаете PersistentVolume объект для представления диска в Kubernetes, затем вы создаете PersistentVolumeClaim для привязки к нему и действует как указатель, который вы можете использовать в вашем модуле Pod. Вы должны быть осторожны, чтобы убедиться, что объекты указывают друг на друга, см. https://stackoverflow.com/a/34323691/5443528 для получения подробной информации о том, как это сделать. Это подход, который вы должны использовать для существующих GCE PD.

Подход 2 (вручную создайте PersistentVolumeClaim и позвольте системе автоматически создать PersistentVolume). Если ваша система хранения поддерживает динамическое предоставление томов Kubernetes, вы просто создаете объект PersistentVolumeClaim, и ваша система хранения автоматически создает новый том. Для Kubernetes в GCE и GKE по умолчанию установлен StorageClass для GCE PD, поэтому это должно работать «из коробки», и именно этот подход вам следует использовать для создания и использования новых GCE PD.

Подробнее об этом см. https://www.youtube.com/watch?v=uSxlgK1bCuA.

...