Зачем вообще думать про storage в single-node Kubernetes
Один узел Kubernetes на VDS — нормальная и распространённая схема: небольшие прод-проекты, стенды, внутренние сервисы, CI, мониторинг. Но почти сразу всплывает вопрос: контейнеры эфемерны, а данные должны переживать рестарты Pod, пересоздания Deployment и обновления.
В Kubernetes это решается через PersistentVolumeClaim (PVC): приложение просит том нужного размера и режима доступа, а provisioner создаёт и подключает конкретное хранилище.
Ключевая особенность single node: у вас нет второй машины, чтобы реально «распределить» данные и пережить падение узла за счёт репликации на другой ноде. Поэтому выбор storage-решения превращается в баланс между простотой, производительностью, снапшотами/backup и тем, как именно вы будете восстанавливаться при аварии.
На одном узле любой вариант хранения остаётся локальным в физическом смысле. Разница между решениями — в автоматизации (PV/PVC), удобстве снапшотов и резервного копирования, а также в операционных рисках и цене по ресурсам.
Базовые понятия: PV/PVC/StorageClass и что важно именно для VDS
Чтобы сравнение было предметным, зафиксируем термины:
- PVC — запрос на том (размер, access mode, класс хранения).
- PV — реальный том, созданный под конкретный PVC (директория, устройство, dataset, образ).
- StorageClass — профиль хранения: какой provisioner создаёт PV и с какими параметрами.
- Access modes — на single node почти всегда используется
ReadWriteOnce(RWO).ReadWriteMany(RWX) обычно требует сетевого хранилища или специальных CSI и редко оправдан на одном узле.
Для VDS практически важны три вещи:
- Профиль диска (latency/IOPS): для БД, очередей, логов и TSDB «медленный слой» быстро становится бутылочным горлышком.
- Сценарий аварии: что делаете при потере ноды или порче ФС — поднимаете новую ноду и разворачиваете данные из backup, или хотите быстро откатываться снапшотами?
- Операционная сложность: чем больше компонентов (контроллеры, engines, сервисы хранения), тем больше мониторинга, обновлений и потенциальных «неочевидных» сбоев.
Если вы на этапе выбора железа/тарифа, ориентируйтесь на задачу: под базу и мониторинг чаще выгоднее взять VDS с быстрым диском, чем «умный» CSI поверх медленного хранилища.
local-path provisioner: самый простой вариант для single node
local-path provisioner — популярный дефолт в k3s и частый выбор для одного узла. Идея простая: PVC превращается в каталог на локальном диске ноды (в заранее заданной базовой директории), который монтируется в Pod.
Как это работает
Provisioner создаёт директорию под каждый PV и выставляет привязку к ноде (node affinity). На одном узле это практически идеальная модель: минимум абстракций и почти нулевая цена по CPU/RAM.
Плюсы
- Производительность близка к нативной (это просто ФС хоста).
- Простота: меньше компонентов — меньше точек отказа.
- Прозрачность: данные — это файлы в директории, удобно дебажить и делать аварийные копии.
Минусы и типовые риски
- Нет отказоустойчивости: потеря диска или ноды = потеря тома. Спасает только внешний backup.
- Миграция на другой узел (если позже добавите ноды) не автоматическая: PV привязан к конкретной машине.
- Снапшоты/backup нужно организовывать отдельно: на уровне приложения, файловой системы или внешними инструментами.
Практика: пример StorageClass и PVC
Ниже минимальные манифесты. В реальной установке имя класса может отличаться (в k3s часто уже есть local-path).
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: local-path
provisioner: rancher.io/local-path
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: app-data
spec:
accessModes:
- ReadWriteOnce
storageClassName: local-path
resources:
requests:
storage: 20Gi
Для восстановления на single node заранее продумайте процедуру «поднять новый сервер → развернуть кластер → вернуть данные». В качестве отправной точки можно использовать статью про резервное копирование в S3-совместимое хранилище: бэкапы в S3 через restic и borg.
Longhorn: удобные снапшоты и backup, даже если узел один
Longhorn — CSI-хранилище от Rancher/SUSE, которое часто берут ради репликации между нодами. На single node репликация «внутри одного узла» не спасает от потери диска, но Longhorn всё равно может быть полезен как управляемый слой: снапшоты, бэкапы, UI, состояние томов.
Что вы реально получаете на single node
- Снапшоты на уровне тома и понятный workflow отката.
- Backup томов во внешний бэкенд (объектное хранилище или NFS, в зависимости от вашей схемы).
- Наблюдаемость: видно состояние томов, ошибки replica/engine, прогресс backup-операций.
Цена удобств
- Производительность: дополнительный слой хранения и фоновые операции (snapshot/backup) могут заметно ударить по latency и write IOPS. Для write-heavy БД нагрузку нужно измерять тестом.
- Ресурсы: больше Pod и служебных компонентов, выше требования к CPU/RAM и диску.
- Диагностика: появляется отдельный «storage-стек» со своими сбоями, логами и апгрейдами.
Практика: StorageClass с базовыми параметрами
Ниже пример, который отражает идею: управляемые тома, расширение и количество реплик. На одном узле обычно ставят одну реплику, чтобы не плодить лишние записи на тот же диск.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: longhorn
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
numberOfReplicas: "1"
staleReplicaTimeout: "30"
На что обратить внимание перед продом
- Проверьте, как ведёт себя нагрузка при регулярных снапшотах и backup (пиковые записи).
- Проверьте реальный restore на «пустой ноде»: развёртывание кластера с нуля и восстановление тома.
- Отдельно проверьте заполнение диска: что будет с приложениями и самим Longhorn, когда место заканчивается.
OpenEBS: гибкий конструктор, но режим выбирайте осознанно
OpenEBS — это набор подходов к storage в Kubernetes: от максимально «локальных» вариантов (LocalPV) до более сложных движков вокруг ZFS/дисковых пулов. Для single node чаще всего рассматривают:
- OpenEBS LocalPV — близко по смыслу к local-path, но с выбором варианта: hostpath, device, иногда LVM/ZFS в зависимости от поставки.
- ZFS-подход — если вы готовы администрировать ZFS: получаете снапшоты/клоны и удобную отправку снапшотов для backup.
Плюсы OpenEBS на VDS
- Гибкость: можно начать с LocalPV и усложнять по мере необходимости.
- Контроль над устройствами: сценарии с отдельным диском/разделом под приложение (device) часто проще поддерживать, чем «всё в одной директории».
- Снапшоты через ZFS (если выбран этот путь): удобно для частых откатов и отправки снапшотов в backup-репозиторий.
Минусы
- Нужно выбрать правильный режим под задачу, иначе миграция PVC может занять время (и потребует окна).
- Операционная сложность растёт, если вы уходите дальше LocalPV hostpath/device.
- Производительность зависит от движка: LocalPV обычно быстрый, а ZFS и другие слои стоит тестировать под нагрузкой.
Пример: LocalPV hostpath StorageClass
Суть та же, что и у local-path: директория на хосте под каждый PV.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: openebs-hostpath
provisioner: openebs.io/local
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
parameters:
cas-type: "local-hostpath"
basePath: "/var/openebs/local"
Сравнение: local-path vs Longhorn vs OpenEBS на одном узле
Для быстрого выбора полезно сравнить по критериям, которые обычно важны на практике: производительность, backup/restore и операционная сложность.
Производительность
- local-path: обычно лучший latency и IOPS, потому что это прямой доступ к ФС хоста.
- OpenEBS LocalPV: близко к local-path; при режиме device может быть удобнее для «отдельного диска под БД».
- Longhorn: чаще медленнее из-за дополнительного слоя и фоновых задач; на NVMe нередко приемлемо, но для активной БД тест обязателен.
Backup и восстановление
- local-path: вы строите backup сами (на уровне приложения, файловых копий, снапшотов на хосте). Плюс — простота и предсказуемость.
- Longhorn: сильная сторона — снапшоты и централизованный backup томов; но restore нужно регулярно проверять, а не «верить в кнопку».
- OpenEBS: зависит от режима. LocalPV = как local-path, ZFS = мощно по снапшотам, но требует дисциплины и понимания ZFS.
Сложность поддержки
- local-path: минимальная сложность, минимум компонентов.
- OpenEBS: от «почти просто» (LocalPV) до заметно сложнее (ZFS-слой и его обслуживание).
- Longhorn: больше компонентов и отдельный контур мониторинга, плюс аккуратные обновления Longhorn вместе с кластером.
Практические сценарии: что выбрать под тип нагрузки
База данных на single node (PostgreSQL/MySQL)
Если база чувствительная к latency и fsync, чаще всего разумнее начинать с local-path или OpenEBS LocalPV (hostpath/device) и вкладываться в правильный backup на уровне СУБД. Для PostgreSQL полезно иметь отработанный PITR: резервное копирование и восстановление PostgreSQL через WAL (PITR).
Longhorn для БД имеет смысл включать только если вы осознанно принимаете цену по производительности ради удобных снапшотов и управляемого backup томов.
Мониторинг (Prometheus/VictoriaMetrics), логи, очереди
Здесь часто важнее управляемость и предсказуемое восстановление. Longhorn может быть удобен, если вы планируете регулярные снапшоты и выгрузку backup, а нагрузка укладывается в ресурс диска/CPU. Если упираетесь в скорость записи — local-path/OpenEBS LocalPV обычно проще и быстрее.
Dev/staging, pet-проекты, CI
local-path закрывает большинство потребностей: просто, быстро, без лишней инфраструктуры. Усложняйте только когда есть конкретная причина (например, быстрые откаты по снапшоту).
Чеклист перед выбором: что проверить администратору
- Где физически лежат данные: какой диск, какая ФС, есть ли отдельный volume под data.
- Что будет при заполнении диска: алерты, поведение приложений, влияние на kubelet и storage-компоненты.
- Как расширять PVC: поддерживает ли StorageClass
allowVolumeExpansionи что нужно сделать внутри Pod/ФС после расширения. - Реальный restore: не «backup где-то есть», а подняли новую ноду и восстановили приложение из бэкапа в тесте.
- План обслуживания: как обновляете Kubernetes и CSI, есть ли окно, какие шаги отката.
Бэкапы: минимально рабочие стратегии для single node
На одном узле важно принять базовый факт: storage-слой не заменяет резервное копирование. Независимо от того, используете вы Longhorn, OpenEBS или local-path, стратегия должна быть простой, повторяемой и проверяемой.
Стратегия A: backup на уровне приложения
Для баз данных и некоторых сервисов это самый контролируемый вариант: дампы, физические бэкапы, WAL/бинлоги, регламент проверки восстановления. Обычно это даёт лучшую консистентность, чем файловые копии PVC.
Стратегия B: снапшот тома + внешний backup
Подходит, когда приложение нормально переживает crash-consistent снапшоты или вы умеете «замораживать» запись. Longhorn и ZFS-сценарии OpenEBS упрощают такие операции, но тест восстановления обязателен.
Стратегия C: файловый backup PVC
Работает для статических данных (медиа, артефакты, репозитории). Для активно пишущих БД чаще всего нежелателен без механизмов консистентности.
Итоги: быстрый выбор без лишней теории
- Нужны максимальная скорость и простота — берите
local-path provisioner(или OpenEBS LocalPV) и инвестируйте в нормальный backup/restore-процесс. - Нужны снапшоты и управляемый backup томов — смотрите в сторону
Longhorn, но обязательно измеряйте производительность на вашей нагрузке. - Нужна гибкость (hostpath/device/ZFS) и вы готовы администрировать слой хранения —
OpenEBSподходит, особенно в LocalPV-режиме для single node.
Какой бы вариант вы ни выбрали, на одном узле «выигрывает» не магия CSI, а дисциплина: мониторинг диска, регулярные бэкапы и проверка восстановления. Тогда storage в Kubernetes на VDS будет предсказуемым и не превратится в лотерею при первой же аварии.
