Ответ
В Kubernetes для обмена данными между узлами (хостами) используются механизмы, обеспечивающие сохранность данных вне жизненного цикла подов (Pods). Основные подходы:
1. PersistentVolumes (PV) и PersistentVolumeClaims (PVC) с сетевым бэкендом: Это основной метод. PV описывает физическое хранилище в кластере (например, NFS-шару, блоковое устройство от облачного провайдера). PVC — запрос на это хранилище со стороны пода.
Пример PVC, который может быть удовлетворен сетевым PV:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: shared-data-pvc
spec:
accessModes:
- ReadWriteMany # Критично для доступа с нескольких нод одновременно
resources:
requests:
storage: 10Gi
storageClassName: nfs-client # Имя StorageClass, provisioner'ом для которого является NFS2. StorageClasses для динамической подготовки (Provisioning): Позволяют автоматически создавать PV при создании PVC. Это стандарт для облачных сред (AWS EBS, GCE PD, Azure Disk) и для сетевых файловых систем (NFS, CephFS, GlusterFS).
3. Использование распределенных файловых систем:
- NFS: Классический вариант. Настраивается NFS-сервер, а в кластере используется CSI-драйвер (например,
nfs-subdir-external-provisioner). - CephFS / Rook: Облачное-native распределенное хранилище, интегрируемое в k8s через оператора Rook.
- Longhorn: Распределенная блочная система хранения, специально разработанная для Kubernetes.
4. Объекты для конфигурации (но не больших данных):
- ConfigMaps / Secrets: Для передачи конфигурационных данных и секретов. Они монтируются как файлы или переменные окружения, но хранятся в etcd кластера k8s и не предназначены для больших или часто изменяемых данных.
5. StatefulSets для stateful-приложений:
Для таких приложений (например, БД) StatefulSets обеспечивают стабильные идентификаторы подов и томов (через volumeClaimTemplates), что позволяет каждому поду иметь свое постоянное хранилище, но данные между подами не разделяются автоматически. Для репликации данных используется логика самого приложения.
На практике для общего кэша, медиафайлов или логов между подами на разных нодах я чаще всего настраиваю NFS или облачный файловый сервис (например, AWS EFS, Azure Files) и подключаю его через соответствующий StorageClass с режимом доступа ReadWriteMany.
Ответ 18+ 🔞
А, ну это же классика, ёпта! Сидишь ты такой, пишешь приложение, а оно, сука, разбежалось по разным нодам в кубернетесе, и им надо общую папку, как в старом офисе. А то получается пиздец — один под что-то записал, другой нихуя не видит. Как будто они в параллельных вселенных.
Так вот, слушай сюда, основные способы, чтобы эта мартышлюшка с данными между узлами работала.
1. PersistentVolumes (PV) и PersistentVolumeClaims (PVC), но чтоб сетевые. Это как взять общую сетевою папку (типа NFS) и сказать куберу: «Вот это, блядь, наше хранилище, давай его юзать». PV — это описание самой этой шары, а PVC — это крик души пода: «Дай мне, блядь, 10 гигов отсюда, я писать буду!».
Вот, смотри, как выглядит эта писанина (PVC):
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: shared-data-pvc
spec:
accessModes:
- ReadWriteMany # Вот это самое важное, ёпта! Чтобы много кто сразу мог и читать, и писать.
resources:
requests:
storage: 10Gi
storageClassName: nfs-client # Имя класса, который как раз и тырит место на NFS-сервере.2. StorageClasses для динамической выдачи. Чтобы руками каждый раз PV не создавать, есть такая автоматическая хуйня — StorageClass. Создал PVC, а кубер сам, как по маслу, нарезал тебе кусок из общего сетевого хранилища (будь то облачный диск или та же NFS). Удобно, бля, волнение ебать отпадает.
3. Распределённые файловые системы — основа основ. Тут вариантов, бля, овердохуища:
- NFS: Старый добрый дед. Настроил сервак, воткнул в кубер CSI-драйвер (типа
nfs-subdir-external-provisioner) и всё, пизда рулю. Работает. - CephFS / Rook: Это уже для крутых ребят, которые хотят всё облачно и распределённо. Через оператора Rook настраивается — мощно, но и возни, бля, немало.
- Longhorn: Специально для кубера сделана, чтобы тома между нодами реплицировались. Выглядит солидно, но надо разбираться.
4. ConfigMaps / Secrets для мелочёвки. Ну, это если тебе не гигабайты данных гонять, а какой-нибудь конфиг или пароль. Они в etcd кластера живут и подам оттуда подсовываются. Для больших и живых данных — полная хуйня, не для этого сделаны.
5. StatefulSets для серьёзных пацанов. Если у тебя, например, база данных, которой своя жопа дорога. StatefulSet каждому поду даст уникальный номер и его личный, приклеенный намертво том. Но, внимание, ёб твою мать — данные между подами сами по себе не синхронизируются! Это задача самой базы — реплицироваться. Кубер только диски привязывает.
Если по-простому, по жизни...
Чтобы сделать общий кэш, лог-директорию или хранилище для медиа, на котором будут работать поды с разных нод — чаще всего берут NFS или облачный файловый сервис (типа AWS EFS). Настраивают под него StorageClass, который умеет создавать тома с доступом ReadWriteMany, и потом просто тырят этот PVC в свои поды. И все счастливы, ядрёна вошь!