Поделиться через

Миграция из Amazon EKS в Служба Azure Kubernetes (AKS)

  • Статья

В этой статье приведены стратегии миграции типичных рабочих нагрузок без отслеживания состояния из Amazon EKS в Служба Azure Kubernetes (AKS).

Рекомендации

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

  • Стратегии развертывания. Выбор между GitOps и традиционными методами непрерывной интеграции и непрерывного развертывания (CI/CD) значительно влияет на подход к развертыванию. GitOps определяет декларативную инфраструктуру, управляемую с помощью управляемых версией репозиториев, в то время как DevOps CI/CD фокусируется на автоматизированных рабочих процессах доставки приложений.

  • Артефакты развертывания. Выбор артефактов развертывания играет важную роль в определении структуры развертывания. Файлы YAML, файлы манифеста, диаграммы Helm и конфигурации Kustomize представляют различные подходы к указанию и настройке параметров развертывания, каждый из которых имеет свои преимущества и варианты использования.

  • Проверка подлинности рабочей нагрузки и авторизация. В зависимости от настройки методы проверки подлинности и авторизации могут отличаться. Для управления доступом можно использовать роли Управления удостоверениями и доступом Amazon Web Services (IAM), механизмы идентификации рабочей нагрузки или строка подключения.

  • Мониторинг. Реализация решений мониторинга является критически важным аспектом, который может включать различные средства и методологии для обеспечения производительности и работоспособности развернутых рабочих нагрузок. Дополнительные сведения о сравнении мониторинга AKS с EKS см. в разделе "Мониторинг и ведение журнала Kubernetes".

Прежде чем начать миграцию, ознакомьтесь со следующими общими рекомендациями и рекомендациями.

  • Ознакомьтесь с рекомендациями для оператора кластера и разработчика.
  • Определите стратегию мониторинга и оповещения, чтобы убедиться, что приложение выполняется должным образом.
  • Определите требования к безопасности и соответствию требованиям для приложения и среды AKS.
  • Определите политики управления доступом и их применение. Определите все стандарты соответствия, которые должны соответствовать требованиям.
  • Определите план аварийного восстановления и непрерывности бизнес-процессов для среды AKS и приложения.
  • Определите политики и процедуры резервного копирования и восстановления. Определение целевой цели времени восстановления (RTO) и целевой точки восстановления (RPO).
  • Определите все риски или проблемы, которые могут возникнуть во время развертывания.
  • Проверьте функциональность, чтобы убедиться, что приложение работает должным образом перед перенаправлением динамического трафика в новый кластер AKS.

Рекомендации по миграции рабочей нагрузки

В этом разделе рассматриваются некоторые аспекты, которые следует учитывать перед переносом рабочих нагрузок из Amazon EKS в AKS.

Общие сведения о существующей среде Amazon EKS

Анализ существующей среды EKS для понимания текущей архитектуры, ресурсов и конфигураций.

  • Просмотрите конфигурацию EKS: оцените конфигурацию кластера EKS, например типы узлов, количество узлов, версию Kubernetes и политику поддержки и конфигурацию масштабирования.

    Примечание.

    EKS позволяет создавать пользовательские образы AMI для узлов EKS. AKS не позволяет использовать пользовательские образы узлов. Если для развертывания требуется настройка узла, можно применить настройку kubelet и /или DaemonSets для настройки узлов.

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

  • Проверьте зависимости: определите все зависимости от служб AWS, относящихся к EKS.

    Служба AWS Dependency
    Диспетчер секретов AWS Azure Key Vault
    Агент AWS Guard Duty Microsoft Defender для контейнеров
    Агент удостоверений pod EKS Удостоверение рабочей нагрузки идентификатора Microsoft Entra ID
    Драйверы интерфейса хранилища контейнеров (CSI) Amazon Elastic File System (EFS) или Elastic Block Store (EBS) Драйверы CSI AKS

  • Кластер EKS резервного копирования: вы можете использовать средство, отличное от Майкрософт, например Velero , для резервного копирования и переноса ресурсов Kubernetes и постоянных томов.

Подготовка среды Azure AKS

Сетевой интерфейс контейнера (CNI) Amazon — это подключаемый модуль сети по умолчанию, поддерживаемый EKS. Кластер AKS поддерживает несколько сетевых подключаемых модулей и методов для развертывания кластера в виртуальной сети, в том числе:

