Недавно мы рассказывали, что Kubernetes в формате Self-Hosted — не всегда самая лучшая идея. Альтернатива — Managed-решения типа Kubernetes as a Service (KaaS).

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

Но вот сам переход на Managed Kubernetes неизбежно ставит клиентов перед вопросом: как организовать переход с текущего технологического стека правильно, с наименьшими затратами и влиянием на пользователей?

Я Павел Селиванов, ведущий DevOps-инженер платформы Mail.ru Cloud Solutions, которая как раз-таки является провайдером Managed Kubernetes 🙂

В статье расскажу:

  • какие стратегии миграции на Managed Kubernetes существуют,
  • от чего зависит сложность и длительность миграции,
  • из каких этапов она состоит,
  • какие проблемы могут возникнуть в ходе миграции и как с ними справиться.

Виды миграции

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

Возможны несколько сценариев:

  1. Компания не использовала оркестраторы и контейнеры ранее, приложения по большей части монолитные

    Самый сложный старт для миграции. Требует частичного или полного рефакторинга приложений и добавления контейнеризации.

  2. Компания не использовала оркестраторы, но приложения построены на основе микросервисов и контейнеров

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

  3. Компания использовала оркестратор, отличный от Kubernetes: Docker Swarm, Mesos Marathon, Nomad и другие

    Еще один непростой сценарий, который можно считать чуть легче двух предыдущих лишь потому, что у команды уже есть опыт работы и с контейнерами, и с оркестраторами. Однако нужно иметь в виду, что концепции и технологии, лежащие в основе других оркестраторов, могут сильно отличаться от используемых в K8s. Например, Kubernetes не поддерживает двухэтапное планирование (two-stage scheduling), реализованное в Mesos. Эти и другие отличия придется учитывать при переписывании yaml-файлов.

  4. Компания использовала один из дистрибутивов Kubernetes: Rancher, OpenShift и другие

    Хотя этот вариант миграции легче перехода с другого оркестратора, он все еще не самый простой. Несмотря на то, что Rancher, OpenShift и другие подобные инструменты основаны на Kubernetes, между ними и «ванильным» K8s могут быть существенные различия. Например, Deployment config, используемый при развертывании сервисов в OpenShift, отличается от Deployment Kubernetes. Похожая ситуация будет и с другими дистрибутивами.

  5. Компания использовала «ванильный» Kubernetes On-premise или в облаке (и хочет сменить провайдера, например, из финансовых соображений)

    Самый простой сценарий миграции, когда планируется перенос существующего кластера, развернутого либо локально с использованием таких инструментов, как Kops и Kubeadm, либо в облачной инфраструктуре. Как правило, требует незначительной корректировки yaml-файлов и переключения трафика на новые адреса. Ситуация может усложниться, если были использованы некоторые проприетарные сервисы на стороне предыдущего облачного провайдера. Но к самому Kubernetes это, скорее всего, не будет иметь отношения, так как провайдеры стараются поддерживать переносимость своего Managed-решения и его совместимость с Open Source-версией K8s.

Зависимость уровня сложности миграции от текущего технологического стека и степени развития DevOps-культуры в компании

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

Но наличие DevOps-специалистов, имеющих опыт работы с Kubernetes, может внести коррективы в описанное выше распределение мест. Как правило, уровень DevOps-культуры напрямую связан с использованием контейнеризации и оркестровки: в описанных мною сценариях он будет увеличиваться от варианта 1 к варианту 5. Но бывают и исключения. Например, переход с «чистой» контейнеризации (без использования оркестраторов) при достаточном уровне экспертности в K8s может оказаться гораздо проще миграции с других оркестраторов и дистрибутивов Kubernetes.

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

Независимо от того, что является отправной точкой для миграции на Managed Kubernetes, есть общий перечень операций, которые рекомендуется выполнить перед ее началом.

Действия, которые рекомендуется выполнить перед миграцией

Рассмотрим подробнее каждую операцию.

1. Подготовка кода

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

