Перенос дисков PV в Managed Kubernetes от VK Cloud: данные переживают кластер

Кластер Kubernetes часто существует меньше, чем данные внутри него. Его пересоздают при переезде в другую зону доступности, смене топологии, обновлении по blue/green-схеме или проверке новой версии в отдельном контуре. Каждый раз возникает вопрос: что будет с постоянными томами.

В кластерах второго поколения Managed Kubernetes от VK Cloud этот вопрос особенно важен: тома находятся не в пользовательском, а в сервисном проекте, которым управляет платформа. Штатный аддон Velero здесь не поможет, поскольку не поддерживает резервное копирование постоянных томов.

Перенос Persistent Volume в пользовательский проект отвязывает данные от кластера. Диск покидает сервисный проект и становится самостоятельным ресурсом: его можно подключить к виртуальной машине, создать снимок или передать новому кластеру. Разберём, где физически находятся PV кластеров второго поколения, как проходит перенос, в каких сценариях он экономит время и чем отличается от Velero и CSI-снапшотов.

Где живут PV кластеров второго поколения

Кластеры второго поколения Managed Kubernetes от VK Cloud обслуживает платформа. В сервисных проектах находятся виртуальные машины узлов, их диски, постоянные тома и сервисные балансировщики нагрузки, через которые доступен Kubernetes API. Сервисный проект изолирован от пользователя и закрывает доступ к системным компонентам кластера. В пользовательском проекте остаются порты и стандартные балансировщики нагрузки с IP-адресами.

Для повседневной эксплуатации такая изоляция удобна: служебная инфраструктура скрыта от пользователя и не пострадает от случайной операции. Но том с данными остаётся внутри контура, привязанного к кластеру. Чтобы не потерять к нему доступ при удалении или переносе кластера, диск нужно переместить из сервисного проекта в пользовательский.

Постоянные тома работают через Cinder CSI (cinder.csi.openstack.org). Под ним используются блочные хранилища на базе Ceph — ceph-ssd и ceph-hdd, а также High-IOPS SSD на NVMe — high-iops.

Класс хранения по умолчанию в Managed Kubernetes не настроен. Его нужно указать в PVC явно либо заранее назначить класс по умолчанию. Имя преднастроенного класса содержит политику освобождения: суффикс -retain означает Retain, а класс без суффикса использует Delete. Мультизональные классы с volumeBindingMode: WaitForFirstConsumer преднастроены только для кластеров второго поколения.

Режим ReadWriteMany в Managed Kubernetes не реализован. Если нескольким подам нужен доступ к одному тому, используют NFS-сервер на отдельной виртуальной машине.

Reclaim Policy не решает задачу переноса

Внутри Kubernetes судьбу тома определяет reclaim policy. В Managed Kubernetes доступны две политики: Retain и Delete.

При Delete удаление PVC удаляет и PV, а вместе с ним связанный облачный диск VK Cloud. Поэтому сценарий «пересоздадим кластер, а с томами разберёмся потом» рискован: класс хранения без суффикса -retain может удалить данные вместе с заявкой.

Retain сохраняет PV и хранилище. Том получает статус Released, но не становится доступен другому PVC, пока администратор вручную не пересоздаст PV на том же носителе. Политика Recycle в upstream Kubernetes объявлена устаревшей, а в Managed Kubernetes её нет.

Обе политики действуют только в пределах одного кластера. Они не помогают вынести данные в другой кластер, на виртуальную машину или в пользовательский проект. Для этого диск нужно перенести из сервисного проекта и дальше управлять им как обычным облачным диском.

Как работает перенос: четыре шага

Перенос постоянных томов выполняется через личный кабинет и доступен только для кластеров второго поколения. Главно, чтобы том был быть отвязан от группы узлов.

1. Выберите проект с нужным кластером второго поколения и откройте раздел Кластеры Kubernetes → Диски PV. В списке отображаются тома кластеров второго поколения. Группа узлов, к которой подключён диск, указана в столбце «Принадлежит».
2. Убедитесь, что диск не подключён к группе узлов. Удалить или перенести PV можно только после отвязки. Том, примонтированный к поду, перенести нельзя.
3. Переместите диск одним из двух способов:

• в меню «···» напротив тома выберите «Переместить диск в проект»;
• отметьте том флажком и нажмите кнопку «Переместить диск».

4. Подтвердите операцию.
5. Найдите диск в разделе Облачные вычисления → Диски. После переноса им можно управлять как обычным диском проекта: создавать снимки, клонировать, менять тип, подключать к виртуальной машине и увеличивать размер, в том числе без перезагрузки ВМ.