Чтобы подготовить кластер AKS, выполните следующие действия.

  1. Создайте новый кластер AKS в Azure, настроив требуемые параметры сети в соответствии с вашими требованиями.
  2. Просмотрите манифесты Kubernetes и файлы YAML, используемые в EKS. Проверьте наличие несовместимости версий API Kubernetes или определенных конфигураций EKS, которые AKS не поддерживают.
  3. Убедитесь, что образы Docker и расположение реестра образов контейнеров доступны из кластера AKS. Проверьте сетевое подключение и все необходимые параметры проверки подлинности и авторизации для доступа к изображениям.

Выполнив указанные ниже действия, вы можете успешно создать кластер AKS и обеспечить совместимость манифестов Kubernetes и образов Docker, обеспечивая плавный процесс миграции из EKS в AKS.

Обзор миграции

Миграция из Amazon EKS в AKS включает несколько этапов, таких как:

  • Миграция образов контейнера. Перенос образов контейнеров является важным шагом при переходе из EKS в AKS. Для экспорта и импорта образов можно использовать такие инструменты, как kubectl, Docker или реестры контейнеров.

    1. Экспорт изображений из EKS.
    2. Настройте Реестр контейнеров Azure и подключите его к AKS, если вы еще не сделали этого.
    3. Отправка образов в реестр контейнеров.

    Образы контейнеров также можно импортировать в реестр контейнеров непосредственно из общедоступного или частного репозитория Azure. Дополнительные сведения см. в разделе "Импорт образов контейнеров".

  • Миграция манифеста Kubernetes: AKS использует манифест YAML Kubernetes для определения объектов Kubernetes. Развертывания обычно создаются и управляются с помощью kubectl create или kubectl. Создайте развертывание, определив файл манифеста в формате YAML. Дополнительные сведения см. в этом примере манифеста AKS. Дополнительные сведения о работе файлов YAML в Kubernetes см. в разделе "Развертывания" и манифестах YAML.

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

Рекомендации по миграции рабочей нагрузки без отслеживания состояния

Перенос манифестов Kubernetes включает адаптацию конфигурации для работы в среде Azure, включая следующие действия:

  1. Обновление манифестов: обновите манифесты Kubernetes, чтобы использовать новые расположения образов в реестре контейнеров. Замените ссылки на образы в файлах YAML путем к реестру контейнеров.

    1. Просмотрите существующие файлы манифеста Kubernetes для конфигураций, относящихся к AWS, например роли VPC и IAM.
    2. Просмотрите роли IAM EKS, связанные с узлами, учетными записями служб и другими ресурсами. Сопоставляйте его с эквивалентными ролями управления доступом на основе ролей (RBAC) Azure AKS. Дополнительные сведения см. в разделе "Удостоверение рабочей нагрузки Kubernetes" и доступ.
    3. Измените файлы манифеста, чтобы заменить параметры, относящиеся к AWS, с параметрами azure, такими как заметки.

  2. Применение манифестов к AKS:

    1. Подключитесь к кластеру AKS.
    2. Примените измененные файлы манифеста Kubernetes с помощью kubectl apply -f.

Рекомендации по миграции рабочей нагрузки с отслеживанием состояния

Если приложения используют постоянные тома (PVs) или утверждения постоянных томов (PVCs) для хранения данных, убедитесь, что вы создайте резервную копию этих данных. Вы можете использовать такие средства, как Velero для резервного копирования кластеров, в том числе для PVS и данных PVCs. Дополнительные сведения см. в статье Резервное копирование и восстановление ресурсов кластера Amazon EKS с помощью Velero.

Приложения с отслеживанием состояния обычно имеют постоянные требования к хранилищу данных, что повышает сложность процесса миграции. Сравнение возможностей хранилища Amazon EKS и AKS см. в разделе "Параметры хранилища" для кластера Kubernetes.

Выполните следующие действия, чтобы создать резервную копию постоянных данных:

  1. Настройте Velero в кластере AKS и EKS.
  2. Создайте резервную копию кластера EKS.
  3. Скопируйте резервную копию Velero из контейнера S3 в хранилище BLOB-объектов Azure с помощью команды az copy.
  4. Так как AKS и EKS могут использовать разные storageClassNames для утверждений сохраняемого тома, создайте configMap источник storageClassNames в имя класса, совместимого с AKS. Этот шаг можно игнорировать, если вы используете то же решение хранилища в кластерах EKS и AKS Kubernetes.
  5. Восстановите резервную копию в AKS (с помощью команды восстановления Velero).
  6. Примените необходимые изменения к восстановленным объектам, например ссылки на образы контейнеров в Реестре контейнеров Amazon Elastic (ECR) или доступ к секретам.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

  • Диксит Арора | Старший инженер клиента, ISV DN CoE
  • Кетан Чавда | Старший инженер клиента, ISV DN CoE

Другие участники:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги