Compartilhar via


Realocar um cluster do AKS (Serviço de Kubernetes do Azure) para outra região

Este artigo aborda as diretrizes para realocar um cluster do Serviço de Kubernetes do Azure para outra região.

Há vários motivos pelos quais talvez você queira mover seus recursos existentes do Azure de uma região para outra. Talvez você queira:

  • Aproveitar uma nova região do Azure.
  • Implantar recursos ou serviços disponíveis apenas em regiões específicas.
  • Atender aos requisitos internos de política e governança.
  • Alinhar-se com fusões e aquisições da empresa
  • Atender aos requisitos de planejamento de capacidade.

Observação

Os clientes com ciclos de lançamento rápidos geralmente aproveitam pipelines de CI/CD. Nesses casos, você pode considerar alterar os pipelines de build e lançamento em vez de implantar novamente os clusters do AKS na região de destino.

Pré-requisitos

Antes de começar o planejamento da realocação, revise os seguintes pré-requisitos:

  • Verifique se a região de destino tem capacidade suficiente (SKUs de VM) para acomodar os novos nós de cluster.

  • Valide se você tem permissões de criação de recursos para a assinatura de destino. Verifique se a política do Azure não está restringindo as regiões às quais o AKS pode ser implantado.

  • (Opcional) Colete os modelos ou scripts de IaC (Infraestrutura como código) com os quais você provisionou o cluster AKS de origem.

  • Colete os manifestos do Kubernetes para recriar a carga de trabalho do aplicativo no cluster de destino.

    Dica

    Avalie uma abordagem do GitOps para implantação de carga de trabalho em que os manifestos de configuração do Kubernetes são armazenados em um repositório git e aplicados automaticamente por um operador GitOps em execução dentro do cluster, como o Flux. Uma abordagem do GitOps torna a implantação nova de cargas de trabalho em clusters diferentes tão simples quanto instalar o controlador GitOps e apontá-lo para o repositório.

  • Examine a implementação de entrada do cluster.

  • Documente as alterações de DNS necessárias para apontar um domínio público para o ponto de extremidade de entrada do cluster.

  • Examine se o cluster armazena dados de estado, como volumes persistentes, que você precisa migrar para o cluster de destino.

  • Documente o gerenciamento e a distribuição de certificados TLS públicos.

  • Capture todos os endereços IP definidos na lista de permissões do serviço de API do AKS.

  • Entenda todos os recursos dependentes. Alguns dos recursos podem ser:

    • Filas, Barramentos de Mensagens, Mecanismos de Cache
    • Azure Key Vault
    • Identidade Gerenciada
    • Configuração de Rede Virtual. Definir tamanhos de sub-rede suficientes para permitir o crescimento do IP do contêiner se estiver usando o modelo de rede avançado do Azure
    • Endereço IP público
    • VNG (Gateway de Rede Virtual). Se a comunicação site a site for necessária para um ambiente local na região de destino, um VNG deverá ser criado na rede virtual de destino.
    • Ponto de Extremidade Privado do Azure. Os recursos de PaaS do Azure que utilizam pontos de extremidade de link privado devem ser revisados e novas instâncias de link privado criadas na região de destino, como ACR, BD SQL do Azure, KeyVault etc.
    • Gateway de Aplicativo do Azure
    • DNS do Azure
    • Firewall do Azure
    • Azure Monitor (Insights de Contêiner)
    • O Registro de Contêiner do Azure pode replicar imagens entre instâncias do ACR. Para obter um desempenho ideal ao efetuar pull de imagens, o registro deve existir na região de destino.

      Observação

      Se você usar o Registro de Contêiner do Azure para autenticar no registro de contêiner, a identidade gerenciada do novo cluster do AKS poderá ser a função RBAC AcrPull concedida.

    • Azure Managed Disks
    • Arquivos do Azure

Preparar-se

Antes de iniciar o processo de realocação do cluster, conclua as seguintes preparações:

  1. Para acomodar os nós e pods de cluster do AKS, se estiver usando a rede CNI do Azure, implante a rede virtual com muitas sub-redes de tamanho suficiente.

  2. Se você estiver usando o Azure Key Vault, implante o Key Vault.

  3. Verifique se os certificados de entrada TLS relevantes estão disponíveis para implantação, idealmente em um repositório seguro, como o Azure Key Vault.

  4. Implante um registro de contêiner. Sincronize as imagens do Registro de origem automaticamente ou recompile e envie novas imagens por push para o registro de destino usando um pipeline ou script de CI/CD.

  5. Implante um workspace do Azure Monitor.

  6. (Opcional) Implante o Gateway de Aplicativo do Azure para lidar com o AGIC (Controlador de Entrada do Gateway de Aplicativo) de entrada pode se integrar firmemente ao cluster

  7. Implante as fontes de dados exigidas pela carga de trabalho do cluster e restaure ou sincronize os dados de origem.

  8. Execute artefatos IaC existentes definidos em um pipeline de CI/CD que foram usados para implantar o cluster de origem e os serviços dos quais ele depende. Altere os parâmetros de entrada de código ou modelo para reimplantar para um grupo de recursos diferente e região do Azure.

Reimplantar

Implante o cluster do AKS sem nenhuma migração de dados seguindo estas etapas:

  1. Para criar o ambiente de destino no Azure, execute manualmente os artefatos IaC existentes em uma estação de trabalho local.

  2. Se não houver ativos de IaC existentes, a configuração atual do cluster poderá ser exportada como um modelo do ARM e executada na região de destino. Os modelos de IaC são criados do zero ou são versões modificadas de modelos de exemplo usando Bicep, JSON, Terraform ou outra solução.

    Observação

    • Conexões de Link Privado, registros conectados ao ACR e fontes de dados do workspace do Azure Monitor não são exportados no momento usando esse método e, portanto, devem ser removidos do modelo gerado antes da execução.
  3. Implante a carga de trabalho de contêiner no cluster do AKS, que pode ser obtida de duas maneiras:

    • Os Manifestos de Pull são extraídos de um repositório e aplicados por um controlador em execução dentro do cluster, conhecido como uma abordagem do GitOps.
    • Push. Os manifestos são enviados por push para o cluster usando o serviço de API do Kubernetes e a ferramenta de linha de comando kubectl, seja de um pipeline de CI/CD ou estação de trabalho local.
  4. Para garantir que o novo cluster seja executado conforme previsto, execute testes e validação.

  5. Altere suas entradas DNS públicas para apontar para o IP de entrada externo do cluster de destino (IP do Azure Public Load Balancer ou IP público do Gateway de Aplicativo).

  6. Uma implantação usando uma solução global de balanceamento de carga, como o DNS do Azure ou o Gerenciador de Tráfego do Azure, precisa adicionar a região à configuração.

Reimplantar com a migração de dados

Cargas de trabalho do AKS que usam o armazenamento local, como volumes persistentes, para armazenar dados ou hospedar serviços de banco de dados dentro do cluster podem ser armazenadas em backup em um cluster de origem e restauradas para um cluster de destino. Para saber como executar o backup e a restauração, consulte Fazer backup do Serviço de Kubernetes do Azure usando a CLI do Azure.