Перейти к содержанию

Как мигрировать серверы Почты с Docker Compose в Kubernetes

Назначение документа

В документе описан перенос серверов инсталляции Почты VK WorkSpace с Docker Compose в Kubernetes через веб-интерфейс установщика.

Внимание

Миграция доступна начиная с релиза 26.2.3 и требует предварительной установки релиза 26.2.0 или 26.2.1.

Как устроена миграция

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

Внимание

В процессе миграции возможен простой инсталляции на время обновления конфигурации сервисов.

Примечание

Первым переносится управляющий узел (ControlPlane) — до его миграции остальные серверы недоступны для переноса. Сервер мониторинга рекомендуется переносить вторым, сразу после управляющего узла. Сервер с последним экземпляром infraetcd переносится последним: он нужен для работы Calico, пока в инсталляции остаются серверы на Docker Compose.

Подготовка к миграции

Перед началом миграции:

  1. Установите релиз 26.2.0 или 26.2.1.

  2. Выполните обновление до версии 26.2.3 по одной из инструкций, в зависимости от типа инсталляции:

    Внимание

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

  3. Запустите автоустановку с проверкой и дождитесь, пока все обновления выполнятся до 100%.

  4. Запустите проверку баз данных.
  5. Убедитесь, что в работе кластеров нет проблем. Все обнаруженные проблемы нужно устранить до начала миграции.
  6. Откройте страницу пререквизитов на вкладке Обслуживание и убедитесь, что инсталляция соответствует всем требованиям.

Примечание

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

Особенности и ограничения

  • Сервер, на котором расположен последний экземпляр infraetcd, переносится последним. Пока в инсталляции остаются серверы на Docker Compose, работоспособный infraetcd необходим для функционирования Calico.
  • Гибридный режим WireGuard не поддерживается: если WireGuard уже настроен в инсталляции на Docker Compose, миграция не сможет корректно подготовить его конфигурацию.

Особенности миграции сервера мониторинга

Если в дата-центре расположен сервер мониторинга, переносите его вторым — сразу после управляющего узла.

Перед запуском автоустановки на этом сервере вручную запустите контейнеры с агрегаторами: vmagent-relay, graphite-mail, graphite-st, graphite-cloud и другие. Только после этого запускайте автоматическую установку.

Ручной запуск нужен, чтобы создались CNAME-записи. Они направят сервисы, работающие в Kubernetes, со старого доменного имени qdit на новые контейнеры в Kubernetes.

Внимание

Если сервер мониторинга переносится предпоследним — перед последним сервером с infraetcd — обязательна полная автоустановка. Это гарантирует, что к моменту переноса последнего сервера все сервисы будут корректно работать с мониторингом, развернутым в Kubernetes.

Шаг 1. Включите продукт VK Kubernetes

  1. Откройте страницу продуктов установщика: http://<deployer_ip>:8888/products.
  2. Перейдите на вкладку Администрирование.

  3. Включите продукт VK Kubernetes.

    Вкладка «Администрирование» с включенным продуктом VK Kubernetes

Шаг 2. Перейдите в раздел с настройками миграции

Откройте страницу миграции: http://<deployer_ip>:8888/service/k8sMigration. Или перейдите на вкладку Обслуживание → Миграция Kubernetes.

На этом этапе:

  • Расставьте метки серверов.
  • Распределите кастомные значения — опциональный шаг.
  • Выберите управляющие узлы (ControlPlane).
  • Cохраните конфигурацию, чтобы сформированные метаданные использовались на следующих шагах.

Страница миграции Kubernetes

Примечание

Для заполнения полей можно воспользоваться встроенными инструкциями на страницах.

Шаг 3. Добавьте управляющие узлы

Примечание

Шаг является опциональным при необходимости новых управляющих узлов.

Управляющие узлы можно добавить двумя способами:

  • Отдельными серверами — по кнопке Добавить в нижней части страницы. Рекомендуемый вариант: три отдельных инстанса под управляющие узлы кластера.
  • Из уже эксплуатирующихся машин с типом database — если свободных ресурсов нет.

Внимание

При повышенном потреблении ресурсов управляющий узел, размещенный на эксплуатируемой машине, столкнется с оверкоммитом и начнет вытеснять поды на этом сервере.

Если вы решили не добавлять отдельные серверы, перейдите на вкладку Распределение вспомогательных меток.

Добавление серверов ControlPlane

Шаг 4. Расставьте вспомогательные метки

Примечание

Шаг является опциональным при необходимости распределения конкретных ролей на конкретные гипервизоры после миграции.