Подготовка кода состоит из следующих шагов:

  1. Частичное или полное преобразование монолитного кода в микросервисы

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

    • Использование локальных хранилищ данных. Чаще всего монолиты хранят данные «под собой», локально. Чтобы данные не терялись, потребуется обучить монолит работать со stateful-хранилищами. Это может быть локальная БД, DBaaS, объектное хранилище или Persistent Volumes самого Kubernetes, построенные на базе блочных либо файловых хранилищ облачного провайдера.
    • Использование локальных кэшей. В качестве кэша монолиты используют чаще всего in-memory-хранилища вида Memcached или Redis, обращаясь к ним локально. При переезде в K8s потребуется развертывание Redis Cluster и взаимодействие с ним именно как с кластером, чего классические монолиты не умеют.
    • Неспособность работать в несколько инстансов. Этому также придется обучить ваше монолитное приложение, причем инстансы должны уметь получать доступ к данным, хранящимся отдельно от монолита.
    • Неспособность корректно обрабатывать перемещение инстансов на новые ноды. В монолитной архитектуре клиентские приложения, даже умеющие работать с несколькими инстансами, обычно способны взаимодействовать только с одним инстансом в рамках текущей сессии. Поэтому каждый переезд инстанса на новую ноду будет сбрасывать сессию. Это противоречит основной концепции K8s, согласно которой для обеспечения балансировки, отказоустойчивости и автовосстановления после сбоев инстансы приложений должны легко перемещаться между нодами. Поэтому монолит необходимо научить обрабатывать подобные переключения либо на балансировщике потребуется реализовать метод Sticky Session, с помощью которого запросы будут распределяться по серверам на основе IP-адресов клиента.

      Чтобы избежать описанных проблем, а также повысить отказоустойчивость и получить более высокую скорость сборки и развертывания, рекомендуется сразу разбивать подобные программы на небольшие слабо связанные сервисы. Конечно, часть монолитов (в первую очередь stateless) может быть перенесена в контейнеры в неизменном виде, но, чтобы воспользоваться всеми преимуществами K8s, в будущем однозначно потребуется их рефакторинг, так как контейнеризация и оркестровка создавались именно для работы с микросервисами.
    • Применение методологии «12 факторов». Она описывает лучшие практики для создания облачных приложений. При миграции в облако важно понимать и применять хотя бы некоторые из этих принципов, например: хранение исходного кода в системе контроля версий, разделение стадий сборки, развертывания и запуска приложения, хранение учетных данных в переменных среды (в Kubernetes это возможно при помощи секретов).
  2. Контейнеризация

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

    • Существуют инструменты для автоматического формирования Docker-файлов. Например, в Docker Enterprise доступно решение для автоматической упаковки приложений .NET в Docker-контейнеры.
    • Еще один важный момент при контейнеризации — определение требований приложений к памяти, диску и процессору. В дальнейшем эти данные пригодятся при запуске контейнеров (с указанием ограничений на используемые ресурсы) и конфигурировании кластера.

