Migrar para o AKS (Serviço de Kubernetes do Azure)

Artigo
11/02/2024

Para ajudar você a planejar e executar uma migração bem-sucedida para o AKS, este guia fornece detalhes sobre a configuração atual de AKS recomendada. Embora este artigo não cubra todos os cenários, ele contém links para informações mais detalhadas para o planejamento de uma migração bem-sucedida.

Neste artigo, resumimos detalhes de migração para:

Conteinerização de aplicativos por meio de Migrações para Azure
AKS com o Azure Load Balancer (Standard) e Conjuntos de Dimensionamento de Máquinas Virtuais
Serviços do Azure anexados existentes
Garantir cotas válidas
Alta disponibilidade e continuidade dos negócios
Considerações para aplicativos sem estado
Considerações para aplicativos com estado
Implantação da sua configuração de cluster

Observação

Dependendo do seu cenário, as seguintes ferramentas de código aberto podem ajudar na sua migração:

Velero (requer Kubernetes 1.7+)
Extensão da CLI do Azure Kube

Antes de começar

Certifique-se de que sua versão de destino do Kubernetes esteja dentro da janela suportada pelo AKS. As versões mais antigas podem não estar dentro do intervalo suportado e exigem uma atualização de versão com suporte para o AKS. Para mais informações, confira Versões do Kubernetes compatíveis com o AKS.
Se você estiver migrando para uma versão mais recente do Kubernetes, consulte a política de suporte de distorção de versão e a versão do Kubernetes.

Uma prática importante que você deve incluir como parte do processo de migração é lembrar-se de seguir os padrões de teste e implantação comumente usados. Testar seu aplicativo antes da implantação é uma etapa importante para garantir a qualidade, funcionalidade e compatibilidade com o ambiente de destino. Isso pode ajudar a identificar e corrigir erros, bugs ou problemas que possam afetar o desempenho, a segurança ou a usabilidade do aplicativo ou da infraestrutura subjacente.

Migrar seus aplicativos para o AKS usando as Migrações para Azure

As Migrações para Azure oferecem uma plataforma unificada para avaliar e migrar para o Azure os servidores, a infraestrutura, os aplicativos e os dados locais. No AKS, você pode usar as Migrações para Azure para realizar as seguintes tarefas:

AKS com Conjuntos de Dimensionamento de Máquinas Virtuais e Standard Load Balancer

O AKS é um serviço gerenciado que oferece recursos exclusivos com menor sobrecarga de gerenciamento. Como o AKS é um serviço gerenciado, você deve selecionar entre um conjunto de regiões suportadas pelo AKS. Talvez seja necessário modificar seus aplicativos existentes para mantê-los íntegros no plano de controle do AKS durante a transição do cluster atual para o AKS.

Recomendamos o uso de clusters do AKS com suporte dos Conjuntos de Dimensionamento de Máquinas Virtuais e do Load Balancer (Standard) para garantir que você obtenha os seguintes recursos:

Vários pools de nós,
Zonas de disponibilidade,
Intervalos de IP autorizados,
Dimensionamento automático do cluster,
Azure Policy para AKS e
Outros recursos novos à medida que forem lançados.

Os clusters do AKS com suporte dos conjuntos de disponibilidade de (VM) máquina virtual não têm suporte para muitos desses recursos.

Crie um cluster do AKS com o Load Balancer (Standard) e os Conjuntos de Dimensionamento de Máquinas Virtuais

CLI do Azure
Terraform

O exemplo a seguir cria um cluster do AKS com um só pool de nós com suporte de um Conjunto de Dimensionamento de Máquinas Virtuais. Ele habilita o dimensionamento automático do cluster no pool de nós do cluster e define um mínimo de um e um máximo de três nós.

Crie um grupo de recursos usando o comando az group create.

az group create --name myResourceGroup --location eastus

Crie um cluster do AKS usando o comando 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

O código a seguir cria um grupo de recursos e um cluster do Kubernetes no Azure, com dimensionamento automático habilitado e configurações de rede específicas, usando o Terraform.

Observação

O código de exemplo deste artigo está localizado no repositório do GitHub do Azure Terraform. Você pode exibir o arquivo de log que contém os resultados do teste das versões atuais e anteriores do Terraform.

Veja mais artigos e exemplos de código mostrando como usar o Terraform para gerenciar recursos do Azure

Crie um diretório no qual testar e executar o código de exemplo do Terraform e faça dele o diretório atual.

Crie um arquivo chamado main.tf, depois insira o código a seguir:

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"
  }
}

Crie um arquivo chamado outputs.tf, depois insira o código a seguir:

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

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

Crie um arquivo chamado providers.tf, depois insira o código a seguir:

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

provider "azurerm" {
  features {}
}

