Как добавить постоянное хранилище в модули 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 создаст постоянные тома, которые переживут отдельные поды. Когда ваши модули будут заменены, заявленные тома будут автоматически смонтированы в новые модули. Данные не будут уничтожены, пока претензия не будет удалена.