Migrar para Azure Kubernetes Service (AKS)

Para o ajudar a planear e executar uma migração bem-sucedida para Azure Kubernetes Service (AKS), este guia fornece detalhes para a configuração do AKS recomendada atual. Embora este artigo não aborde todos os cenários, contém ligações para informações mais detalhadas para planear uma migração com êxito.

Este documento ajuda a suportar os seguintes cenários:

Ao migrar, certifique-se de que a versão do Kubernetes de destino está dentro da janela suportada para o AKS. As versões mais antigas podem não estar dentro do intervalo suportado e exigirão que uma atualização de versão seja suportada pelo AKS. Para obter mais informações, veja Versões do Kubernetes suportadas pelo AKS.

Se estiver a migrar para uma versão mais recente do Kubernetes, reveja a política de suporte de distorção de versões e versões do Kubernetes.

Várias ferramentas open source podem ajudar na sua migração, consoante o seu cenário:

Neste artigo, vamos resumir os detalhes da migração para:

  • Contentorizar aplicações através do Azure Migrate
  • AKS com Balanceador de Carga Standard e Conjuntos de Dimensionamento de Máquinas Virtuais
  • Serviços do Azure anexados existentes
  • Garantir quotas válidas
  • Elevada Disponibilidade e continuidade do negócio
  • Considerações para aplicações sem estado
  • Considerações para aplicações com estado
  • Implementação da configuração do cluster

Utilizar o Azure Migrate para migrar as suas aplicações para o AKS

O Azure Migrate oferece uma plataforma unificada para avaliar e migrar para servidores, infraestruturas, aplicações e dados no local do Azure. Para o AKS, pode utilizar o Azure Migrate para as seguintes tarefas:

AKS com Balanceador de Carga Standard e Conjuntos de Dimensionamento de Máquinas Virtuais

O AKS é um serviço gerido que oferece capacidades exclusivas com menor sobrecarga de gestão. Uma vez que o AKS é um serviço gerido, tem de selecionar a partir de um conjunto de regiões que o AKS suporta. Poderá ter de modificar as aplicações existentes para as manter em bom estado de funcionamento no plano de controlo gerido pelo AKS durante a transição do cluster existente para o AKS.

Recomendamos a utilização de clusters do AKS apoiados por Conjuntos de Dimensionamento de Máquinas Virtuais e pela Balanceador de Carga Standard do Azure para garantir que obtém funcionalidades como:

Os clusters do AKS apoiados por Conjuntos de Disponibilidade de Máquinas Virtuais não têm suporte para muitas destas funcionalidades.

O exemplo seguinte cria um cluster do AKS com um único conjunto de nós apoiado por um conjunto de dimensionamento de máquinas virtuais (VM). O cluster:

  • Utiliza um balanceador de carga padrão.
  • Ativa o dimensionador automático do cluster no conjunto de nós do cluster.
  • Define um mínimo de 1 e máximo de 3 nós.
# First create a resource group
az group create --name myResourceGroup --location eastus

# Now create the AKS cluster and enable the cluster autoscaler
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

Serviços do Azure anexados existentes

Ao migrar clusters, poderá ter anexado serviços externos do Azure. Embora os seguintes serviços não necessitem de recreação de recursos, precisarão de atualizar as ligações de clusters anteriores para novos para manter a funcionalidade.

  • Registo de Contentores do Azure
  • Log Analytics
  • Application Insights
  • Gestor de Tráfego
  • Conta de Armazenamento
  • Bases de Dados Externas

Garantir quotas válidas

Uma vez que outras VMs serão implementadas na sua subscrição durante a migração, deve verificar se as quotas e os limites são suficientes para estes recursos. Se necessário, peça um aumento da quota de vCPU.

Poderá ter de pedir um aumento das quotas de Rede para garantir que não esgota os IPs. Para obter mais informações, veja networking and IP ranges for AKS (Intervalos de rede e IP do AKS).

Para obter mais informações, veja Subscrição do Azure e limites de serviço. Para verificar as quotas atuais, no portal do Azure, aceda ao painel subscrições, selecione a sua subscrição e, em seguida, selecione Utilização + quotas.

Elevada Disponibilidade e Continuidade do Negócio

Se a sua aplicação não conseguir lidar com o tempo de inatividade, terá de seguir as melhores práticas para cenários de migração de elevada disponibilidade. Leia mais sobre as Melhores práticas para planeamento de continuidade de negócio complexo, recuperação após desastre e maximização do tempo de atividade no Azure Kubernetes Service (AKS).

Para aplicações complexas, normalmente irá migrar ao longo do tempo em vez de todos de uma só vez, o que significa que os ambientes antigos e novos poderão ter de comunicar através da rede. As aplicações que utilizam ClusterIP anteriormente serviços para comunicar podem ter de ser expostas como tipo LoadBalancer e protegidas adequadamente.

Para concluir a migração, deverá apontar os clientes para os novos serviços que estão em execução no AKS. Recomendamos que redirecione o tráfego ao atualizar o DNS para apontar para o Balanceador de Carga em frente ao cluster do AKS.

