Миграция в службу Azure Kubernetes (AKS)

Статья
10/31/2024

Чтобы помочь вам спланировать и успешно выполнить миграцию в Службу Azure Kubernetes (AKS), в этом разделе приводятся подробные сведения о текущей рекомендуемой конфигурации AKS. Хотя в этой статье не рассматриваются все сценарии, она содержит ссылки на более подробные сведения о планировании успешной миграции.

В этой статье мы обобщаем сведения о миграции для следующих сведений:

Контейнеризация приложений с помощью службы "Миграция Azure"
AKS с Azure Load Balancer (цен. категория "Стандартный") и Масштабируемые наборы виртуальных машин
Существующие подключенные службы Azure
Обеспечение допустимых квот
Высокий уровень доступности и непрерывность бизнес-процессов
Соображения по приложениям без отслеживания состояния
Соображения по приложениям с отслеживанием состояния
Развертывание конфигурации кластера

Примечание.

В зависимости от вашего сценария, следующие средства с открытым кодом могут помочь в миграции:

Velero (требуется Kubernetes 1.7+)
Расширение интерфейса командной строки Azure Kube

Подготовка к работе

Убедитесь, что целевая версия Kubernetes находится в поддерживаемом окне ДЛЯ AKS. Старые версии могут не находиться в поддерживаемом диапазоне и требовать обновления версии для поддержки AKS. Дополнительные сведения см. в статье Поддерживаемые версии Kubernetes в AKS.
Если вы переносите новую версию Kubernetes, ознакомьтесь с политикой поддержки Kubernetes и версии.

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

Используйте Миграцию Azure для миграции ваших приложений в AKS

Служба "Миграция Azure" является единой платформой для оценки и миграции серверов, инфраструктуры, приложений и данных из локальной среды в Azure. В случае AKS можно использовать Миграцию Azure для следующих задач:

AKS с подсистемой балансировки нагрузки ценовой категории "Стандартный" и Масштабируемые наборы виртуальных машин

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

Мы рекомендуем использовать кластеры AKS, поддерживаемые Масштабируемые наборы виртуальных машин и Load Balancer (стандартный), чтобы обеспечить получение следующих функций:

использование нескольких пулов узлов;
Зоны доступности,
разрешенные диапазоны IP-адресов;
Автомасштабирование кластера,
Политика Azure для AKS;
Другие новые функции по мере их выпуска.

Кластеры AKS, поддерживаемые группами доступности виртуальных машин, не поддерживают многие из этих функций.

Создание кластера AKS с load Balancer (стандартный) и Масштабируемые наборы виртуальных машин

Azure CLI
Terraform

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

Создайте группу ресурсов с помощью az group create команды.
```
az group create --name myResourceGroup --location eastus
```

Создайте кластер AKS с помощью az aks create команды.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 1 \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --enable-cluster-autoscaler \
    --min-count 1 \
    --max-count 3 \
    --generate-ssh-keys

Следующий код создает группу ресурсов и кластер Kubernetes в Azure с поддержкой автоматического масштабирования и определенными параметрами сети с помощью Terraform.

Примечание.

Пример кода для этой статьи находится в репозитории Azure Terraform GitHub. Вы можете просмотреть файл журнала, содержащий результаты теста из текущих и предыдущих версий Terraform.

См. другие статьи и примеры кода, в которых показано, как использовать Terraform для управления ресурсами Azure.

Создайте каталог, в котором необходимо протестировать и запустить пример кода Terraform и сделать его текущим каталогом.

Создайте файл с именем main.tfи вставьте следующий код:

resource "random_pet" "rg_name" {
  prefix = var.resource_group_name_prefix
}

resource "azurerm_resource_group" "rg" {
  location = var.resource_group_location
  name     = random_pet.rg_name.id
}

resource "random_string" "aks_cluster_name" {
  length  = 12
  special = false
}

resource "azurerm_kubernetes_cluster" "aks_cluster" {
  name                = random_string.aks_cluster_name.result
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  dns_prefix          = "myakscluster"

  default_node_pool {
    type                = "VirtualMachineScaleSets"
    name                = "default"
    node_count          = 1
    max_count           = 3
    min_count           = 1
    vm_size             = "Standard_DS2_v2"
    enable_auto_scaling = true
    upgrade_settings {
      drain_timeout_in_minutes      = 90
      max_surge                     = "10%"
      node_soak_duration_in_minutes = 0
    }
  }

  network_profile {
    network_plugin    = "azure"
    load_balancer_sku = "standard"
  }

  identity {
    type = "SystemAssigned"
  }

  tags = {
    Environment = "Production"
  }
}

