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

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

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

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

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

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

   • Установка на 1 машину.
   • Кластерная установка.

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.

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

2. Перейдите на вкладку Администрирование.

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

   

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

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

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

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

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

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

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

   

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

   

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

   

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

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

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

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

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

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

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

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

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

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

  

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

  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    
   kubectl exec -it -n onprem rima1-0 -- bash

4. Перейдите в консоль:

    
   tarantoolctl connect /run/tarantool/tarantool.sock

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

    
   box.info

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

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

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

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

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

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

   

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

   

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

   

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

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

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

    
   kubectl delete sts -n onprem rima2kubectl delete sts -n onprem rima3

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

    
   cd /opt/mailOnPremise/dockerVolumessudo mv rima2 rima2baksudo 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

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

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

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

    
   box.space._cluster:select{}

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

    
   box.snapshot()

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

    
   TARANTOOL_FORCE_RECOVERY=false

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

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

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

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

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

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

Технический писатель: Груздев Никита