2. Создание и настройка кластера

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

  • Количество Master- и Worker-узлов. Для производственных кластеров рекомендуется три Master-узла. Количество Worker-узлов должно позволять разместить все приложения как минимум в двух экземплярах. Чем больше Worker-узлов, тем выше отказоустойчивость приложения.
  • Зона доступности. Если трафик ожидается из определенного географического местоположения, для наилучшей производительности следует выбрать самую близкую зону.
  • Конфигурация виртуальных машин. Следует предварительно оценить требования приложения к памяти и ЦП. Рабочий узел должен иметь достаточно ресурсов для его развертывания и запуска. Также важно установить квоты для используемых ресурсов в спецификациях deployment.yaml (в секции resources). Эти ограничения будут использоваться Kubernetes для выбора рабочего узла, имеющего достаточную емкость для запуска приложения.
  • Автомасштабирование. Если при использовании приложения возможны частые и непредсказуемые скачки трафика, желательно настроить автомасштабирование, благодаря которому в моменты пиковых нагрузок будут автоматически создаваться новые Worker-узлы в кластере. Но при этом важно корректно подобрать границы для автомасштабирования (минимальное и максимальное число узлов) и в обязательном порядке использовать AntiDDos-программы. Иначе DDoS-атаки, воспринимаемые K8s как обычные нагрузки, могут привести к финансовым потерям.
  • Внешний доступ к кластеру. Для организации доступа к кластеру извне следует использовать Ingress Controller, например Nginx. Он позволит определять правила для маршрутизации внешнего трафика.
  • Мониторинг. Желательно уже при добавлении кластера продумать сбор метрик и настройку оповещений на их основе, например, с использованием Prometheus и Grafana. Многие провайдеры предлагают эти инструменты в виде предустановленных сервисов. Также рекомендуется использовать централизованное хранилище логов — например, на основе ELK.
  • Постоянное хранилище данных. Данные, хранимые внутри контейнера, не могут быть переданы другим контейнерам. Кроме этого, при сбое контейнера или его удалении они теряются. Поэтому вместо хранения данных в локальной файловой системе контейнера следует рассмотреть использование постоянных хранилищ на основе Persistent Volumes (PV) в K8s. В качестве персистентного хранилища данных для Docker-контейнеров в составе кластера Kubernetes провайдеры предлагают блочные и файловые (чаще всего NFS) хранилища.
  • RBAC (Role Based Access Control) и политики безопасности. В K8s есть возможность создания сервисных учетных записей и разграничения их доступа к различным ресурсам кластера. Это пригодится, в частности, при настройке доступа к кластеру из конвейера CI/CD — чтобы Runner мог деплоить приложения в Kubernetes.
  • Пространства имен Kubernetes. Важно подумать о том, как правильно организовать ресурсы кластера: можно работать в пространстве имен по умолчанию, но желательно создавать несколько пространств имен с собственными квотами ресурсов.
  • Секреты. Для хранения конфиденциальной информации вида паролей, токенов OAuth и ключей SSH рекомендуется использовать секреты Kubernetes.
  • Число кластеров. Рекомендуется разделять кластеры, предназначенные для разработки/тестирования и для производства. На многих облачных платформах даже доступны шаблоны кластерных конфигураций под различные среды, различающиеся числом Master-узлов и конфигурацией ВМ.

Чаще всего провайдеры предлагают удобную административную панель для добавления кластеров, однако возможен и другой вариант — с применением подхода IaC (Infrastructure as a Code).

Суть IaC состоит в том, что вся инфраструктура декларативно описывается в виде кода. Описание включает топологию сети, перечень необходимых приложению виртуальных машин, их требования к ресурсам, конфигурацию и так далее. Стандартом де-факто для этих задач в последнее время стал Terraform: он поддерживается большинством облачных провайдеров. Его цель — обеспечить возможность быстрого развертывания инфраструктуры, в том числе при смене облачного провайдера. Например, если ранее в компании уже использовался Kubernetes-кластер в On-premise-варианте или в облаке и есть декларативное описание кластера, то все, что потребуется для перехода на другую облачную платформу, — изменить Environment-переменные и немного отформатировать код под конкретный Terraform-провайдер. Это значительно ускорит миграцию кластера.

Конечно, при небольшом количестве виртуальных машин возможна и ручная настройка кластера. И она рекомендуется, если в компании еще нет опыта работы с Kubernetes. Однако в дальнейшем будет не лишним рассмотреть возможность использования IaC, особенно если количество виртуальных машин измеряется десятками и сотнями или в проекте используется сложная сетевая топология.

3. Подготовка yaml-файлов K8s