Создайте файл с именем outputs.tfи вставьте следующий код:

output "resource_group_name" {
  value = azurerm_resource_group.rg.name
}

output "aks_cluster_name" {
  value = azurerm_kubernetes_cluster.aks_cluster.name
}

Создайте файл с именем providers.tfи вставьте следующий код:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~>3.0"
    }
    random = {
      source  = "hashicorp/random"
      version = "~>3.0"
    }
  }
}

provider "azurerm" {
  features {}
}

Создайте файл с именем variables.tfи вставьте следующий код:

variable "resource_group_location" {
  type        = string
  default     = "eastus"
  description = "Location of the resource group."
}

variable "resource_group_name_prefix" {
  type        = string
  default     = "rg"
  description = "Prefix of the resource group name that's combined with a random ID so name is unique in your Azure subscription."
}

Инициализируйте Terraform.

Запустите terraform init, чтобы инициализировать развертывание Terraform. Эта команда скачивает поставщик Azure, необходимый для управления ресурсами Azure.
```
terraform init -upgrade
```
Основные моменты:
- Параметр -upgrade обновляет необходимые подключаемые модули поставщика до последней версии, которая соответствует ограничениям версии конфигурации.
Создание плана выполнения Terraform.

Чтобы создать план выполнения, выполните terraform plan.
```
terraform plan -out main.tfplan
```
Основные моменты:
- Команда terraform plan создает план выполнения, но не выполняет его. Вместо этого она определяет, какие действия необходимы для создания конфигурации, заданной в файлах конфигурации. Этот шаблон позволяет проверить, соответствует ли план выполнения вашим ожиданиям, прежде чем вы начнете вносить изменения в фактические ресурсы.
- Необязательный параметр -out позволяет указать выходной файл для плана. Использование параметра -out гарантирует, что проверяемый план полностью соответствует применяемому.
Примените план выполнения Terraform.

Выполните terraform apply, чтобы применить план выполнения к вашей облачной инфраструктуре.
```
terraform apply main.tfplan
```
Основные моменты:
- В примере terraform apply команды предполагается, что вы ранее выполнили.terraform plan -out main.tfplan
- Если для параметра -out указано другое имя файла, используйте то же имя в вызове к terraform apply.
- Если вы не использовали параметр -out, вызовите terraform apply без параметров.

Существующие подключенные службы Azure

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

Реестр контейнеров Azure
Azure Log Analytics
Azure Application Insights
Диспетчер трафика Azure
Учетная запись хранения Azure
Внешние базы данных

Обеспечение допустимых квот

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

Возможно, потребуется запросить увеличение квот сети, чтобы убедиться, что вы не исчерпаете IP-адреса. Дополнительные сведения см. в разделе Использование сети kubenet с пользовательскими диапазонами IP-адресов в Службе Azure Kubernetes (AKS).

Дополнительные сведения см. в статье Подписка Azure и ограничения службы. Чтобы проверить текущие квоты, на портале Azure перейдите к колонке подписок, выберите свою подписку, а затем — Использование + квоты.

Высокий уровень доступности и непрерывность бизнес-процессов

Если приложение не может обрабатывать простои, необходимо следовать рекомендациям по сценариям миграции с высоким уровнем доступности. Узнайте больше о рекомендациях по комплексному планированию непрерывности бизнес-процессов, аварийному восстановлению и обеспечению максимального времени работы в Службе Azure Kubernetes (AKS).

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

Чтобы завершить миграцию, необходимо указать клиентам новые службы, которые выполняются в AKS. Мы рекомендуем перенаправить трафик, обновив DNS, чтобы указать подсистему балансировки нагрузки, сидящую перед кластером AKS.

Диспетчер трафика Azure может направлять клиентов в нужный кластер Kubernetes и экземпляр приложения. Диспетчер трафика — это подсистема балансировки нагрузки на основе DNS, которая может распределять сетевой трафик между регионами. Чтобы обеспечить оптимальную производительность и избыточность, направляйте весь трафик приложений через диспетчер трафика перед передачей в кластер AKS.