Перенос необратим, вернуть PV из пользовательского проекта в сервисный нельзя. Окно подтверждения на третьем шаге — последняя возможность отменить операцию.

Как подключить диск к новому кластеру

Диск из пользовательского проекта подключают к кластеру через статический PersistentVolume. Идентификатор существующего диска указывают в поле spec.csi.volumeHandle, а в качестве драйвера используют cinder.csi.openstack.org.

Идентификатор действующего тома можно получить командой:

kubectl get pv <ИМЯ_PV> -o jsonpath='{.spec.csi.volumeHandle}'

В манифесте статического PV объём в capacity.storage должен совпадать с объёмом диска, а политикой освобождения нужно указать Retain.

Зона доступности диска должна совпадать с зоной узла. Для этого настраивают nodeAffinity по ключу topology.cinder.csi.openstack.org/zone. Затем создают PVC с теми же accessModes, объёмом и классом хранения. После этого PV должен получить статус Bound.

Манифест статического PV описан в руководстве VK Cloud по миграции между зонами доступности. При этом отдельный сценарий подключения диска по идентификатору в документации отмечен как доступный только для кластеров первого поколения. Сквозной процедуры «перенести PV в пользовательский проект и подключить его к новому кластеру второго поколения» в публичной документации нет, поэтому порядок для второго поколения лучше подтвердить в технической поддержке.

При подключении через статический PV данные не копируются. Диск остаётся тем же блочным ресурсом, поэтому длительность операции не зависит от его объёма.

Четыре сценария, где перенос экономит время

Что учесть до переноса

Консистентность — на стороне приложения

Перенос PV работает с диском, а не с согласованным состоянием приложения. Миграцию нужно проводить на остановленной рабочей нагрузке.

Для баз данных порядок такой: остановить под, дождаться отмонтирования тома и только после этого переносить диск. Если снять диск во время записи, в нём могут остаться недописанные данные.

Возврата в сервисный проект нет

Перемещение работает только в одну сторону: вернуть PV из пользовательского проекта в сервисный нельзя. Переносить тома стоит под конкретную задачу, а не «на всякий случай» перед каждым обновлением кластера.

Объекты PVC и PV в старом кластере

Ссылки внутри кластера вместе с диском не переносятся. Документация не описывает, что происходит с объектами PVC и PV после перемещения тома в пользовательский проект, поэтому их состояние нужно проверить вручную.

В руководстве по миграции нагрузки отдельным шагом указано удаление неиспользуемых ресурсов. В upstream Kubernetes том после удаления заявки получает статус Released и не может быть привязан к другому PVC без ручных действий администратора.

Тарификация

Постоянные тома тарифицируются только для кластеров второго поколения. После переноса диск оплачивается как обычный диск пользовательского проекта: за каждый гигабайт, по цене выбранного типа диска.

Остановленная виртуальная машина не освобождает от оплаты дискового пространства. Конкретные суммы указаны в прайс-листе VK Cloud. Неиспользуемые тома стоит регулярно проверять, иначе расходы будут накапливаться незаметно.

Перенос PV, Velero или CSI-снапшоты: что выбрать

Перенос PV, Velero и CSI-снапшоты решают разные задачи. В кластерах второго поколения Managed Kubernetes от VK Cloud это особенно заметно.

Штатный аддон Velero не поддерживает резервное копирование постоянных томов. Он сохраняет манифесты в бакет класса Hotbox в VK Object Storage, но данные томов в копию не попадают. По умолчанию копии хранятся 72 часа, после чего удаляются.

Velero, установленный самостоятельно, может копировать тома через снапшоты провайдера или File System Backup на kopia, который имеет статус beta. Но документация VK Cloud описывает самостоятельную установку Velero только для кластеров первого поколения. Для второго поколения она предлагает использовать аддон.

CSI-снапшот существует внутри кластера как ресурс VolumeSnapshot. Для восстановления на его основе создаётся новый том, а не откатывается существующий PVC. Контроллер снапшотов в Managed Kubernetes не преднастроен: CRD и external-snapshotter нужно устанавливать вручную.

Перенос PV решает другую задачу: он сохраняет владение данными после удаления кластера.

Заключение

Перенос постоянных томов Kubernetes в проект VK Cloud решает задачу, которую не закрывают ни reclaim policy, ни аддон Velero, ни CSI-снапшоты: данные остаются под управлением проекта независимо от кластера.

После переноса диск можно подключить к виртуальной машине, передать новому кластеру или оставить в архиве. Перед отвязкой тома нужно остановить нагрузку, а перед переносом — помнить, что вернуть диск в сервисный проект уже не получится.

Политику освобождения и порядок выноса томов лучше определить заранее, до того как кластер придётся пересоздавать.