Как перенести приложение k3s на другой VPS с Velero и сохранить данные

MAATRIX · 17 октября 2026 · 8 мин чтения

У Kubernetes есть замечательное свойство: он умеет заново создать приложение по его описанию. И есть неприятная бытовая подробность: заново созданная бухгалтерия без документов мало кого радует. Когда проект переезжает с одного VPS на другой, зелёные значки у контейнеров ещё не означают, что переехали клиентские файлы, база и ключи доступа.

Velero помогает перенести ресурсы Kubernetes и, при подходящей настройке хранилища, содержимое томов. Но сначала надо разобраться, где именно живут данные. Особенно в k3s: удобный локальный диск может оказаться тем местом, которое привычная команда резервирования вообще не копирует.

Ниже — маршрут переноса одного приложения. Он предполагает доступ администратора к обоим кластерам, отдельное объектное хранилище резервных копий и заранее установленный Velero совместимой версии. Это не перенос всей операционной системы и не обещание миграции без единой секунды остановки.

Перед упаковкой проверьте шкафы

Возьмём учебный проект: личный кабинет с PostgreSQL и загруженными пользователями документами. Он работает в пространстве имён portal. Составим ведомость: Deployment веб-приложения, Service, Ingress, ConfigMap, Secrets, PVC с документами, база, задания по расписанию и используемые операторы.

Начальная инвентаризация выполняется в исходном кластере:

kubectl --context=source -n portal get deploy,statefulset,svc,ingress,pvc
kubectl --context=source get pv,storageclass
kubectl --context=source -n portal get cronjob

Имена source, target и portal в примерах условные: подставьте свои контексты и пространство имён. Не переключайте рабочий контекст на память — явно указывайте его в командах. Два одинаковых приглашения терминала способны устроить очень убедительный спектакль о человеческом факторе.

Отдельно запишите внешние зависимости: почтовый сервис, объектное хранилище, домен, базу вне кластера, OAuth-адреса возврата. Они не появляются на новом сервере только потому, что восстановлен Deployment. Нужны также образы контейнеров с фиксированными версиями и доступ к реестру.

Главная ловушка k3s: local-path и hostPath

Название StorageClass не говорит всей правды. Откройте описание каждого PV и посмотрите его фактический тип:

kubectl --context=source get pv IMYA_TOMA -o yaml

Вместо IMYA_TOMA укажите имя из предыдущего списка. Если обнаружен spec.hostPath, нельзя считать такой том автоматически защищённым File System Backup. В документации Velero этот тип указан среди неподдерживаемых. Тип local отличается от hostPath, хотя оба связаны с диском узла. Сам Local Path Provisioner умеет создавать разные варианты томов в зависимости от настройки.

Для уже работающего приложения на неподдерживаемом томе выберите отдельный перенос файлов: остановите изменения, скопируйте каталог с сохранением прав, проверьте контрольные суммы и восстановите его в заранее подготовленное хранилище нового кластера. Базу переносите средствами самой СУБД. Velero в таком сценарии отвечает за выбранные Kubernetes-ресурсы, а ведомость данных — за то, что осталось за пределами его возможностей.

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

Подготовьте место назначения до резервной копии

На целевом VPS создайте k3s совместимой версии. Для первого переноса разумно сохранить ту же версию Kubernetes и приложения; обновление можно провести позже отдельной операцией. Velero не поддерживает восстановление в более старую версию Kubernetes, а различия API требуют проверки. Это отмечено в руководстве по миграции кластеров.

Установите нужные CRD и операторы, контроллер Ingress, хранилище и механизм выдачи сертификатов. Проверьте, что новый StorageClass действительно создаёт том нужного размера. Старые привязки к узлам, имена классов хранения и внешние IP нельзя переносить механически. Правила замены и порядок восстановления описаны в справочнике восстановления Velero.

Velero на обоих кластерах должен видеть один каталог резервных копий в объектном хранилище. На принимающей стороне используйте режим чтения для этого расположения, чтобы тестовое восстановление не удалило исходные архивы. Если применяется File System Backup, подготовьте node-agent и сохраните необходимые секреты репозитория отдельно от потерянного сервера.

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

Сначала согласованное состояние, затем backup

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

Если все включённые тома подходят для File System Backup и node-agent настроен, пример резервирования пространства имён выглядит так:

velero --kubecontext source backup create portal-move-20261017 \
  --include-namespaces portal \
  --default-volumes-to-fs-backup \
  --snapshot-volumes=false --wait

velero --kubecontext source backup describe portal-move-20261017 --details
velero --kubecontext source backup logs portal-move-20261017

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

Посмотрите не только общий статус, но и перечень скопированных томов, объём, предупреждения и длительность. Сопоставьте результат с ведомостью. Отсутствующий каталог на триста гигабайт может очень приятно ускорить backup; радоваться такому рекорду следует осторожно.

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

Репетиция на новом сервере

Дождитесь появления резервной копии в принимающем Velero. Убедитесь, что выбран именно нужный архив, а пространство назначения не содержит действующей версии приложения. Затем восстановите его:

velero --kubecontext target backup get
velero --kubecontext target restore create portal-rehearsal \
  --from-backup portal-move-20261017 --wait

velero --kubecontext target restore describe portal-rehearsal --details
kubectl --context=target -n portal get pods,pvc

Если данные переносились отдельно, восстановите их по подготовленному плану до открытия доступа приложению. Проверьте владельцев файлов, права, объём тома и соответствие версии базы. Не запускайте старый каталог PostgreSQL на произвольной новой основной версии сервера.

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

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

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

Не забудьте о времени: часовой пояс контейнера, расписание ежедневных задач и срок действия подписанных ссылок могут отличаться от привычной настройки старого сервера. Задача, успешно перенесённая на три часа раньше, с точки зрения планировщика совершенно исправна. С точки зрения отдела продаж — уже не всегда.

Результаты репетиции храните рядом с ведомостью переноса. Если обнаружилась ручная правка, внесите её в конфигурацию или в точную последовательность действий. Финальный переезд не должен зависеть от того, помнит ли администратор, какую именно галочку он переставил прошлым вечером.

Переключение без двух независимых историй

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

Старый сервер некоторое время сохраняют в режиме, который исключает запись. Возврат DNS назад после появления новых заказов на новом сервере уже не является простым откатом: придётся переносить эти заказы обратно или согласовывать две истории. Поэтому решение о возврате должно учитывать момент первой рабочей записи.

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

Какой VPS нужен для такого переноса

Для небольшого учебного k3s с приложением и инструментами резервирования можно начать испытания с MAATRIX Heka Standard: 4 vCPU, 8 ГБ памяти и 160 ГБ диска. Это ориентир для стенда, а не обещание вместить любую базу. Если сама рабочая информация занимает больше диска тарифа, выбор очевидно начинается с другого объёма хранения.

Суммируйте данные, образы контейнеров, временные файлы восстановления, журналы и запас на рост. Во время распаковки архив и восстановленный каталог могут существовать одновременно. Объектные резервные копии храните независимо от единственного VPS: потеря узла не должна уничтожать и систему, и её запасной экземпляр.

В MAATRIX доступна установка k3s через каталог приложений; совместимое хранилище, Velero и проверку восстановления настраивают отдельно. У одиночного узла остаётся единая точка отказа. Но даже такой кластер можно сделать переносимым, если заранее известно, что копируется, где лежат секреты и по каким признакам принимается результат.