Пример: Необходимо распределить сборщики только на конкретные сервера.

  1. На вкладке Значения лейблов – добавьте значения для вспомогательной метки.

    Значения лейблов

  2. На вкладке Назначения серверов – распределите все добавленные вспомогательные метки между гипервизорами. Одному гипервизору можно присвоить сразу несколько меток.

Назначение серверов

  1. На вкладке Назначение ролей – установите метки на конкретные роли.

    Назначение ролей

Шаг 5. Расставьте метки серверов

  1. Напротив каждого сервера укажите соответствующую метку. Сервисы распределяются по конкретным нодам на основании указанных меток.
  2. Обязательно добавьте ноду с типом database. Она понадобится для миграции первого управляющего узла, если под управляющую ноду кластера Kubernetes переносится одна из нод БД.
  3. Гипервизору, на котором развернут локальный registry добавьте метку registry.
  4. Нажмите кнопку Сохранить.

Распределение меток серверов

Шаг 6. Создайте конфигурацию будущего кластера

На странице Распределение меток K8S можно добавить несколько кластеров Kubernetes и несколько управляющих узлов.

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

Распределение меток K8S с несколькими кластерами

Шаг 7. Настройте кластер

После сохранения метаданных настройте конфигурацию кластера. Укажите:

  • Режим маршрутизации: VXLAN.
  • Namespace по умолчанию — пространство имен, в котором будут работать сервисы Почты.
  • Домен в кластере K8s.
  • CIDR — диапазон адресов для интерфейсов WireGuard или tunl0.
  • Версия Kubernetes.
  • Использовать BGP — нужен при использовании нескольких дата-центров.
  • Использовать WG — установщик самостоятельно установит и настроит WireGuard на серверах на шаге enable_hybrid_bgp.

Внимание

Если WireGuard уже был настроен в инсталляции на Docker Compose, миграция не сможет корректно подготовить конфигурацию WireGuard. Гибридный режим не поддерживается.

Конфигурация кластера Kubernetes

Шаг 8. Настройте сеть

После сохранения конфигурации заполните сетевые параметры:

Параметр Описание
podCIDR Диапазон адресов для подов
serviceCIDR Диапазон адресов для сервисов
Адрес ControlPlane По умолчанию указывает на порт 6443 публичного IP сервера с типом database, выбранного в качестве управляющего узла

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

Сетевые настройки кластера

Шаг 9. Запустите миграцию нод

После заполнения всех конфигурационных данных можно переходить к переносу серверов.

Внимание

Сначала мигратор потребует перенести управляющие узлы — остальные ноды до этого недоступны для миграции. Выбирайте серверы с соответствующими метками.

Выбор нод для миграции

Шаг 10. Проверьте распределение сервисов и ролей

На странице миграции и распределения ролей установщик покажет:

  • Какие сервисы будут удалены полностью.

    Распределение сервисов и ролей

  • Какие сервисы будут перенесены в кластер Kubernetes в качестве подов.

    Распределение сервисов и ролей

После проверки нажмите кнопку Далее.

Шаг 11. Подтвердите конфигурацию

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

Поставьте галочку в чекбоксе Конфигурация верная и нажмите кнопку Далее.

Итоговая таблица конфигурации

Шаг 12. Дождитесь очистки сервера

Как только конфигурация подтверждена, запускается очистка сервера от Docker Compose:

  1. Последовательно останавливаются сервисы.
  2. Удаляется Calico и ее зависимости.
  3. Удаляется Docker Compose с сопутствующими пакетами.
  4. Нода подготавливается к роли управляющего узла.
  5. На ноду устанавливается Kubernetes и необходимые для работы сервисы, включая CNI, kubelet и runtime.

Процесс очистки сервера

Если возникла ошибка

При ошибке на странице миграции появится отчет. В отчете видно, на каком шаге произошла ошибка. Подробности доступны в логах установщика.

Отчет об ошибке миграции

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

Шаг 13. Мигрируйте роли и сервисы

Когда сервер очищен и на нем запущены компоненты Kubernetes, переходите к миграции сервисов и ролей.

Примечание

На этом шаге мигратор готовит только метаданные для последующего запуска сервисов в Kubernetes. Сами сервисы запускаются на следующем шаге.

Миграция ролей и сервисов

Шаг 14. Запустите автоустановку

Когда метаданные для всех ролей и сервисов подготовлены, конвертацию ноды с Docker Compose на Kubernetes можно считать завершенной.

  1. Перейдите на главную страницу веб-интерфейса установщика.
  2. Запустите автоматическую установку со всеми проверками.
  3. Дождитесь завершения и убедитесь, что в Kubernetes появились первые сервисы.

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

Шаг 15. Проверьте базы данных после обновления

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

Внимание

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