Этот этап необходим для всех сценариев миграции, но со следующими особенностями:

  • Если ранее не было оркестратора либо использовался оркестратор, отличный от K8s, yaml-файлы необходимо написать с нуля.

    При этом для Docker Swarm доступны инструменты автоматического преобразования из файлов Docker Compose в yaml Kubernetes, например Kompose. Однако его можно рассматривать лишь как вспомогательное средство при миграции большого количества манифестов. Как показывает опыт, преобразованные файлы все равно придется редактировать вручную, чтобы исключить лишние теги и учесть все преимущества Kubernetes, связанные с deployments, labels, tolerations и так далее.

    Переход с других оркестраторов (Nomad, Mesos и так далее) возможен исключительно вручную, так как их манифесты несовместимы с Kubernetes.
  • Если ранее использовалась PaaS-платформа типа Rancher или OpenShift, скорее всего, потребуется частично переписать yaml-файлы под «ванильный» Kubernetes.
  • При переходе с K8s, который был развернут On-premise или в другой облачной платформе, в большинстве случаев yaml-файлы изменять не потребуется, так как провайдеры следят за совместимостью своих Managed-решений с Open Sourсe-версией K8s. Если правки и будут, то косметические.

В Kubernetes практически все основано на yaml-файлах, но для начала достаточно изучить и настроить манифесты для трех основных абстракций: Deployment — для описания жизненного цикла приложения, Service — для организации сетевого доступа и балансировки запросов внутри кластера, Ingress — для организации внешнего доступа к кластеру.

Все настроенные манифесты желательно хранить в общем репозитории наряду с кодом основного приложения, чтобы в будущем автоматически применять их к кластеру при выполнении CI/CD-пайплайнов. По мере увеличения числа yaml-файлов можно разрабатывать собственные Helm-чарты, которые позволят избежать применения каждого файла по отдельности и собрать необходимые для приложения ресурсы в одном месте.

4. Настройка CI/CD

Настройка конвейера автоматической сборки и развертывания приложений рекомендуется для всех сценариев миграции, где он до этого не использовался. Конечно, применять yaml-файлы к Kubernetes-кластеру и развертывать в нем Docker-образы можно и вручную, но с увеличением числа микросервисов и частоты выхода релизов работа без конвейера станет практически невозможна. Поэтому лучше внедрить CI/CD сразу — как в тестовом, так и в промышленном окружении. Для этого необходимо:

  • выбрать инструмент построения CI/CD — например, GitLab;
  • выбрать Docker Registry — реестр, в который будут помещаться Docker-образы приложений, формируемые при сборке. В GitLab есть встроенный Docker Registry;
  • настроить Runner, отвечающий за запуск пайплайнов. Если вы используете Managed GitLab на gitlab.com, то общедоступные раннеры могут быть ограничены по CI-часам. Для установки специфических раннеров существуют Helm-чарты, например GitLab Runner;
  • настроить манифест gitlab-ci.yml, который будет описывать все стадии пайплайна. В качестве таких стадий чаще всего выделяют тестирование кода (test), сборку Docker-образа (build) и развертывание готового образа в кластере K8s (deploy).

В общем случае процесс CI/CD при работе с Kubernetes может выглядеть следующим образом. Когда в репозитории исходного кода фиксируются изменения, запускается новый пайплайн. Выполняется стадия тестирования test (если она описана в пайплайне) и стадия сборки build. В результате сборки формируется готовый к развертыванию Docker-образ с файлами приложения. Этот образ помещается в Docker Registry. На стадии deploy Kubernetes извлекает образ приложения из Docker Registry и развертывает его в кластере.

Обобщенная схема построения CI/CD при работе с Kubernetes

5. Тестирование кластера и составление плана миграции

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

  • Функциональное тестирование — чтобы убедиться, что приложения работают должным образом.
  • Интеграционное тестирование — чтобы проверить взаимодействие со сторонними системами.
  • Нагрузочное тестирование — чтобы понять, как кластер обрабатывает пиковые нагрузки и масштабируется в соответствии с потребностями бизнеса.
  • Аудит безопасности (например, Penetration Test) — чтобы убедиться, что конфигурация кластера не содержит уязвимостей и устойчива к различным типам атак.

При тестировании важно зафиксировать и обработать все острые углы. Необходимо намеренно вызывать различные системные сбои и фиксировать поведение системы. Для тех случаев, где Kubernetes по каким-то причинам не может восстановить работу приложений самостоятельно, следует обязательно добавить оповещения через систему мониторинга.

