Поиск по сайту:

Как добавить постоянное хранилище в модули Kubernetes


Файловые системы Kubernetes Pod по умолчанию эфемерны. Это соответствует природе контейнеров без сохранения состояния. Постоянные данные должны храниться вне контейнера, даже если кажется, что они находятся в файловой системе контейнера. Вот как выделить постоянное хранилище в Kubernetes.

Базовой единицей постоянного хранилища Kubernetes является постоянный том. Это абстракция над более фундаментальным Томом.

Постоянные тома существуют независимо от какого-либо конкретного модуля. Как и обычные тома Docker, постоянные тома Kubernetes могут оставаться в вашем кластере, даже если их не используют модули.

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

Основной пример

Давайте посмотрим, как создать постоянную систему хранения путем ручной настройки Persistent Volume и Persistent Volume Claim. Каждый ресурс войдет в свой собственный файл манифеста. Вы можете применить эти файлы к своему кластеру с помощью kubectl apply.

Создать постоянный том

Начните с создания тома:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-volume
  namespace: pvc-demo
spec:
  storageClassName: manual
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /mnt/data

Это определение создает том с именем my-volume. Он имеет емкость 2Gi и будет храниться в /mnt/data на хост-узле. Поскольку мы создаем этот том вручную, для storageClassName установлено значение manual. Классы хранилища можно использовать для того, чтобы тома были привязаны только к утверждениям тома, запрашивающим тот же класс.

Создать постоянную заявку на объем

Теперь вы можете настроить постоянную претензию тома:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-volume-claim
  namespace: pvc-demo
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Претензия запрашивает 1 ГБ хранилища для тома с помощью класса manual. Том, который мы создали ранее, может выполнить эти условия. Когда заявка создана, Kubernetes должен понять это и привязать заявку к тому.

Если бы вы проверили детали тома и претензии, вы бы увидели, что они оба имеют статус Bound.

kubectl get pv my-volume
kubectl get pvc my-volume-claim

Добавить модуль

Последним этапом является использование заявки на объем для добавления постоянного хранилища в под.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace: pvc-demo
spec:
  containers:
    - name: my-container
      image: my-image:latest
      volumeMounts:
        - mountPath: /path/in/container
          name: my-pod-volume
  volumes:
    - name: my-pod-volume
      persistentVolumeClaim:
        claimName: my-volume-claim

В разделе volumes настраивается ссылка на Persistent Volume Claim. Никакой другой информации о томе указывать не нужно. Pod будет использовать требование, которое предоставит том, к которому он привязан.

Утверждение упоминается в volumeMounts. Убедитесь, что вы используете одно и то же имя в volumes и volumeMounts. Том будет подключен к вашему поду в месте, указанном в mountPath.

Теперь у вашего модуля есть доступное постоянное хранилище. Все, что будет записано в /path/in/container, будет сохранено на постоянном томе. Утверждение Persistent Volume Claim будет повторно использоваться новыми модулями, которые на него ссылаются, что позволит данным пережить любой отдельный модуль.

Классы хранения

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

Управляемые сервисы Kubernetes обычно предоставляют свои собственные классы хранения, которые соответствуют реализации блочного хранилища платформы. Примеры включают gcePersistentDisk с Google Kubernetes Engine или do-block-storage с DigitalOcean Managed Kubernetes.

В этих сценариях вам не нужно создавать манифест PersistentVolume вручную. Создайте PersistentVolumeClaim с правильным storageClassName и используйте поле resources.requests.storage (показано выше), чтобы указать желаемую емкость. Драйвер хранилища автоматически привяжет заявку к совместимому экземпляру тома.

Режимы доступа

Существует три поддерживаемых значения для поля accessModes:

  • ReadWriteOnce — том можно подключить только к одному узлу Kubernetes. Этот узел будет иметь полный доступ для чтения и записи к тому.
  • ReadOnlyMany — том может использоваться несколькими узлами одновременно. Каждый узел имеет доступ только для чтения (ничего не может записывать в том).
  • ReadWriteMany — том можно подключить к нескольким узлам одновременно. Каждый узел может читать и записывать том.

Только один режим доступа может использоваться данным томом в любое время. Это означает, что две заявки на том будут привязаны к одному и тому же тому только в том случае, если обе заявки объявляют один и тот же режим доступа.

Режим доступа к вашим томам влияет на способность планировщика Kubernetes распределять реплики ваших подов на нескольких узлах. Режимы ReadOnlyMany/ReadWriteMany необходимо использовать, если вам нужно, чтобы поды совместно использовали постоянное хранилище и реплицировались на несколько узлов.

Имейте в виду, что не все драйверы хранилища поддерживают все режимы доступа — вам следует проконсультироваться с поставщиком вашего плагина. Неполный список объемных плагинов и совместимых режимов доступа приведен в документации Kubernetes.

Заключение

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

При использовании постоянных томов Kubernetes создаст постоянные тома, которые переживут отдельные поды. Когда ваши модули будут заменены, заявленные тома будут автоматически смонтированы в новые модули. Данные не будут уничтожены, пока претензия не будет удалена.




Все права защищены. © Linux-Console.net • 2019-2024