Crie um arquivo chamado variables.tf, depois insira o código a seguir:

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."
}

Inicialize o Terraform.

Execute terraform init para inicializar a implantação do Terraform. Esse comando baixa o provedor do Azure necessário para gerenciar seus recursos do Azure.
```
terraform init -upgrade
```
Pontos principais:
- O parâmetro -upgrade atualiza os plug-ins do provedor necessários para a versão mais recente que esteja em conformidade com as restrições de versão da configuração.
Crie um plano de execução Terraform.

Execute o comando terraform plan para criar um plano de execução.
```
terraform plan -out main.tfplan
```
Pontos principais:
- O comando terraform plan cria um plano de execução, mas não o executa. Em vez disso, ele determina quais ações são necessárias para criar a configuração especificada em seus arquivos de configuração. Esse padrão permite que você verifique se o plano de execução corresponde às suas expectativas antes de fazer qualquer alteração nos recursos reais.
- O parâmetro opcional -out permite que você especifique um arquivo de saída para o plano. Usar o parâmetro -out garante que o plano que você examinou seja exatamente o que é aplicado.
Aplicar um plano de execução do Terraform.

Execute terraform apply para aplicar o plano de execução à sua infraestrutura de nuvem.
```
terraform apply main.tfplan
```
Pontos principais:
- O exemplo de comando do terraform apply pressupõe que você executou o terraform plan -out main.tfplan anteriormente.
- Se você especificou um nome de arquivo diferente para o parâmetro -out, use esse mesmo nome de arquivo na chamada para terraform apply.
- Se você não usou o parâmetro -out, chame terraform apply sem nenhum parâmetro.

Serviços do Azure anexados existentes

Ao migrar clusters, você pode ter anexado serviços externos do Azure. Embora os seguintes serviços não exijam a recriação de recursos, eles exigem a atualização de conexões dos clusters mais antigos para os novos para manter a funcionalidade:

Registro de Contêiner do Azure
Azure Log Analytics
Azure Application Insights
Gerenciador de Tráfego do Azure
Conta do Armazenamento do Azure
Bancos de dados externos

Garantir cotas válidas

Como outras VMs estão implantadas na sua assinatura durante a migração, você deve verificar se suas cotas e limites são suficientes para esses recursos. Se necessário, solicite um aumento de cota de vCPU.

Talvez seja necessário solicitar um aumento nas cotas de rede para garantir que você não esgote os IPs. Para obter mais informações, consulte intervalos de rede e IP para o AKS.

Para saber mais, confira os limites de assinatura e serviço do Azure. Para verificar suas cotas atuais, no portal do Azure, acesse a folha de assinaturas, selecione sua assinatura e, em seguida, selecione Uso + cotas.

Alta disponibilidade e continuidade dos negócios

Se o aplicativo não conseguir lidar com o tempo de inatividade, você precisará seguir as melhores práticas para cenários de migração de alta disponibilidade. Leia mais sobre as Melhores práticas para o planejamento de continuidade de negócios complexos, recuperação de desastre e maximização do tempo de atividade no AKS.

Para aplicativos complexos, você normalmente migra ao longo do tempo, em vez de tudo de uma vez, o que significa que os ambientes antigos e novos podem precisar se comunicar pela rede. Aplicativos que anteriormente usavam os serviços ClusterIP para se comunicar podem precisar ser expostos como o tipo LoadBalancer e protegidos adequadamente.

Para concluir a migração, você deseja apontar os clientes para os novos serviços executados no AKS. Recomendamos que você redirecione o tráfego atualizando o DNS para apontar para o balanceador de carga na frente do seu cluster do AKS.

O Gerenciador de Tráfego do Azure pode direcionar os clientes para o cluster de Kubernetes e a instância do aplicativo desejados. O Gerenciador de Tráfego é um balanceador de carga de tráfego com base em DNS que pode distribuir o tráfego de rede entre regiões. Para obter melhor desempenho e redundância, direcione todo o tráfego do aplicativo por meio do Gerenciador de Tráfego antes que ele vá para o cluster do AKS.

Em uma implantação de vários clusters, os clientes devem se conectar a um nome DNS do Gerenciador de Tráfego que aponta para os serviços em cada cluster do AKS. Defina esses serviços usando os pontos de extremidade do Gerenciador de Tráfego. Cada ponto de extremidade é o IP do balanceador de carga do serviço. Usar essa configuração para direcionar o tráfego de rede do ponto de extremidade do Gerenciador de Tráfego em uma região para o ponto de extremidade em uma região diferente.

AKS com o Gerenciador de Tráfego