После успешного завершения тестирования остается составить план перевода пользователей на развернутый в облаке кластер. Желательно выбрать окно с наименьшей нагрузкой на систему, хотя при переключении на уровне DNS время простоя системы будет и так сведено к минимуму. При планировании важно предусмотреть возможность отката: для этой цели рекомендуется использовать шаблон blue-green deployment.

Миграция

После правильно проведенной подготовки сама миграция включает в себя, по сути, лишь применение настроенных yaml-файлов к созданному production-кластеру, проверку его работоспособности и постепенное переключение рабочих нагрузок на новые адреса. Применить манифесты к кластеру можно вручную, но гораздо эффективнее и правильнее использовать настроенный конвейер CI/CD.

Ниже приведены особенности миграции для различных сценариев.

Сценарий Шаги миграции
1 Монолитные приложения без контейнеризации
  • Применить созданные yaml-файлы к производственному кластеру Kubernetes и развернуть приложение, используя CI/CD. Проверить работоспособность.
  • Переключить пользователей на приложение, развернутое в кластере.
2 Микросервисы + контейнеризация
  • Применить созданные yaml-файлы к производственному кластеру Kubernetes и развернуть приложение, используя CI/CD. Проверить работоспособность.
  • Переключить пользователей на приложение, развернутое в кластере.
3 Отличные от K8s оркестраторы: Docker Swarm, Nomad, Mesos Marathon и другие
  • Применить созданные yaml-файлы к производственному кластеру Kubernetes и развернуть приложение, используя CI/CD. Проверить работоспособность.
  • Переключить пользователей на приложение, развернутое в кластере.
4 Платформы, основанные на K8s: OpenShift, Rancher и другие
  • Применить адаптированные под K8s yaml-файлы к производственному кластеру Kubernetes и развернуть приложение, используя CI/CD. Проверить работоспособность.
  • Переключить пользователей на приложение, развернутое в кластере.
5 «Ванильный» K8s, развернутый On-premise или в облаке
  • Выполнить переключение в конвейере CI/CD на новый производственный кластер и развернуть приложение либо воспользоваться ПО Velero для переноса всех ресурсов прежнего кластера в новый. Проверить работоспособность.
  • Переключить пользователей на приложение, развернутое в кластере.

Типичные проблемы и способы их решения

Разумеется, у миграции есть свои подводные камни. Ниже приведен перечень наиболее частых проблем и описаны способы их решения:

  1. Перенос баз данных. Здесь возможны несколько стратегий:
    • оставить БД в локальной инфраструктуре;
    • развернуть БД внутри кластера Kubernetes — для этого придется поэкспериментировать с доступными операторами для запуска БД в Kubernetes;
    • использовать управляемую базу данных как услугу (DBaaS) в облаке. Этот вариант более прост в настройке и предполагает встроенное резервное копирование и масштабирование.

    В общем случае рекомендуется переносить БД в облако, а не оставлять у себя локально — во избежание потери производительности. Чтобы снизить время простоя во время миграции данных, можно предварительно создать реплику БД в облаке и обеспечить ее синхронизацию с основной БД, а по готовности преобразовать ее в master и выполнить переключение. Эту работу необязательно выполнять одновременно с миграцией кластера.

  2. Перенос очередей сообщений. Доступны те же варианты, что и с базами данных: продолжить использование очереди On-premise, запустить ее в Kubernetes-кластере либо использовать управляемый сервис в облаке (Simple Queue Service, SQS). Рекомендация будет той же — перенос в облако для обеспечения максимальной производительности.
  3. Возможные простои в работе приложений при миграции. Для снижения времени простоя при переключении пользователей на новый Kubernetes-кластер рекомендуется использовать подход blue-green deployment. Можно развернуть приложения в новом кластере, не отключая их предыдущие версии, и в случае успеха выполнить перевод трафика на уровне DNS — например, при помощи маршрутизации по весам, доступной в большинстве провайдерских систем управления DNS. Когда весь объем запросов будет переведен на новый кластер, старые версии приложений можно отключить.
  4. Несоответствие версий Kubernetes. Чтобы избежать любых несоответствий в API K8s, необходимо планировать миграцию на ту же версию Kubernetes, которая используется в настоящий момент. Если эта версия уже не поддерживается в целевой облачной платформе, важно выявить и исключить устаревшие API.
  5. Проприетарные сервисы на стороне предыдущего облачного провайдера. При использовании любой облачной платформы крайне важно избегать Vendor lock-in, то есть привязки к сервисам определенного провайдера, отсутствующим у других провайдеров. Применение проприетарных сервисов, возможно, и приносит определенные преимущества, позволяя пользоваться уникальным функционалом, но вместе с тем оно затрудняет быструю смену провайдера в случае необходимости. Если вы оказались в подобной ловушке, перед миграцией потребуется дополнительный рефакторинг приложений — чтобы перейти на ближайшие аналоги сервисов на новой платформе (при условии, что они вновь не окажутся проприетарными) либо исключить их из своего проекта вовсе.
  6. Недостаток экспертности в настройке yaml-файлов и управлении кластером. В этом случае потребуется повышать квалификацию своих специалистов либо обратиться за помощью к экспертам облачного провайдера.

