Должен ли я явно создавать постоянный том, когда я использую утверждение постоянного тома?

Я новичок в Kubernetes, и мне сложно понять всю идею Persistent Storage в Kubernetes.

Этого достаточно, или мне нужно создать постоянный том и что произойдет, если я разверну только эти два объекта без создания PV?

Хранилище должно быть на локальной машине.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  creationTimestamp: null
  name: nginx-logs
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Mi
status: {}

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: app-web
  name: app-web
spec:
  selector:
    matchLabels:
      app: app-web
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: app-web
    spec:
      containers:
        image: nginx:1.14.2
        imagePullPolicy: Always
        name: app-web
        volumeMounts:
        - mountPath: /var/log/nginx
          name: nginx-logs
      restartPolicy: Always
      volumes:
      - name: nginx-logs
        persistentVolumeClaim:
          claimName: nginx-logs

kubernetes persistent-volumes persistent-volume-claims
person Most31    schedule 06.10.2020    source источник

Ответы (3)


arrow_upward
2
arrow_downward

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

Когда ни один из статических PV, созданных администратором, не соответствует PersistentVolumeClaim пользователя, кластер может попытаться динамически подготовить том специально для PVC. Это обеспечение основано на StorageClasses: PVC должен запрашивать класс хранилища, и администратор должен создать и настроить этот класс для динамического предоставления. Утверждения, которые запрашивают класс, фактически отключают динамическую подготовку для себя.

Когда я применяю ваш ПВХ, он создает том gp2, потому что это мой класс хранения по умолчанию.

$kubectl get pvc
NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nginx-logs   Bound    pvc-b95a9d0c-ef46-4ff0-a034-d2dde1ac1f96   1Gi        RWO            gp2            6s

Вы можете увидеть свой класс хранилища по умолчанию следующим образом

$kubectl get storageclass
NAME            PROVISIONER                                           AGE
gp2 (default)   kubernetes.io/aws-ebs                                 355d

Вы также можете указать определенный класс хранилища. Подробнее об этом можно узнать здесь.

Пользователи запрашивают динамически выделенное хранилище, включая класс хранилища в свой PersistentVolumeClaim.

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

person Howard_Roark    schedule 06.10.2020
comment
Ах, понятно, это действительно хорошее объяснение! И мой класс StorageClass по умолчанию - это локальный путь, чего я хочу достичь. - person Most31; 06.10.2020

arrow_upward
3
arrow_downward

Я изо всех сил пытаюсь понять всю идею Persistent Storage в Kubernetes.

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

Этого достаточно, или мне нужно создать постоянный том и что произойдет, если я разверну только эти два объекта без создания PV?

Это зависит от вашего окружения. В большинстве сред обычно есть динамическое выделение томов, например Крупные облачные провайдеры, а теперь и Minikube поддерживают это.

При использовании динамического выделения тома разработчик должен создать только PersistentVolumeClaim - и не PersistentVolume, вместо этого он будет динамически проверен.

person Jonas    schedule 06.10.2020
comment
Большое спасибо, это было действительно полезно! И похоже, что в моей среде есть Dynamic Volume Provisioning, потому что я не получал никаких ошибок, поскольку @Argha сказал, что это должно произойти. Я использую дистрибутив Kubernetes K3s. Но считаете ли вы это хорошей практикой или все равно будете явно создавать PV? - person Most31; 06.10.2020
comment
да, я всегда стараюсь использовать Dynamic Volume Provisioning, если это соответствует вашим потребностям. - person Jonas; 06.10.2020

arrow_upward
3
arrow_downward

Требуется PV, который соответствует PVC с точки зрения capacity(100Mi) и accessModes(ReadWriteOnce). Если у вас нет PV, вы получите ошибку pod has unbound immediate PersistentVolumeClaims. Таким образом, вы либо создаете PV вручную (это называется статической подготовкой), либо полагаетесь на класс хранилища и драйвер тома, чтобы сделать это автоматически (это называется динамической подготовкой).

PV - это кубернетское представление объема. Фактический том все еще необходимо подготовить. Если вы используете динамическое предоставление тома и у вашего облачного провайдера есть драйвер тома, инициализация автоматически выполняется драйвером без необходимости создавать PV вручную.

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

person Arghya Sadhu    schedule 06.10.2020
comment
хм, после всех этих ответов кажется, что мой дистрибутив кубернетов - k3s имеет класс хранилища по умолчанию, и это локальный путь, поэтому это сработало для меня без создания PV или StorageClass - person Most31; 06.10.2020
comment
Да, у владельца ранчо есть github.com/rancher/local-path-provisioner - person Arghya Sadhu; 06.10.2020