Как указано здесь , все эти ресурсы будут объявлены / смонтированы одинаково:
Сохранение данных с томами
При удалении модуля Pod или перезапуске контейнера все и все данные в файловой системе контейнера также удаляются.
Чтобы сохранить данные за пределами модуля, используйте Тома.
Есть 2 дополнения для добавления томов в модули:
- spec.volumes
Этот массив определяет все тома, к которым могут обращаться контейнеры в манифесте Pod. Обратите внимание, что не все контейнеры требуются для монтирования всех томов, определенных в модуле.
- volumeMounts
Этот массив определяет тома, которые монтируются в конкретный контейнер, и путь, по которому должен монтироваться каждый том. Обратите внимание, что два разных контейнера в модуле могут монтировать один и тот же том на разных путях монтирования.
Итак, сначала в spec.volumes мы определяем, какие объемы могут использоваться контейнерами в Pod.
И, в volumeMounts, мы фактически используем их
Пример (из той же статьи):
apiVersion: v1
kind: Pod
metadata:
name: kuard
spec:
volumes:
- name: "kuard-data"
hostPath:
path: "/var/lib/kuard"
containers:
- image: gcr.io/kuar-demo/kuard-amd64:1
name: kuard
volumeMounts:
- mountPath: "/data"
name: "kuard-data"
ports:
- containerPort: 8080
name: http
protocol: TCP
Здесь мы определяем kuard-data как том, а затем монтируем его в контейнер kuard.
Существуют различные типы томов:
- emptyDir
- Такой объем ограничен сроком службы Блока, но его можно разделить между двумя контейнерами. (в нашем примере выше, это формирует основу для связи между нашей Git-синхронизацией и контейнерами веб-обслуживания). Это выживает после перезагрузки стручка
- hostDir
- это может монтировать произвольные места на рабочем узле в контейнер
- это было использовано в примере выше
- Это может быть использовано, когда модуль хочет получить прямой доступ к хранилищу блоков экземпляра, например. Но его нельзя использовать для хранения обычных данных, поскольку не все хосты будут иметь одинаковую базовую структуру dir.
- сетевое хранилище
- если вы хотите, чтобы данные оставались в модуле, даже когда модуль перемещается, перезапускается и т. Д., Используйте один из нескольких вариантов, доступных в сетевом хранилище
- Kubernetes включает поддержку стандартных протоколов, таких как NFS и iSCSI, а также API хранилища на основе облачных провайдеров для основных облачных провайдеров (как публичных, так и частных)
То есть:
# Rest of pod definition above here
volumes:
- name: "kuard-data"
nfs:
server: my.nfs.server.local
path: "/exports"
«бесшовная» часть относится к аналогичной концепции, представленной в « Миграция на драйверы CSI из встроенных плагинов »
Функция CSI Migration, если она включена, направляет операции с существующими подключаемыми модулями в дереве к соответствующим подключаемым модулям CSI (которые, как ожидается, будут установлены и настроены).
Эта функция реализует необходимую логику перевода и прокладки для перенаправления операций без шва .
В результате операторы не должны вносить какие-либо изменения конфигурации в существующие классы хранения, PV или PVC (ссылаясь на подключаемые модули внутри дерева) при переходе на драйвер CSI, который заменяет подключаемый модуль внутри дерева.
До введения CSI и Flexvolume все плагины томов (например, типы томов, перечисленные выше) были « in-tree », что означало, что они были собраны, связаны, скомпилированы и поставлены с основными двоичными файлами Kubernetes и расширить ядро Kubernetes API.
Это означало, что добавление новой системы хранения в Kubernetes (плагин для томов) потребовало проверки кода в основном хранилище кода Kubernetes.
Таким образом, «беспроблемный способ» здесь подразумевает небольшую или нулевую конфигурацию, помимо первоначального объявления тома.