O Azure Front Door é outra opção para rotear o tráfego para os clusters do AKS. Com o Azure Front Door, você pode definir, gerenciar e monitorar o roteamento global do tráfego da Web fazendo uma otimização para ter o melhor desempenho e o failover global instantâneo para alta disponibilidade.

Considerações para aplicativos sem estado

A migração de aplicativos sem estado envolve as seguintes etapas:

Aplique suas definições de recurso (YAML ou Helm) ao novo cluster.
Verifique se tudo funciona conforme o esperado.
Redirecione o tráfego para ativar o novo cluster.

Considerações para aplicativos com estado

Planeje cuidadosamente a migração de aplicativos com estado para evitar perda de dados ou tempo de inatividade inesperado.

Se você usar os Arquivos do Azure, poderá montar o compartilhamento de arquivos como um volume no novo cluster. Consulte Montar Arquivos do Azure estáticos como um volume.
Se você usar o Managed Disks do Azure, só poderá montar o disco se não estiver conectado a nenhuma VM. Consulte Montar discos estáticos do Azure como um volume.
Se nenhuma dessas abordagens funcionar, você poderá usar as opções de backup e restauração. Consulte Velero no Azure.

Arquivos do Azure

Ao contrário dos discos, os Arquivos do Azure podem ser montados em vários hosts simultaneamente. No cluster do AKS, o Azure e o Kubernetes não impedem a criação de um pod que o cluster do AKS ainda use. Para evitar perda de dados e comportamentos inesperados, certifique-se de que os clusters não gravem simultaneamente nos mesmos arquivos.

Se o seu aplicativo pode hospedar várias réplicas que apontam para o mesmo compartilhamento de arquivos, siga as etapas de migração sem monitoração de estado e implante suas definições YAML no novo cluster.

Caso contrário, uma possível abordagem de migração envolve as seguintes etapas:

Valide se o aplicativo está funcionando corretamente.
Aponte seu tráfego ao vivo para o novo cluster AKS.
Desconecte o cluster antigo.

Se você quiser começar com um compartilhamento vazio e fazer uma cópia dos dados de origem, você poderá usar o comando az storage file copy para migrar seus dados.

Migrar volumes persistentes

Se você estiver migrando volumes persistentes existentes para o AKS, em geral, siga estas etapas:

Desative as gravações no aplicativo.
- Essa etapa é opcional e requer tempo de inatividade.
Tire instantâneos dos discos.
Crie novos discos gerenciados a partir dos instantâneos.
Crie volumes persistentes no AKS.
Atualizar as especificações de pod para usar volumes existentes em vez de PersistentVolumeClaims (provisionamento estático).
Implante o aplicativo no AKS.
Valide se o aplicativo está funcionando corretamente.
Aponte seu tráfego ao vivo para o novo cluster AKS.

Importante

Se você optar por não interromper as gravações, precisará replicar os dados para a nova implantação. Caso contrário, você perderá os dados que foram gravados depois de tirar os instantâneos do disco.

As seguintes ferramentas de código aberto podem ajudar você a criar discos gerenciados e migrar volumes entre os clusters do Kubernetes:

A extensão Copiar Disco da CLI do Azure copia e converte os discos entre os grupos de recursos e regiões do Azure.
A extensão da CLI Azure Kube enumera os volumes Kubernetes do ACS e os migra para um cluster do AKS.

Implantação da sua configuração de cluster

Recomendamos que você use seu pipeline existente de integração contínua e entrega contínua para implantar uma configuração válida conhecida no AKS. Você pode usar o Azure Pipelines para compilar e implantar seus aplicativos no AKS. Clone suas tarefas de implantação existentes e garanta kubeconfig pontos para o novo cluster do AKS.

Se isso não for possível, exporte as definições de recursos do cluster do Kubernetes existente e aplique-as ao AKS. É possível usar kubectl para exportar objetos. Por exemplo:

kubectl get deployment -o yaml > deployments.yaml

Examine a saída e remova todos os campos de dados ativos desnecessários.

Mover recursos existentes para outra região

O ideal é mover o cluster do AKS para uma região diferente com suporte do AKS. Recomendamos que você crie um novo cluster na outra região e, em seguida, implante seus recursos e aplicativos no seu novo cluster.

Se você tiver algum serviço em execução no seu cluster do AKS, será necessário instalar e configurar esses serviços no seu cluster na nova região.

Neste artigo, resumimos os detalhes de migração para:

Conteinerização de aplicativos por meio de Migrações para Azure
AKS com o Load Balancer (Standard) e Conjuntos de Dimensionamento de Máquinas Virtuais
Serviços do Azure anexados existentes
Como garantir cotas válidas
Alta disponibilidade e continuidade dos negócios
Considerações para aplicativos sem estado
Considerações para aplicativos com estado
Como implantar sua configuração de cluster

Compartilhar via