Возможности миграции «под ключ»

Многие облачные платформы готовы помочь в осуществлении миграции на Managed Kubernetes. При переходе на Kubernetes aaS от Mail.ru Cloud Solutions предлагается следующая поддержка:

  • консультации по построению микросервисной архитектуры с использованием Kubernetes;
  • помощь с переносом данных из Docker Swarm, Managed-решений других облачных провайдеров и существующих On-premise кластеров. Можно воспользоваться доступной на платформе интеграцией с Velero или получить консультацию по ручному переписыванию yaml-файлов в случае необходимости;
  • помощь экспертов Mail.ru Group в создании отказоустойчивого и масштабируемого Kubernetes-кластера, включая настройку резервного копирования, балансировки нагрузки, мониторинга и прочего функционала;
  • дальнейшие консультации по работе кластера, включая круглосуточный мониторинг и устранение инцидентов 24/7.

Несколько советов в заключение

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

  • Старайтесь переносить рабочие нагрузки по одной. Разделив архитектуру на несколько небольших развертываемых частей, можно изучить процесс на первой небольшой миграции, а затем применить его к более крупным компонентам.
  • Помните, что миграция не требует единовременного переноса всех важных ресурсов приложения в Kubernetes. Например, web-приложение и сервисы Middleware можно перенести в Kubernetes, а базу данных оставить на первое время прежней. Легче всего начинать миграцию для сервисов без сохранения состояния (stateless).
  • Не пытайтесь задействовать весь функционал Kubernetes с первого раза, особенно если это новая для вас технология. Благодаря популярности и расширяемости K8s создано множество полезных инструментов, интегрированных с ним, включая сервисные сетки (service mesh), операторы Kubernetes и так далее. Но не стоит пробовать все сразу. То, что не является первостепенным для развертывания кластера, лучше рассмотреть уже после успешной миграции.
  • Для миграции не стоит выбирать стратегию «Rip and replace», когда код всех приложений полностью переписывается под облачные технологии. Даже для команд с относительно небольшой ИТ-инфраструктурой степень риска, связанного с обновлением всего стека, очень велика. Лучше придерживаться тактики «Improve and move», когда на момент миграции рефакторинг проводится точечно и только там, где это необходимо — например, в самых громоздких монолитах, контейнеризация которых невозможна без разбиения на микросервисы. Более глобальный рефакторинг, если он нужен, планируется отдельно от миграции.

И не забывайте, что облачные провайдеры всегда готовы помочь с миграцией. С поддержкой их экспертов многих сложностей переезда на Kubernetes aaS удастся избежать.

Оригинал статьи на Наbr.com.