В развертывании с несколькими кластерами клиентам следует подключаться по DNS-имени диспетчера трафика, которое приведет их к службам в каждом кластере AKS. Эти службы определяются через конечные точки диспетчера трафика. Каждая конечная точка имеет IP-адрес службы подсистемы балансировки нагрузки. Такая конфигурация позволяет направить трафик из конечной точки диспетчера трафика в одном регионе в конечную точку в другом регионе.

AKS с Диспетчером трафика

Azure Front Door — это еще один вариант маршрутизации трафика для кластеров AKS. С помощью Azure Front Door вы можете определить, управлять и отслеживать глобальную маршрутизацию для веб-трафика, оптимизируя для повышения производительности и мгновенной глобальной отработки отказа для обеспечения высокой доступности.

Соображения по приложениям без отслеживания состояния

Миграция приложений без отслеживания состояния включает следующие действия.

Примените определения ресурсов (в формате YAML или Helm) к новому кластеру.
Убедитесь, что все работает правильно.
Перенаправьте трафик для активации нового кластера.

Соображения по приложениям с отслеживанием состояния

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

Если вы используете Файлы Azure, вы можете подключить общую папку как том в новом кластере. Ознакомьтесь с разделом Подключение статических файлов Azure в качестве тома.
Если вы используете Управляемые диски Azure, то вы можете подключить диск только в том случае, если он не подключен к какой-либо виртуальной машине. Ознакомьтесь с разделом Подключение статического диска Azure в качестве тома.
Если ни один из этих способов не подошел, можно использовать варианты резервного копирования и восстановления. Ознакомьтесь с разделом Velero в Azure.

Файлы Azure

В отличие от дисков, файлы Azure можно одновременно подключить к нескольким узлам. В кластере AKS службы Azure и Kubernetes не препятствуют созданию контейнера pod, который по-прежнему используется кластером ACS. Чтобы предотвратить потерю данных и непредвиденное поведение, убедитесь, что кластеры одновременно не записываются в одни и те же файлы.

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

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

Проверьте, правильно ли работает приложение.
Направьте реальный трафик в новый кластер AKS.
Отключите старый кластер.

Если вы хотите начать с пустой общей папки и сделать копию исходных данных, можно использовать az storage file copy команду для переноса данных.

Миграция постоянных томов

Если вы переносите существующие постоянные тома в AKS, обычно выполните следующие действия:

Заморозить запись в приложение.
- Этот шаг является необязательным и требует простоя.
Создать моментальные снимки дисков.
Создать новые управляемые диски из моментальных снимков.
Создать постоянные тома в службе AKS.
Обновить спецификации Pod для использования существующих томов вместо PersistentVolumeClaims (статической подготовки).
Развернуть приложение в AKS.
Проверьте, правильно ли работает приложение.
Направьте реальный трафик в новый кластер AKS.

Внимание

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

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

Расширение Azure CLI для копирования дисков копирует и конвертирует диски между группами ресурсов и областями Azure.
Расширение Azure Kube CLI: нумерация томов ACS Kubernetes и их перенос в кластер AKS.

Развертывание конфигурации кластера

Мы рекомендуем использовать существующий конвейер непрерывной интеграции и непрерывной доставки для развертывания известной конфигурации в AKS. Azure Pipelines можно использовать для создания и развертывания приложений в AKS. Клонируйте существующие задачи развертывания и убедитесь, что kubeconfig он указывает на новый кластер AKS.

Если это невозможно, экспортируйте определения ресурсов из существующего кластера Kubernetes и примените их к AKS. Для экспорта объектов можно использовать kubectl. Например:

kubectl get deployment -o yaml > deployments.yaml

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

Перемещение существующих ресурсов в другой регион

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

Если у вас есть службы, работающие в кластере AKS, необходимо установить и настроить эти службы в кластере в новом регионе.

В этой статье приводится сводная информация о миграции:

Контейнеризация приложений с помощью службы "Миграция Azure"
AKS с Load Balancer (стандартный) и Масштабируемые наборы виртуальных машин
Существующие подключенные службы Azure
Обеспечение допустимой квоты
Высокий уровень доступности и непрерывность бизнес-процессов
Соображения по приложениям без отслеживания состояния
Соображения по приложениям с отслеживанием состояния
Развертывание конфигурации кластера

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