Что такое volume в Kubernetes и зачем он нужен

Volume в Kubernetes — это абстракция для хранения данных, которую можно подключать к Pod и контейнерам внутри Pod. Она даёт место для данных, отличное от временной файловой системы контейнера (overlay/fs слоя), и решает две основные задачи: сохранить нужные данные при перезапуске контейнера внутри того же Pod и/или предоставить общий каталог для нескольких контейнеров в одном Pod.

Ключевые свойства

• Volume объявляется в spec.volumes Pod-а и монтируется в контейнеры через volumeMounts.

• Жизненный цикл volume привязан к Pod (для многих видов volume): когда Pod удаляется — volume, описанный в Pod, тоже теряется (есть исключения — PersistentVolume).

• Volume обеспечивает совместный доступ для всех контейнеров в одном Pod (полезно для sidecar-паттернов).

• Есть как эпhemerальные (временные, например emptyDir), так и персистентные (PersistentVolume + PVC), которые сохраняют данные независимо от конкретных Pod.

Типы и примеры использования

• emptyDir — временная директория на ноде, создаётся при запуске Pod и удаляется при его завершении. Подходит для временных файлов, кэшей между контейнерами в Pod. Можно задать emptyDir.medium: "Memory" для tmpfs (RAM).

• hostPath — монтирует путь с ноды в Pod. Используйте с осторожностью (безопасность, привязка к ноде).

• configMap / secret — монтируют конфигурацию или секреты как файлы или переменные окружения.

• downwardAPI — даёт доступ к метаданным Pod (имя, namespace, labels) как файлы/переменные.

• persistentVolumeClaim (PVC) — логический запрос хранения; связывается с PersistentVolume (PV), который представляет реальный ресурс хранения (NFS, cloud-disk, iSCSI, Ceph, CSI-драйвер и т.д.). PVC позволяет получить персистентное хранилище, которое переживёт перезапуск Pod и даже удаление/воссоздание Pod на другой ноде (если PV поддерживает это).

• CSI (Container Storage Interface) — современный плагинный механизм для подключения внешних систем хранения (AWS EBS, GCE PD, Azure Disk, NFS, Gluster, Ceph, и др.) через драйверы.

Доступ и режимы

• AccessModes для PV/PVC: ReadWriteOnce (RWO) — запись с одного узла, ReadOnlyMany (ROX) — можно читать с многих узлов, ReadWriteMany (RWX) — запись с многих узлов (поддерживается не всеми провайдерами).

• Reclaim policy у PV (например Delete/Retain) — что происходит с физическим хранилищем после удаления PV/PVC.

Примеры YAML

Ephemeral (emptyDir):

apiVersion: v1
kind: Pod
metadata:
name: example-emptydir
spec:
containers:
\- name: app
image: busybox
command: \["sh","-c","sleep 3600"\]
volumeMounts:
\- name: cache
mountPath: /cache
volumes:
\- name: cache
emptyDir: {}
Persistent (PVC + Pod):
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-claim
spec:
accessModes:
\- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: standard
\---
apiVersion: v1
kind: Pod
metadata:
name: pod-with-pvc
spec:
containers:
\- name: db
image: postgres
volumeMounts:
\- name: data
mountPath: /var/lib/postgresql/data
volumes:
\- name: data
persistentVolumeClaim:
claimName: my-claim

Практические сценарии

• Базы данных и блоб-хранилища — требуют персистентного тома (PVC → PV).

• Совместная работа контейнеров в Pod (sidecar logging, agent) — emptyDir или общий том.

• Передача конфигурации/секретов — configMap / secret.

• Быстрый временный кэш или временный рабочий каталог — emptyDir.

• Логи/архивы — лучше централизовать (EFK, Loki), но для краткосрочной потребности можно монтировать том.

Ограничения и подводные камни

• Некоторые volume (hostPath, локальные PV) привязывают Pod к конкретной ноде — это ухудшает переносимость.

• Не всякое хранилище поддерживает RWX; для масштабируемых приложений нужен сетевой сторидж с поддержкой мульти-рид/райт.

• Если приложение пишет файлы внутри контейнера (не stdout), kubectl logs это не покажет — нужно монтировать или просматривать файлы через exec или собирать логи агентом.

• Права и безопасность: hostPath и неправильные права на монтируемые секреты опасны, внимательно настраивайте права доступа и securityContext.

Полезные опции

• subPath — смонтировать только поддиректорию тома в контейнер.

• readOnly: true на volumeMount — сделать том доступным только для чтения.

• Динамическое выделение (StorageClass) — позволяет автоматически создавать PV при создании PVC.

• Расширение PVC, снапшоты и бэкапы — зависят от провайдера/StorageClass.

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