Исследования российского ИТ-рынка показывают, что компании все чаще стали выбирать Managed Kubernetes отечественных провайдеров. При этом рост спроса обусловлен не только построением облачной инфраструктуры с нуля, но и необходимостью «приземления» уже существующих ИТ-ландшафтов на российских платформах.
Меня зовут Михаил Карцев. Я инженер по разработке и эксплуатации в VK Cloud. Мы продолжаем серию статей о правильной и безопасной миграции компонентов виртуальной инфраструктуры между облаками. В первом и втором материалах серии мы разобрались с переносом между платформами виртуальных машин, баз данных и объектных S3-хранилищ, а в этой статье разберемся с миграцией кластера Kubernetes из AWS в VK Cloud.
Подготовка к миграции Kubernetes: основные рекомендации
Миграцию работающего кластера Kubernetes стоит рассматривать как транспортировку большой хрустальной вазы — сделать это можно, но надо тщательно подготовиться и быть аккуратным в процессе перевозки.
Так, миграции Kubernetes должно предшествовать несколько этапов подготовки.
Проверка инфраструктуры и зависимостей. Перед миграцией надо понимать, как K8s встроен в существующий ИТ-ландшафт, как влияет на другие сервисы и что нужно переносить на новую платформу вместе с кластером. Такой аудит нужен, чтобы понять, можно ли вообще проводить миграцию и в каких объемах она будет.
Проверка сети. Здесь проверяются возможности канала. Пропускная способность канала в сочетании с размером мигрируемого кластера определяет, сколько времени понадобится на переезд. Соответственно, на какой период придется сделать кластер и приложения на нем недоступными.
Проверка совместимости. Важно, чтобы исходный кластер и нагрузки, работающие на нем, были совместимы с кластером на целевой платформе. Обычно для проверки совместимости хватает сравнения поддерживаемых версий K8s на платформах. Если этого недостаточно, нужную информацию можно запросить у техподдержки целевой облачной платформы.
Вводные данные: исходная и целевая инфраструктура
Для наглядности разбора каждого этапа миграции мы предварительно развернули кластер K8s с названием demo-vkcloud в сервисе Amazon Elastic Kubernetes Service.
На самом кластере мы запустили приложение Moodle — это платформа для хранения обучающих курсов VK Cloud. Приложение является продовой нагрузкой.
Примечание: подробную инструкцию по созданию кластера в Amazon EKS можно найти здесь.
Нашей целевой платформой для миграции является VK Cloud. Здесь мы тоже предварительно создали кластер, который для удобства также назвали demo-vkcloud.
Кластер пустой — на нем «крутятся» только системные поды.
Примечание: в VK Cloud доступен сервис Cloud Containers — полностью управляемая облачная платформа. Она позволяет развертывать приложения в контейнерах в пуле вычислительных хостов и управлять этими контейнерами через K8s. Сервис позволяет быстро получать готовые кластеры Kubernetes для проектов любого размера. Подробная инструкция по созданию кластера Kubernetes — здесь.
Стек для миграции
Самый распространенный способ миграции — резервное копирование с последующим развертыванием бэкапа на целевой платформе. Такой подход — безопасный и простой. Более того, для его реализации надо минимум ресурсов и инструментов. Например, для миграции кластера Kubernetes из AWS в VK Cloud нам понадобится только:
Kubectl — стандартная утилита командной строки для управления кластерами Kubernetes;
AWS CLI — интерфейс командной строки для работы с сервисами AWS;
Velero — клиент-серверная утилита для резервного копирования и восстановления ресурсов кластера Kubernetes.
Примечание: в статье мы не будем отдельно останавливаться на описании порядка установки Velero — весь алгоритм уже есть в документации VK Cloud. Его можно найти здесь.
Алгоритм миграции
Итак, перейдем непосредственно к миграции кластера Kubernetes.
Создание резервной копии кластера AWS
Подготовка хранилища
Первое, что нам нужно сделать, — создать резервную копию кластера Kubernetes, работающего в AWS.
Для размещения бэкапа, который мы будем создавать, нужно хранилище. Причем важно, чтобы оно могло вместить кластер любого размера, поэтому для этих задач мы будем использовать бакет S3. Само S3-хранилище будем разворачивать в VK Cloud — это сделает бэкапы «ближе».
Для этого переходим в Личный кабинет VK Cloud. Заходим в раздел «Объектное хранилище» и подраздел «Бакеты».
Нажимаем «Добавить».
Указываем название бакета и класс хранения. Выбираем Hotbox — он предпочтительнее для миграции.
Установка серверной части Velero
На следующем этапе подключаемся к кластеру в AWS и проверяем его доступность.
m.kartsev@m-kartsev ~/Jobs/vk/velero_test
$ export KUBECONFIG=/Users/m.kartsev/ .kube/config
m.kartsev@m-kartsev ~/Jobs/vk/velero_test
$ kubectl cluster-info
Kubernetes control plane is running at https://F97FAlE18635C488F16FDBD4E0C9F0E4.gr7.eu-central-l.eks.amazonaws.com
CoreDNS is running at https://F97FAlE18635C488F16FDBD4E0C9F0E4.gr7.eu-central-l.eks.amazonaws.сom/api/vl/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.Далее устанавливаем серверную часть Velero на Kubernetes в AWS.
Вводим следующую команду, где в числе прочего передаем «координаты» только что созданного бакета S3, в который нужно положить бэкап.
m.kartsev@m-kartsev ~/Jobs/vk/velero_test
$ velero install \
--plug-ins \
velero/velero-plugi n-for-aws:vl.9.0 \
--provider aws \
--bucket demo-vkcloud-moodle \
--prefix data \
--secret-file ./s3_creds \
--use-volume-snapshots=false \
--backup-location-config \
region=ru-msk,s3ForcePathStyle=”true",s3Url=https://hb.ru-msk.vkcs.cloud \
--uploader-type restic \
--use-node-agentДожидаемся выполнения команды.
Передаем вторую часть кода установки серверной части Velero.
m.kartsev@e-kartsev ~/Jobs/vk/velero_test
$ kubectl -n velero create secret generic openstack-cloud-credentials \
--from-literal OS_PROJECT_ID=$OS_PRO3ECT_ID \
--from-literal OS_REGION_NAME=$OS_REGION_NAME \
--from-literal OS_IDENTITY_API_VERSION=$OS_IDENTITY_API_VERSION \
--from-literal OS_PASSWORD=$OS_PASSWORD \
--from-literal OS_AUTH_URL=$OS_AUTH_URL \
--from-literal OS_USERNAME=$OS_USERNAME \
--from-literal OS_INTERFACE=$OS_INTERFACE \
--from-literal OS_FILE_OPERATION_TIMEOUT=$OS_FILE_OPERATION_TIMEOUT \
--from-literal OS_DOMAIN_NAME=$OS_USER_DOMAIN_NAME \
-о yamlТакже дожидаемся выполнения команды. Обычно на это требуется меньше минуты.
Далее патчим Velero, чтобы ограничить его потребление ресурсов для снижения нагрузки на продовый кластер — в противном случае есть риск, что Velero начнет забирать слишком много оперативной памяти и мощностей процессора.
m.kartsev@kartsev ~/Jobs/vk/velero_test
$ kubectl patch deployment velero -n velero --patch-file velero-patch-aws.yaml
deployment.apps/velero patched
m.kartsev@m-kartsev ~/Jobs/vk/velero_test
$ kubectl patch daemonsets node-agent -n velero --patch-file velero-patch-daemonsets.yml
daemonset.apps/node-agent patchedПосле этого проверяем, что Velero установлен успешно и корректно.
Создание бэкапа
Передаем команду на создание резервной копии. Среди аргументов также добавляем правила для визуализации процесса бэкапа — чтобы можно было отследить все этапы.
Примечательно, что мы добавляем в бэкап не только сам кластер, но и всю его «обвязку», включая балансировщик и упомянутое приложение moodle, которое крутится на кластере. Причем мигрируют даже актуальные конфиги.
В нашем случае приложение небольшое, поэтому бэкап выполнится быстро. Дожидаемся сообщения об успешном создании резервной копии.
На этом работа с AWS и кластером Kubernetes в нем завершена.
Восстановление резервной копии кластера в VK Cloud
Подключение к кластеру в VK Cloud
Передаем команду на подключение к предварительно созданному кластеру Kubernetes в VK Cloud — далее будем работать только с ним.
m.kartsev@m-kartsev ~/Jobs/vk/velero_test
$ export KUBECONFIG=/Users/m.kartsev/Downloads/demo-vkcloud_kubeconfig.yaml
m.kartsev@m-kartsev ~/Jobs/vk/velero_test
$ kubectl cluster-info
Kubernetes control plane is running at https://89.208.211.13:6443
CoreDNS is running at https://89.208.211.13:6443/api/vl/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.Далее по аналогии в два этапа устанавливаем серверную часть Velero уже на кластер в VK Cloud. Единственное отличие на уровне кода — добавляется один плагин для работы с VK Cloud.
m.kartsev@m-kartsev ~/Jobs/vk/velero_test
$ velero install \
--plugins \
velero/velero-plugin-for-aws:vl.8.2,registry.infra.mail.ru:5010/velero/velero-plugin-mcs:vl.2.2 \
--provider aws \
--bucket demo-vkcloud-moodle \
--prefix data \
--secret-file ./s3_creds \
--use-volume-snapshots=false \
--backup-location-config \
region=ru-msk,s3ForcePathStyle="true",s3Url=https://hb.ru-msk.vkcs.cloud \
--uploader-type restic \
--use-node-agentУстановка, как правило, занимает менее минуты.
Далее также патчим Velero.
m.kartsev@m-kartsev ~/Jobs/vk/velero_test
$ kubectl patch deployment velero -n velero —patch-file velero-patch-aws.yaml
deployment.apps/velero patched
m.kartsev@m-kartsev ~/Jobs/vk/velero_test
$ kubectl patch daemonsets node-agent -n velero --patch-file velero-patch-daemonsets.yml
daemonset.apps/node-agent patchedПримечание: в VK Cloud ограничения на под устанавливаются автоматически, поэтому шаг с патчингом необязательный. Но дополнительная страховка никогда не бывает лишней. Особенно если кластер большой и мест, где может произойти «утечка» по ресурсам, много.
Патчинг storage class
Следующим этапом нужно пропатчить Storage-классы, которые в AWS и VK Cloud различаются. А именно, надо применить патчер, который поменяет Storage-классы с именем gp2.
m.kartsev@m-kartsev ~/Jobs/vk/velero_test
$ cat newstorage.yml
apiVersion: v1
kind: ConfigMap
metadata:
name: change-storage-class-config
namespace: velero
labels:
velero.io/plugi n-config: ""
velero.io/change-storage-class: RestoreltemAction
data:
gp2: csi-ceph-hdd-gzlЧтобы узнать значение, на которое нужно заменить текущие данные, переходим в Личный кабинет VK Cloud. Открываем раздел «Контейнеры» и подраздел «Кластеры Kubernetes». Находим кластер demo-vkcloud и переходим в него.
Открываем пункт «Ресурсы кластера».
Во вкладке с ресурсами выбираем «Хранилище». После этого станет доступен перечень всех доступных в VK Cloud storage-классов.
Для демонстрации выбираем класс csi-ceph-hdd-gz1.
m.kartsev@m-kartsev ~/Jobs/vk/velero_test
$ cat newstorage.yml
apiVersion: v1
kind: ConfigMap
metadata:
name: change-storage-class-config
namespace: velero
labels:
velero.io/plugi n-config: ""
velero.io/change-storage-class: RestoreltemAction
data:
gp2: csi-ceph-hdd-gzlДалее передаем это значение класса в команде и применяем патч.
mkartsev@m-kartsev ~/Jobs/vk/velero_test
$ kubectl apply -f newstorage.yml
configmap/change-storage-class-config createdВосстановление резервной копии
Выполняем команду backup get, чтобы проверить доступность созданной ранее резервной копии.
После проверки выполняем команду восстановления из бэкапа.
Примечание: серверная часть Velero, установленного как в AWS, так и в VK Cloud, использует единое объектное хранилище S3, развернутое в VK Cloud. Поэтому бэкап доступен обеим инсталляциям из «единой точки» без необходимости выстраивания сложной логики обращения к копии.
Дожидаемся сообщения о восстановлении резервной копии.
Чтобы проверить успешность миграции, переходим в Личный кабинет VK Cloud. Заходим в раздел «Контейнеры» и подраздел «Кластеры Kubernetes». Находим кластер demo-vkcloud и переходим в него. Открываем пункт «Ресурсы кластера». Выбираем пространство demo-vkcloud.
Видим, что доступен под Moodle в статусе running — то есть успешно смигрировало и приложение.
Далее остается поменять конфиг приложения — изменить в нем путь к базе данных, если она параллельно также мигрирует на новую платформу.
Примечание: подробный гайд по миграции из AWS в VK Cloud баз данных и S3-хранилищ мы описали в предыдущей статье серии.
Проверка приложения
На последнем этапе миграции важно сделать приложение доступным к работе. Для этого также нужно небольшое обновление данных, а именно — изменение домена.
Выполняем команду dig moodle.demo-vkcloud.ru. и находим домен.
Сейчас он ведет в облако AWS.
Чтобы переключиться на VK Cloud, заходим в Личный кабинет облака. Здесь переходим в раздел «Контейнеры» и подраздел «Кластеры Kubernetes». Находим кластер demo-vkcloud и открываем его. Далее переходим во вкладку «Ресурсы кластера» и выбираем «Сеть».
Копируем плавающий IP-адрес, присвоенный в VK Cloud сервису Moodle.
Далее переходим в настройки DNS вашего домена.
Примечание: В нашем случае мы использовали DNS VK Cloud, поэтому в примере будем показывать именно его. Подробнее о DNS VK Cloud и обо всех особенностях работы с ним (создании и удалении зон, квотах и других аспектах) можно узнать в официальной документации.
Итак, переходим в личный кабинет VK Cloud. Заходим в раздел DNS и подраздел «DNS-зоны». Находим домен demo-vkcloud.ru.
Открываем его. Находим А-запись для адреса moodle.demo-vkcloud.ru.
Вызываем контекстное меню для записи и выбираем «Редактировать».
Меняем IP-адрес на новое значение. Нажимаем «Сохранить изменения».
После завершения TTL приложение станет доступным уже по новому домену с новым IP-адресом.
Примечание: Подробнее о работе с DNS в облаке VK Cloud можно прочитать в документации.
Для проверки переходим на страницу приложения.
Логинимся и попадаем в полностью доступное приложение, в котором есть все исходные файлы.
Отличие лишь в том, что запущенное приложение развернуто уже на серверах и в DNS-зоне VK Cloud.
После этого миграцию кластера Kubernetes можно считать успешно выполненной.
Что в итоге
Описанный нами алгоритм наглядно демонстрирует, что Kubernetes-кластер можно быстро и довольно легко перенести из облака в облако. Причем для этого не нужен большой опыт, сложный стек и огромные ресурсы — достаточно понимания принципа работы k8s и облачных платформ. При этом, безусловно, определяющую роль играет не столько процесс миграции, сколько подготовка к ней — от оценки возможности переноса до подготовки ИТ-инфраструктуры на целевой платформе.
Своей серией статей мы продемонстрировали, что миграция в облако — это не страшно. В большинстве случаев подход одинаковый даже для разных компонентов, а успех всего процесса зависит от подготовки и четкого следования рекомендациям — в таком случае довольно легко обходятся даже ограничения vendor-lock.
VK Cloud предлагает российским компаниям помощь в переходе на безопасную облачную платформу отечественного провайдера. Поможет с этим команда Professional Services — они проведут аудит инфраструктуры, подскажут решение и мигрируют существующую инфраструктуру в VK Cloud.