O Gestor de Tráfego do Azure pode direcionar os clientes para o cluster e instância de aplicação do Kubernetes pretendidos. O Gestor de Tráfego é um balanceador de carga de tráfego baseado em DNS que pode distribuir o tráfego de rede entre regiões. Para obter o melhor desempenho e redundância, direcione todo o tráfego da aplicação através do Gestor de Tráfego antes de aceder ao cluster do AKS.

Numa implementação de vários clusters, os clientes devem ligar-se a um nome DNS do Gestor de Tráfego que aponte para os serviços em cada cluster do AKS. Defina estes serviços com os pontos finais do Gestor de Tráfego. Cada ponto final é o IP do balanceador de carga do serviço. Utilize esta configuração para direcionar o tráfego de rede do ponto final do Gestor de Tráfego numa região para o ponto final numa região diferente.

AKS com Gestor de Tráfego

O Azure Front Door Service é outra opção para encaminhar o tráfego para clusters do AKS. Com o Azure Front Door Service, pode definir, gerir e monitorizar o encaminhamento global para o seu tráfego Web ao otimizar o melhor desempenho e ativação pós-falha global instantânea para elevada disponibilidade.

Considerações para aplicações sem estado

A migração de aplicações sem estado é o caso mais simples:

  1. Aplique as definições de recursos (YAML ou Helm) ao novo cluster.
  2. Certifique-se de que tudo funciona conforme esperado.
  3. Redirecione o tráfego para ativar o novo cluster.

Considerações para aplicações com estado

Planeie cuidadosamente a migração de aplicações com estado para evitar perdas de dados ou períodos de indisponibilidade inesperados.

Ficheiros do Azure

Ao contrário dos discos, Ficheiros do Azure podem ser montadas em vários anfitriões em simultâneo. No cluster do AKS, o Azure e o Kubernetes não o impedem de criar um pod que o cluster do AKS ainda utiliza. Para evitar perda de dados e comportamento inesperado, certifique-se de que os clusters não escrevem nos mesmos ficheiros em simultâneo.

Se a sua aplicação conseguir alojar várias réplicas que apontem para a mesma partilha de ficheiros, siga os passos de migração sem estado e implemente as definições do YAML no seu novo cluster.

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

  1. Valide se a sua aplicação está a funcionar corretamente.
  2. Aponte o tráfego em direto para o novo cluster do AKS.
  3. Desligue o cluster antigo.

Se quiser começar com uma partilha vazia e fazer uma cópia dos dados de origem, pode utilizar os comandos para migrar os az storage file copy seus dados.

Migrar volumes persistentes

Se estiver a migrar volumes persistentes existentes para o AKS, geralmente seguirá estes passos:

  1. O Quiesce escreve na aplicação.
    • Este passo é opcional e requer tempo de inatividade.
  2. Tirar instantâneos dos discos.
  3. Crie novos discos geridos a partir dos instantâneos.
  4. Criar volumes persistentes no AKS.
  5. Atualize as especificações do pod para utilizar volumes existentes em vez de PersistentVolumeClaims (aprovisionamento estático).
  6. Implemente a sua aplicação no AKS.
  7. Valide se a sua aplicação está a funcionar corretamente.
  8. Aponte o tráfego em direto para o novo cluster do AKS.

Importante

Se optar por não questionar as escritas, terá de replicar dados para a nova implementação. Caso contrário, perderá os dados que foram escritos depois de tirar os instantâneos do disco.

Algumas ferramentas open source podem ajudá-lo a criar discos geridos e a migrar volumes entre clusters do Kubernetes:

Implementação da configuração do cluster

Recomendamos que utilize o pipeline de Integração Contínua (CI) e Entrega Contínua (CD) existente para implementar uma configuração de bem conhecido no AKS. Pode utilizar os Pipelines do Azure para criar e implementar as suas aplicações no AKS. Clone as suas tarefas de implementação existentes e certifique-se de que kubeconfig aponta 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, em seguida, aplique-as ao AKS. Pode utilizar kubectl para exportar objetos. Por exemplo:

kubectl get deployment -o yaml > deployments.yaml

Certifique-se de que examina o resultado e remove todos os campos de dados dinâmicos desnecessários.

Mover recursos existentes para outra região

Poderá querer mover o cluster do AKS para uma região diferente suportada pelo AKS. Recomendamos que crie um novo cluster na outra região e, em seguida, implemente os seus recursos e aplicações no seu novo cluster.

Além disso, se tiver serviços em execução no cluster do AKS, terá de instalar e configurar esses serviços no cluster na nova região.

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

  • AKS com Balanceador de Carga Standard e Conjuntos de Dimensionamento de Máquinas Virtuais
  • Serviços do Azure anexados existentes
  • Garantir quotas válidas
  • Elevada Disponibilidade e continuidade do negócio
  • Considerações para aplicações sem estado
  • Considerações para aplicações com estado
  • Implementação da configuração do cluster