Проверьте состояние всех баз данных

  1. Откройте Настройки → Шардирование и репликация БД → Кластеры баз данных.

  2. Нажмите Опросить базы данных.

  3. Перейдите в контейнер каждой роли Tarantool, например:

    kubectl exec -it -n onprem rima1-0 -- bash
    4. Перейдите в консоль:

    tarantoolctl connect /run/tarantool/tarantool.sock

  4. Выполните команду:

    box.info

  5. Убедитесь, что:

    • В box.info.status состояние — running.
    • В репликации значения box.info.replication.upstrea и downstream — follow.

Если все кластеры в этом состоянии, обновление завершено корректно. Если репликация нарушена, восстановите её по инструкции ниже.

Восстановите репликацию Tarantool или OneDB

Выполняйте этот шаг, только если на предыдущем шаге обнаружены реплики с нарушенной репликацией.

Внимание

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

  • Выбранный источник действительно является актуальным RW-мастером.
  • Восстанавливаемый инстанс является репликой, а не мастером.

Вариант 1. Ребутстрап через веб-интерфейс

  1. В составе нужного кластера найдите неисправную реплику.

  2. Откройте меню реплики и выберите Ребутстрап.

    Пункт «Ребутстрап» в меню реплики

  3. Нажмите Запустить.

    Окно подтверждения ребутстрапа

  4. Дождитесь завершения операции.

    Сообщение об успешном завершении ребутстрапа

  5. Повторно выполните проверку кластера по инструкции «Проверьте состояние всех баз данных».

Во время ребутстрапа данные выбранной реплики удаляются и загружаются заново с мастера.

Внимание

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

Вариант 2. Ручной ребутстрап в Kubernetes

Порядок действий описан на примере кластера rima. В примере считаем, что rima1 - master, а для rima2, rima3 нужно выполнить ребутстрап. Для других кластеров используйте их имена.

  1. Во вкладке Шардирование и репликация выберите инстанс с наибольшим значением LSN. Остальные инстансы кластера остановите, удалив соответствующие StatefulSet:

    kubectl delete sts -n onprem rima2
kubectl delete sts -n onprem rima3

  2. На Kubernetes-нодах остановленных инстансов создайте резервную копию каталогов в /opt/mailOnPremise/dockerVolumes, а оригинальные каталоги удалите переименованием:

    cd /opt/mailOnPremise/dockerVolumes
sudo mv rima2 rima2bak
sudo mv rima3 rima3bak

  3. В веб-интерфейсе установщика на вкладке Переменные окружения установите для мастера переменную:

    TARANTOOL_FORCE_RECOVERY=true

  4. Запустите установку роли для мастера в веб-интерфейсе установщика.

  5. Зайдите в консоль Tarantool мастера:

    kubectl exec -it -n onprem rima1-0 -- \
  tarantoolctl connect /var/run/tarantool/tarantool.sock

    Примечание

    Если pod содержит несколько контейнеров, дополнительно укажите контейнер:

    kubectl exec -it -n onprem rima1-0 \
  -c <контейнер-с-Tarantool> -- \
  tarantoolctl connect /var/run/tarantool/tarantool.sock

  6. Удалите записи в space _cluster. Идентификаторы для удаления возьмите из результата box.space._cluster:select{}:

    box.space._cluster:select{}
box.space._cluster:delete{ИДЕНТИФИКАТОР_RIMA2}
box.space._cluster:delete{ИДЕНТИФИКАТОР_RIMA3}

    Примечание

    На одном из удалений может появиться ошибка RO — это ожидаемо.

    В результате команда должна возвращать одну запись:

    box.space._cluster:select{}

  7. Сохраните snapshot:

    box.snapshot()

  8. В веб-интерфейсе установщика установите для мастера переменную:

    TARANTOOL_FORCE_RECOVERY=false

  9. Повторно запустите установку роли для мастера.

  10. Запустите установку роли для остальных инстансов кластера. Установщик заново создаст удалённые StatefulSet rima2 и rima3.

  11. После запуска всех инстансов нажмите Опросить базы данных и проверьте состояние кластера.

Шаг 16. Перенастройте рассыльщики служебных писем

Этот шаг нужен, если вы перенесли сервер с сервисами relay или fallback.

После миграции такого сервера перенастройте адрес рассылщиков на странице установщика /config/main/components/sendersSettings/.

Внимание

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

Шаг 17. Перенастройте отправку писем Календаря

  1. Перейдите в Панель администратора VK WorkSpace, в раздел Настройка отправки писем от календаря.
  2. Измените стандартный адрес SMTP-сервера на relay-headless-service.onprem.svc.dc1.<домен в кластере K8S>.

Миграция ролей и сервисов